[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: scons
From:       Parag Warudkar <kernel-stuff () comcast ! net>
Date:       2005-02-13 1:33:09
Message-ID: 1108258389.18487.61.camel () localhost ! localdomain
[Download RAW message or body]

Why not do something like this -

1) Divide the configuration in two parts - Core Functionality and
Optional Modules.

2) Provide one platform specific configuration file for core
functionality on each platform - config-linux-debian.h , config-
windows.h etc. and pre-configure the absolutely essential things to
saner defaults such as C header include path in that file. This saves us
from having to fork a shell and actually compile a program to see if
something is present and if yes where.

3) For optional functionality, provide possible default settings for
each platform and have the user define what additional functionality he
wants. If things are in standard places this will work out-of-box.
Otherwise, provide with override mechanism - if the user was expert
enough to install things at a different place, he as well can edit the
config files to adjust the paths and build the thing.

Whatever does not fit into 2 and 3, for that, employ whatever means that
are necessary.

This saves lot of redundant work - 99% Linux folks have include files
in /usr/include, have path separator ":", have gcc as their compiler and
so on so forth - what purpose does it serve to guess it _all_ the times?

Parag

> Inefficient - Exactly why do I have to run that bloat named configure
> every time for kdelibs, kdebase............. kdevelop.....? To waste cpu
> cycles every time to find out that my compiler is GCC? This is just one
> thing. (It compiles programs with GCC which is already slow for
> compiling and it does uselessly repeat most of that stuff N number of
> times for N packages - is this not inefficient?) Further more, one can
> argue that forking 100 shells one from the other is also in-efficient
> but it's not that big a deal.
> 
> CMake looks right in one direction - You learn one thing. It generates
> the platform specific stuff - NMake makefiles, DSP on Windows, Makefiles
> on UNIX. I as a developer should not be bothered to learn 10  different
> build systems to support 10 platforms. If you are a Windows developer,
> you aren't forced to install Cygwin to be able to build things - You
> stay within your familiar territory of NMake/DSPs.
> 
> ACE and TAO ORB for example, is one complex project - They don't force
> the use of the auto* tools - They provide one config.h per platform, and
> platform specific stuff - DSP on Windows and Makefiles on GNU systems
> for instance. So the build essentially is choosing the config file and
> running the platform's build tool - make or nmake.
> 
> Parag 
> 
> 
>  
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]