[FFmpeg-devel] Compiling with Sun cc

Diego Biurrun diego
Sun Oct 12 17:25:08 CEST 2008


On Sun, Oct 12, 2008 at 12:40:59PM +0100, M?ns Rullg?rd wrote:
> Diego Biurrun <diego at biurrun.de> writes:
> 
> > On Sat, Oct 11, 2008 at 07:42:12PM -0700, Roman V. Shaposhnik wrote:
> >> 
> >> 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:
> >> > > > 
> >> > > > 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.
> 
> Sadly, getting suncc fixed still leaves gcc in a mess, and we have to
> support that.

There is always hope that gcc might eventually mimic the features of the
competition.

Diego




More information about the ffmpeg-devel mailing list