Shorter build times

Peter Kümmel syntheticpp at gmx.net
Thu Mar 29 18:00:48 BST 2007


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




More information about the kde-core-devel mailing list