[FFmpeg-devel] Compiling with Sun cc

[Roman V. Shaposhnik]

Sorry for the long delay...

On Mon, 2008-10-06 at 07:25 +0200, Diego Biurrun wrote:
> On Sun, Oct 05, 2008 at 09:47:10PM -0700, Roman V. Shaposhnik wrote:
> > On Fri, 2008-10-03 at 20:18 +0200, Diego Biurrun wrote:
> > > On Fri, Oct 03, 2008 at 11:26:36AM +0100, M?ns Rullg?rd wrote:
> > > > 
> > > > Diego 'Flameeyes' Petten? wrote:
> > > > > M?ns Rullg?rd <mans at mansr.com> writes:
> > > > >
> > > > >> That all depends on what the dependency output looks like.
> > > > >
> > > > > See attached if you wish ;)
> > > > >
> > > > > ffmpeg.o: /media/repos/flame/git/ffmpeg/ffmpeg.c
> > > > 
> > > > How does it look for files in subdirs, e.g. libavutil/mem.o?  Does it
> > > > output the full object file name, or does it mimic the lobotomised gcc
> > > > behaviour?
> > > 
> > > It apparently mimics gcc's idiocy.
> > > 
> > > Roman, a feature request for you: Please provide us with a suncc option
> > > that does not cut off the file path when outputting dependency
> > > information for inclusion in Makefiles.  It's clear you will have to
> > > provide an ass-backwards-compatibility mode, but you can surely improve
> > > upon that...
> > 
> > I guess I have to know more. If all you need is a FQPN, than cd'ing to /
> > would do the trick. IOW:
> >    (cd / ; gcc ...  -MM -MG ~/src/ffmpeg/libavcodec/dv.c) 
> > results in:
> > dv.o: /home/roman/src/ffmpeg/libavcodec/dv.c \
> >       /home/roman/src/ffmpeg/libavcodec/avcodec.h \ 
> >       /home/roman/src/ffmpeg/libavutil/avutil.h \
> > 
> > Am I missing something?
> 
> Yes.  The above is what gcc emits and it is only useful if you use
> braindamaged recursive make.  What we need is the full relative path,
> of the object file, i.e.
> 
> libavcodec/dv.o: libavcodec/dv.c libavcodec/avcodec.h libavutil/avutil.h
> 
> instead of
> 
> dv.o: libavcodec/dv.c libavcodec/avcodec.h libavutil/avutil.h
> 
> Does that clarify things?

It sure does and it makes sense. As long as you don't ask for 
full path names, but instead require full *relative* path names
(IOW: a string that, if given to open(2), will open the same
file that compiler did in the first place when it was run from
the same CWD) it makes a very logical request. I'll see what I
can do on our end.

Thanks,
Roman.