[FFmpeg-devel] Moving if(constant expression) to preprocessor?

[Reimar Döffinger]

On Sat, Sep 18, 2010 at 06:41:26PM +0200, Axel Holzinger wrote:
> Reimar D?ffinger wrote:
> > On Sat, Sep 18, 2010 at 06:00:40PM +0200, Axel Holzinger wrote:
> > > You could leave this up to me or others.
> > > 
> > > It is possible to write a macro that does the trick and in 
> > the end the 
> > > above line would for example look like this:
> > > 
> > > AV_COND_IF(CONFIG_##X##_HWACCEL, 
> > (av_register_hwaccel(&x##_hwaccel)),)
> > > ; }
> > > 
> > > Wouldn't that still be fine? And it could be done with a 
> > few lines of 
> > > generic macro defintions that could go to some generic header.
> > > 
> > > What would be the disadvantage?
> > 
> > 1) It's a rather obfuscated mess
> 
> Where would that mess come from? Please elaborate.

The AV_COND_IF macro definition would be that.
And to a degree its use as well.

> > 2) There's a lot more where this won't work
> 
> I don't talk of things that wouldn't work. Please give any details
> where what wouldn't work.

Just grep for 'if (CONFIG'. Not all of them will cause compilation
errors, but most.

> > 3) The compiler will not syntax-check (actually it can even
> >    run quite a lot of static analysis) the disabled code
> 
> Fair enough. But isn't #ifdefs exactly for masking out code that isn't
> possible to be compiled on a system that is missing features (like
> i.e. hardware support). What more than a function call or struct
> definition will the compiler check? I don't think is does help a lot
> if the compiler checks this, but leaves away all the details. For
> thoroughly checking code, the relies on special features, the features
> have to be turned on/be available to get a correct analysis from the
> compiler.

If you volunteer to provide every developer with every strange combination
of hardware and someone to test their code on all of them?
Otherwise at least being able to check syntactical correctness of the parts
that are embedded in common code (after all, someone without such a system
would only be touching common code mostly) is useful.
If you really care search the archives for the discussion when we first
introduced it, we did it to solve an actual annoyance.
As a side-effect it also solves the issue that gcc does not make it possible
to make it an error when you do
#if SOMEDEFINE
and SOMEDEFINE is not defined.
Which can lead to hard to debug issues.

> Why is the functions itself masked out by #ifdefs then? Wouldn't it
> then be consequent to have function stubs, that do nothing but are
> there to make the compiler/linker happy? Using the optimiser to me
> does smell a bit.

Because we generally do consider binary size and performance an issue.

> > And I don't think there's any way you'll be able to solve 3)
> 
> No I won't. Sounds like you want to sell this to me as a law that has
> to be complied.

Unless you have some immensely more convincing arguments you might
as well consider it as such. We decided to do it like this on purpose,
as did some other projects like busybox and it's highly unlikely
that's just because we do not know better.