confdefs.h is never created by configure context

[bdbaddog]

This issue was originally created at: 2009-07-16 05:10:31.
This issue was reported by: bms.

bms said at 2009-07-16 05:10:31

The CheckHeader() and other checks allow Autoconf to be replaced.

However, whilst the configuration context is documented to contain context.headerfilename, there doesn't appear to be any way of setting this variable when the configuration context is created, and it probably needs changes to SCons itself.

It is explicitly set to None when the context is created, and that's it.

Therefore, confdefs.h is never created, so SCons configuration tests never actually get to see HAVE_FOO_H defines.

gregnoel said at 2009-11-10 18:02:04

Bug party triage.

gregnoel said at 2010-07-21 17:00:31

Bug party triage. Bump the priority of this issue.

garyo said at 2010-07-25 13:27:27

I've looked into this a little. It's a bit convoluted. At first I thought this bug was referring to config.h generation. You can specify a config.h file name when creating the context (via the config_h arg); what happens is the SConf code builds a set of #define strings based on user's calls to sconf.Define() and those end up in config.h. However config.h is never created during the configuration tests; there's a builder that is set up in Main.py (where it calls SCons.SConf.CreateConfigHBuilder(SCons.Defaults.DefaultEnvironment()), which builds config.h from the strings) that makes sure config.h is up-to-date before any source file needs it. That part seems to work OK.

But this bug is really about confdefs.h, which is (according to the code) supposed to be created and updated during the tests. Most of the logic there is in Conftest.py. That code seems to me to be incomplete. There's no way to specify it when creating a Configure context, and even if I do it manually it doesn't get into the individual CheckContext instance, which is where it's needed. And if I do pass it all the way through, there are errors in the configure tests due to the file being missing. I think basically it was never finished. At least that's what it looks like to me from Conftest.py.

We should figure out what's needed to finish it so it works. At least:

• an arg to Configure() to specify that confdefs.h should be used (or default it on?)
• pass that name to CheckContext when creating those
• create the file if it doesn't exist, before running tests
• make it actually work in Conftest.py (_Have, etc.)
• write tests
• update doc

Votes for this issue: 1.

[mwichmann]

Many years later, looking at it for about the third time... the @garyo comment seems on target. Autoconf has used confdefs.h as an internal (silent) accumulator of results, always included by checks, as you go through them, conclusions are added, so subsequent checks can use that info. We don't auto-include it unless someone has initialized context.headerfilename to something, which, as noted above, can't be done (without fiddling SCons source itself).

We can't use config.h because it's not available during the configure run, it's generated later, for use by consumers of the Configure tests. If we need this kind of behavior, we have to keep track ourselves, and pass it in using the string argument usually named header to the various checkers.

Dunno if there's anything to do here - the feature is incomplete, but it's also not documented beyond the docstring at the head of Confdefs.py, so it's not like we've exposed it to users. It doesn't break anything, so there's no real reason to remove the existing incomplete code. If somebody wants to volunteer to complete it, great.

I'd suggest close this (with a "reopen if someone cares" note) since it's not a documented feature.

[bdbaddog]

Hmm.. Part of the reason that autoconf has this, I'd think, is so the various later checks could do different things with the results of successive preceding checks.
Since SCons has the power of python, those if/else type decisions can be made in SConscript(s) instead.
So there's always been a way to do this, it's just different than the way you'd do it with autoconf.

Unless I'm missing something here? @mwichmann

[mwichmann]

I don't think so ("missing something")... plus, it does still have the ability to accumulate from previous checks, I think. Perhaps needs some thought... imitating autoconf too closely wasn't ever a really superb match with scons logic.