very basic SConfigure support available

[Ralf Habacker]

Am Sonntag, 23. Oktober 2005 09:16 schrieb Stephan Kulow:
> On Sunday 23 October 2005 02:01, Ralf Habacker wrote:
> > conf.cheaders += "unistd.h"
>
> This shows clearly that it will suck as you need to know very well about
> white spaces. I think strings are a dead end here.

Do you have take a deeper look in the class  PackageConfiguration ? There is 
support for dealing with spaces 

	def __setattr__(self, item, value):
		"""Maps attributes to values."""
		if not self.__dict__.has_key(item):
			self.__dict__[item] = value
		elif type(value) is types.ListType:
			self.__dict__[item] += value
		elif type(value) is types.StringType:
			self.__dict__[item] += value + ' '
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		else:
			print "unknown type"


> conf should be a obj that has functions you need to call to append
> something. 
It is - from Type PackageConfiguration. See configure.py 

> And before you implement parsers, you should make a design what 
> is supposed to be in the files.

The parser is an initial play ground to see what kind of runtime issues could  
be to be able to check if the proposal is a good design. Before we have 
something to play with we are only on the green table. :-) 

Design: For this i have started the custom configuration page 
(config_custom.dox) as proposal. If a specification/design is discussed in a 
mailing list with omany single emails it is very hard to get an overview for 
newbies, so I prefer to writing down a structured extract. Additional I'm not 
a python guru, so i prefer to write specs in a more general manner, thinking 
in processes/steps and user related view not mostly in real code.  

> And you also need to put some extra functions in the conf obj that e.g.
> control in what config.h the results are written to.
>
> So I picturing:
>
> conf.setConfigHeader("dcop/config-dcop.h")
yes this is a new attribute 

> conf.checkFunction("setenv")
> conf.checkHeaders(['sys/time.h', ['unistd.h'])

> if conf.checkWithArg('dpms', conf.HelpString('without-dpms','disable DPMS
> power saving'):
>    have_dpms=no
> else:
>   conf.checkLink(.....
>
> With other words: I don't think the API of autoconf's macros was bad and we
> should stick to an API also for configure checks. Still you want tons of
> helper functions and you want them to spread in subfiles.
> What will be interesting though is:
>    a) to gather the help options (the "without-dpms" in the above example)
> for scons help. You don't want to evaluate the tests on help, so I guess we
> need eiter a simple parser that greps HelpString out of the SConfigure
> files or something fancy.

Because of this I wrote in the configuration process page  in step 2 at 
http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/bksys/doc/configuration.dox

required steps

   1. parse command line options related to the configure process
   2. scan all directories for custom configuring scripts (SConfigure), 
collect all required cheader, cfunction, modules and other options and store 
them in the cache for further processing
   3. perform the required task for detecting the requested configure options
   4. store the results in the configuration cache
   5. create the required configuration header

Are you see any problems with this steps or do you have additional notes ? 

>    b) when to do the walk. The configure.py you commited takes 2s on my
>        kdelibs tree on second run - just for the walk. 
>        If you would want to  do that on every scons run, you won't find many 
> fans. 
no, remember this is currently play ground and could be taken to improved. 
I'm currently in the state to figure out the best design and this are the 
tools to find the right way. 

>  So once again, we need to come up with a solution to cache the file list 
> with their mtimes.
Which would be an extension of the above initial script. Do you have a pointer 
for this or a working solution ? 

Regards
 Ralf