bksys / scons (Re: win32 port)

[Federic-Emmanuel Picca]

On Mon, Jan 09, 2006 at 01:27:45PM -0600, Matt Rogers wrote:

> I firmly believe that SCons is capable of handling KDE, just like I
> believe that CMake is capable of handling KDE. please keep in mind that
> this time around, building KDE is harder with a new system because
> (unlike during the age of autotools) KDE is now huge, and rather than
> doing things step by step wrt adding special things like support for
> dcop files or kdeinit module when those ideas came about, it all has to
> be done at once and that takes time. Let's also not forget that we're
> dealing with the most complicated module in terms of the build system
> with kdelibs and that helps contribute a bit to the "scons isn't
> working" impression.

I don't know very much about KDE, but bksys seems to be a promising system
even for non-KDE project.
but for this we need to organize the bksys-code the right way.

We can find kde specific code in the generic module.
Is it the right place for this code ?

It seems that you separated the code depending of the platform.
Except that lots of code was mixed in the non platform specific code.

so even for the simplest things (genobj), we need to refactor a part of
the code.

Once the basic code is set we could put the qt and kde specific part.

So I propose to focus on the refactoring of the generic module, to take
into account that we want to build on different platforms
osx, unix and windows.

In that refactoring we need to think about the right way to do the
configuration.

1) to my opinion, we need to put in the platform specific part, the code
to populate the CCFLAGS and the LINKFLAGS so next time we use scons
without configuration, we can retrive thoses two flags from the cache
(so the platform specific code is only during the configuration process).

2) for now we have CACHED_XXX or XXX_ISCONFIGURED Is it the same meaning
If not maybe we need a file explaining what must be implement in each
module.

all this to say that we need a module well implemented and use that module
as a reference for other modules.

this is that way that I am working on the generic module.

> I'd suggest a little patience, and if there's something that we need
> from scons then we need to bring it up on this list so that i can go to
> the scons development team and say, "hey, we're using scons, and we'd like it
> to do X, Y, and Z." and get support from them. If you've read the scons
> dev list archives, they know we're using scons for KDE, and they've
> offered support if we need it. we should take advantage of that.

Yes right

> 
> If after some more time, scons still isn't working for us, then we
> switch. From my POV, we're still in the evaluation stage.

I am using only the generic part and it is quite usable. Still some work
but usable.
My POV is that we are on the right way. :)

-- 
Frédéric-Emmanuel PICCA
Departement of Physics
McGill University Ernest Rutherford Physics Building
3600 University Street
Montreal, PQ, Canada H3A2T8
phone: 	+1-(514)-398-1545
fax:	+1-(514)-398-8434
email: 	piccaf at physics.mcgill.ca