[C++-sig] Compile times using Boost::python.

[gideon may]

--On Wednesday, June 04, 2003 4:35 PM -0700 "Ralf W. Grosse-Kunstleve" 
<rwgk at yahoo.com> wrote:

> --- gideon may <gideon at computer.org> wrote:
>> Regarding compilation on Linux in debug mode (gcc 3.2),
>> I have extremely long linking phases, sometimes up to an hour
>> with my application :(. Is there a way to speed this up ?
>> Linking without debug info is much faster.
>
> I am always using -O0. If and only if I really need the debug symbols I
> recompile with -g (with SCons and bjam you can do this without
> interferring with your -O0 built).

I agree with you, normally I do build release versions (am using bjam),
but in the case that I do need debugging info I normally take lunch :)

>
>> > 2. Once you have your (run)time-consuming core algorithms implemented
>> > in C++ and wrapped with Boost.Python you can spend most of your time
>> > working with the much more pleasant Python language. I am sometimes
>> > going for weeks without recompiling.
>>
>> Except if you're actively developing the wrapper library and looking
>> for bugs in your code.
>
> True, but:
>
> - Parallel builts really help.

Agree, if you have a multiprocessor system. And parallel builds don't speed
up the linking phase, which is definitely the bottleneck in the 
edit-compile-test
loop.

> - Good build systems like SCons and bjam always only recompile what is
> really needed (i.e. no "make clean" necessary ever).

what is make clean or  bjam clean <wink> ?

> - You can maximize the benefits of parallel builts and good build systems
> by modularizing your code, which is also good for other reasons.

Again, the compilation is fast in comparison with the linking. Unfortunately
I do need to link after I change a single source file. BTW, my library 
consists
of about 100 source files, thus I could say the code is pretty modular.

> - While developing you can use the fastest platform available. Test on
> slower platforms later.

With me they are all one and the same  platform :(

Guess I will do some profiling of the gcc linker and file a report, as Dave 
mentioned

ciao
gideon