[A-A-P-develop] Re: [scons-devel] auto-configuration plans
Brought to you by:
vimboss
From: Bram M. <Br...@mo...> - 2003-08-08 08:54:12
|
Christoph Wiedemann wrote: > Well, we found out, that it is not just that easy to do this system- > independent, if you want to create a config.log file. Maybe this is partly > cause both of us, David and me, are no windows gurus ... However, we set up > something that looks like it works (the piped_spawn functions in the > corresponding Platform modules). Redirecting the output of a shell command indeed requires some non-portable code. It's a pity there is no standard Python way to do this. This is probably the most complicated part for executing the configure tests. > >> 1. SCons went beta recently, so we should try hard to fix the API > >> including the API to the SConf subsystem. The affected API is the > >> Configure - call, but also the Custom-Test stuff. > > > > Currently there is no API. At least, I could not find it. Since the > > use of the SConf module is quite SCons-specific I already suggested to > > make an interface at a lower level. That avoids modifying parts of > > SCons that use the SConf module. And makes it easier to define an > > interface that is not SCons-specific. > > There *is* the current SCons API (documented in the SCons manpage). I just > meant that this API shouldn't change. The manual page doesn't say anything about TryBuild() and the like... From reading the source code it's not clear what is part of the API and what isn't. Thus it's not clear what may change and what should not change to remain backwards compatible. Anyway, with the current approach I'll not have to worry about these things. It is unlikely that any SCons user will notice the split up of SConf.py. > >> 3. Caching the checks is really essential for a usable autoconf > >> replacement. I doubt, that a completely non-caching autoconf version > >> would be accepted by users. Though not perfect yet, the current caching > >> mechanism of scons is rather good, and i wouldn't like to see this good > >> thing dying... > > > > I don't see why caching is essential. Can you explain? > > It is essential from the developer's point of view. Developers want things > to go fast, so they won't accept a configuration tool which doesn't cache > results at all. That's just my personal viewpoint. I'm still not sure what you are talking about. You would not want to do the configure phase every time you invoke the builder, of course. Thus the configure results are stored (in config.h etc.) and configure is only run again when it's needed or when the user explicitly tells the builder to. This assumes the configuration phase is viewed as one dependency of the configure output (config.h, etc.) on the configure input (the configuration script). Inside the configuration script there are hardly any things that are repeated. It is very unusual to do the same test twice. Perhaps a few things are duplicated when two high-level checks use the same low-level check. But caching these results will not give much speedup (and simply using a variable for the result can also avoid doing a test twice). There is also the overhead of caching itself to take into account. If you don't want a separate configure phase and mix configure tests with other building, then you indeed need to avoid that time consuming tests are done again. But I suppose this uses the standard SCons dependency stuff, you would not need a separate caching mechanism on top of the already existing one. Hmm, perhaps the problem is that the SCons builders expect to store the results of building in a file, and a configure check may only result in a variable being set to "success" or "fail". You could store that in a file, but that's a lot of overhead. Is this the reason to add a separate caching mechanism for the configure checks? > After all, i think that it is worth trying to define an > SCons-independant API for the tests. Both worlds would benefit from > such an API and the tests defined on it. Joerg Beyer posted his work on an Aap autoconf implementation yesterday. So I'm all set to figure out what the common parts with SCons are and how to interface them. -- hundred-and-one symptoms of being an internet addict: 74. Your most erotic dreams are about cybersex /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html /// |