[FFmpeg-devel] Compiling with Sun cc

[Diego Biurrun]

On Sat, Oct 11, 2008 at 07:42:12PM -0700, Roman V. Shaposhnik wrote:
> 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.

Great, this has been Mans' and mine pet peeve when dealing with
dependency generation for FFmpeg/MPlayer.

Diego