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

List:       kde-core-devel
Subject:    Re: Shorter build times
From:       Peter_Kümmel <syntheticpp () gmx ! net>
Date:       2007-03-29 16:59:42
Message-ID: 460BF0C0.7020906 () gmx ! net
[Download RAW message or body]

David Faure wrote:
> On Wednesday 28 March 2007, Peter Kümmel wrote:
>> The idea of attached patch is to manually exclude some files from the generated
>> all-in-one file.
> Good idea.

Thanks ;)

> 
> But why are the touched files compiled together? IMHO this isn't a good idea,
> it will make developers forget some #include statements.

You mean developers will forget to comment out the includes in the _const file?
The _touched file needs not to be changed, only the _const file.

Commenting out of the include line in the _const file is neccesary because undefining
the macros only doesn't prevent cmake to add the include file to the dependency file
- a cmake bug?

The touched files are compiled together because currently the decision which file
will be touched is made at compile-time not at configuration-time, so it
is not necessary to call cmake again and again when touching a file.

> 
> I like the idea of a allinone_const.cpp, but the non-const files (i.e. the modified files)
> should just be compiled separately. Can that be done?
> 

It could be done when you know which files are const and which are touched at
configuration-time, then it is possible to pass a list of files to the cmake
scripts which will create separate build rules for these files.

Maybe it is also possible to create such a touched list automatically (with
some critera for what is 'touched') but I currently have no idea how this
could be done.


A ugly version would be to add each file twice to the build process
once in the _const file and once as separarte build and than switching
on/off the code with macros within the cpp file, like it is done in the
header file, by defining one macro the code 'moves' from the
_const file into the seperate file. But I'm not sure I this
is a nice idea.


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