Modular configuration

[Nagy Thomas]

What about a hashtable in SConstruct, like this:

conftests = {
"lowlevel" : ["sys.h", "otherheader.h"]
"libxml" : ["someheader.h"]
}

env=configure(config, conftests)

and if the conftests are not given then all possible
tests are run or an error is thrown ?

Thomas

--- David Faure <faure at kde.org> a écrit :

> On Monday 17 October 2005 14:10, Stephan Kulow
> wrote:
> > The main reason why you can't do this from
> SConscript files is that they work
> > on an environment and configure's main task is to
> create that environment.
> OK.
> 
> > So SConscript files are per se a bad place to put
> them. The name SconfNeeds is 
> > pretty bad too, but different topic.
> Hey, at least I didn't name it "unserconf" :-)
> But I agree. Initially I called it needs because I
> only wanted "sys/stat.h, getmntent"
> in it. But then I realized we want to categorize
> that, so it would be a python script,
> not just a text file. So... SConf? SConsConf?
> Actually I don't understand the "SConscript" name
> (the 's' belongs to both
> "scons" and "script"?)
> 
> > I very much think we need something more easy to
> plug together, yes. And a 
> > recursive search is pretty easy to implement and
> if you have to stat the dirs 
> > pretty soon anyway, it isn't even very expensive
> at runtime. So I wouldn't 
> > worry about plugging it somewhere. I don't think
> there is any reason to mimik
> > the "obj = " syntax. As we simply don't create
> objects there, but want checks 
> > to be done. 
> OK.
> 
> > So I think a series of
> env.CheckCHeader("sys/param.h") calls is 
> > asking for too much
> 
> What do you mean, it's asking for too much? Did
> rather you mean it would be OK to do that there?
> I would agree, but it doesn't do the whole job, does
> it? E.g. it handles config.h but
> it doesn't do the caching.
> 
> About the config.h output, we would need to put
> context.headerfile="config-lowlevel.h" 
> somewhere, for all those subdir checks to go there.
> OK, config-subdirs.h, since it
> might not only be about lowlevel stuff (?)
> 
> Or we might want per-subdir .h files (e.g.
> config-kdecore.h and config-kdeui.h), so that
> it's easier to move a subdir to another module...
> but then we have to run the same tests 
> more than once, if both kdecore and kdeui need
> sys/stat.h. Although, with the caching
> it would be fast, just a bit strange on stdout.
> 
> Ah, and maybe it's enough to have CheckCHeader()
> calls if we handled
> the caching like: automatically writing into
> CACHEDIR+'config-kdecore.py' 
> that KDECORE_ISCONFIGURED=1, and not using
> kdecore/SConfChecks (new name :)
> when that is set. If someone modifies that file, he
> needs to do "./scons configure"
> after that, which is quite OK. This is getting
> somewhere - if we do the
> per-subdir "ok, this is configured" caching
> automatically, then indeed
> env.CheckCHeader("sys/param.h") from SConfChecks is
> enough.
> 
> -- 
> David Faure, faure at kde.org, sponsored by Trolltech
> to work on KDE,
> Konqueror (http://www.konqueror.org), and KOffice
> (http://www.koffice.org).
> 
> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
>
https://mail.kde.org/mailman/listinfo/kde-buildsystem
> 


/* Thomas Nagy */


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com