[MPlayer-dev-eng] configure vs #undef

[Diego Biurrun]

On Mon, Aug 21, 2006 at 09:42:24AM -0400, Rich Felker wrote:
> On Mon, Aug 21, 2006 at 02:51:23PM +0200, Diego Biurrun wrote:
> > Currently configure sets "#define FOO" if a test succeeds and if it
> > fails it sets "#undef FOO" in config.h.  I wonder if this is necessary.
> > AFAICT we only depend on defined and not on undefine things.
> > 
> > I'm tempted to remove all the #undef, which should get rid of 250 or
> > more lines in configure.  Am I overlooking something?
> 
> You're overlooking the fact that the #undef makes debugging easier.
> Users can _see_ the #undef in config.h and know that the option was
> disabled by configure, as opposed to having to look all over various
> headers to make sure it's not implicitly defined because of something
> else. It also makes it easier to then override the decisions of
> configure to see if something works before modifying configure to fix
> whatever bug prevented detection from working.

I don't entirely agree.

IMO configure should be the only place to #define system-dependent
things, so if some header implicitly defines something then it's
probably a bug and/or bad style.  But maybe I'm just not entirely sure
what you have in mind.

FFmpeg's configure for example does not place #undef in config.h.

I've just tried that modification locally, it appears to work and the
diffstat sure looks tempting:

 1 file changed, 4 insertions(+), 306 deletions(-)

> So in the absence of a compelling reason to remove #undefs I'm
> inclined to leave them. However we could surely consider an option to
> automate the #define/#undef thing better to reduce the code size in
> configure!

I'm planning to reduce code size in configure (and I'm already on it),
but doing it incrementally in a way that does not break current
configurations complicates things a bit.

Diego