From: Ken H. <ke...@ha...> - 2004-10-08 03:37:06
|
Tony Houghton wrote: > In <51518.24.43.56.135.1097118689.squirrel@24.43.56.135>, jd...@hc... wrote: > > >>The config.h is what I would consider a legacy option that can be removed >>pretty easily if we were to move it to SCONS. If we really needed to say >>that yes this thing is or is not supported we can support defines just by >>adding a -D option. We could generate a config.h file I suppose but that >>isn't the best way of doing it (Consider that configure is ran once, but >>make possibly multiple times in a typical program. But scons configures >>when it runs.) > > > What's the disadvantage of config.h compared to loads of -D options? I > suppose config.h slows compilation slightly, but it cuts down the > clutter on the gcc commands scrolling past. They're bad enough as they > are, especially if you run pkg-config once, eg at configure time, > instead of on the fly like ROX. > > Unless, is Scons clever enough to know which files depend on a > particular option and rebuild only those when you change the option? The scons wiki has a GenerateConfig 'recipie' that creates a config.h file for you. http://www.scons.org/cgi-bin/wiki/GenerateConfig This may not be the best way to use scons, but it should be a good stepping stone to replace the autotools without touching the existing code. Future code might find a nicer replacement for config.h. -- Ken Hayber (ke...@ha...) Huntington Beach, CA |