[FFmpeg-devel] Compiling with Sun cc

[Måns Rullgård]

Diego Biurrun <diego at biurrun.de> writes:

> 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.

Sadly, getting suncc fixed still leaves gcc in a mess, and we have to
support that.

-- 
M?ns Rullg?rd
mans at mansr.com