From kde-buildsystem  Mon Oct 24 14:56:10 2005
From: ralf.habacker () freenet ! de (Ralf Habacker)
Date: Mon, 24 Oct 2005 14:56:10 +0000
To: kde-buildsystem
Subject: very basic SConfigure support available
Message-Id: <200510241656.10775.ralf.habacker () freenet ! de>
X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=113280651211851

Am Montag, 24. Oktober 2005 13:36 schrieb Stephan Kulow:
> Am Montag, 24. Oktober 2005 12:04 schrieb 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
>
> Then you can just as well write = "unistd.h". But why not make it a list
> right away in the internal implementation? My point is less of this can be
> handled, I'm more talking about the API, e.g. does the user/author of the
> code understand what he's supposed to do?
>
> > 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. :-)
>
> You misunderstood me. I'm aware that this is a play ground, my point I
> dislike the general idea of the syntax. And I was disagreeing with the
> syntax already before you wrote your initial parser.

After thinking about this stuff a while more, I'm coming to the result, that 
using descriptive functions like you have  mentioned is the best because 

- using the += syntax requires one function (__setattr__) fo all types of 
attributes, which  may result in a very  long unreadable function. 

- using descriptive functions like you have mentioned allows using a 
dictionary as parameter like the SCons  functions. This allows parameter 
setting regardless of their order, which is important if there are many 
parameters , but only used a few. I think especially about the checkModule 
function 

conf.checkModule(
	key="key", 			
	type=<supported module checking type>,
	description="description",
	check_handler=<python function for user defined checks>,
	message=['not-found-message',found-message']), 

and so one. 

Although I vote to allow a space separated string as parameter for example 

conf.checkFunction('setenv gethostname')

because I see no problems to check the parameter type internal and convert it 
into a list if required. This form is easier to type as 

conf.checkFunction(['setenv','gethostname'])

and will probably one  of the most used case 

Regards
 Ralf