[Ffmpeg-devel] libavutil conflict with system headers on Darwin

[Måns Rullgård]

Diego Biurrun said:
> On Sun, Dec 03, 2006 at 05:27:55PM +0100, Reimar D?ffinger wrote:
>> [...]
>> > > It is usually reasonable to include system headers before ffmpeg
>> > > headers, but that's not enough to avoid the problem. Other non-system
>> > > headers besides ffmpeg ones can also use __attribute__((always_inline)),
>> > > and it's not reasonable to require that ffmpeg headers must be included
>> > > after those. It would be impossible to include headers from two projects
>> > > with such "must appear last" requirements.
>> >
>> > as these arent supposed to be vissible to the outside you can never have a
>> > problem with headers from 2 projects ...
>>
>> Unfortunately always_inline currently is visible outside. Probably a bad idea in
>> looking back.
>> Though I find this define a bit weird anyway, since is named the same
>> way as one of its "components":
>> #    define always_inline __attribute__((always_inline)) inline
>> In addition it is inconsistent, e.g.:
>> #    define attribute_used __attribute__((used))
>> so attribute_always_inline would be more consistent (although
>> always_inline is not only an attribute it also includes inline).
>
> So my next suggestion is to rename it to
>
>   attribute_always_inline
>
> which is both more consistent and should avoid the name clash we are
> currently suffering from.  Is that a workable solution?

That's not really any more consistent.  The expansion of attribute_inline
includes the regular 'inline' keyword as well as __attribute__((always_inline)).

Before changing anything, I'd suggest investigating whether a simple reordering
of #include directives would get around the problem.  Are these macros visible
to applications using our headers?  Should they be?

-- 
M?ns Rullg?rd
mru at inprovide.com