per-class build is broken?

[Bruno Chareyre]

This week-end, I fixed compile errors in per-class build. Now, I have no explicit error message, but the compilation still ends with "terminated because of errors"...
Can anybody compile "per-class" at the moment?
It seems monolithic takes more time for routine edit/compile on only one file. I spend most yade-time waiting for the compiler these days... it is annoying.

[Václav Šmilauer (eudoxos)]

You overlooked the error message

pkg/common/Engine/PartialEngine/GravityEngines.hpp: In constructor 'CentralGravityEngine::CentralGravityEngine()':
pkg/common/Engine/PartialEngine/GravityEngines.hpp:31: error: incomplete type 'Body' used in nested name specifier

I will fix that in a few minutes

[Václav Šmilauer (eudoxos)]

r2020

[Bruno Chareyre (bruno-chareyre)]

No, I opened the bug AFTER fixing the problem in gravity engine on my side.

[Václav Šmilauer (eudoxos)]

I am not able to reproduce it here, yade compiles without error with per-class linkage. Can you attach full output by running

scons > /tmp/error.log 2>&1

[Bruno Chareyre (bruno-chareyre)]

It is as I said in the original post, no error message until the end.
I guess this trunk is corrupted somehow. I keep it as-is in case you are interested in that, I'm working with other trunks and compiling monolithic a.t.m.

[Václav Šmilauer (eudoxos)]

I suspect your computer runs out of memory, kernel kills one of the compiler instances and there it is, error without any message. Can you confirm that by watching memory usage during compilation? You can also try jobs=1 or chunkSize=10 (but that will make compilation slower).

[Bruno Chareyre (bruno-chareyre)]

I always compile with jobs=1. ChunkSize has an effect on per-class
build? There is something I don't understand.
It seems you are right on the memory. I saw swap usage increasing slowly
while the compilation was stuck at "scons: Building targets ..." (no
local diff after last compile attempt).
I didn't wait 100% swap though, after 30mins I wanted to work on the PC
:-P . I stopped compilation at 75% swap or so.

p.s. Is it better to send this to <email address hidden> or to
yade-dev? What do you prefer?

[Anton Gladky (gladky-anton)]

On my experience, when the compilation process starts to use swap, it is
better to terminate it.
I think, if you make chunkSize=1, it will be like per-class build. I can be
wrong.
______________________________

Anton Gladkyy

2010/2/18 Chareyre <email address hidden>

> I always compile with jobs=1. ChunkSize has an effect on per-class
> build? There is something I don't understand.
> It seems you are right on the memory. I saw swap usage increasing slowly
> while the compilation was stuck at "scons: Building targets ..." (no
> local diff after last compile attempt).
> I didn't wait 100% swap though, after 30mins I wanted to work on the PC
> :-P . I stopped compilation at 75% swap or so.
>
>
> p.s. Is it better to send this to <email address hidden> or to
> yade-dev? What do you prefer?
>
> --
> per-class build is broken?
> https://bugs.launchpad.net/bugs/522244
> You received this bug notification because you are subscribed to Yade.
>
> Status in Yet Another Dynamic Engine: New
>
> Bug description:
> This week-end, I fixed compile errors in per-class build. Now, I have no
> explicit error message, but the compilation still ends with "terminated
> because of errors"...
> Can anybody compile "per-class" at the moment?
> It seems monolithic takes more time for routine edit/compile on only one
> file. I spend most yade-time waiting for the compiler these days... it is
> annoying.
>
>
>

[Bruno Chareyre (bruno-chareyre)]

Thanks. Actually, monolithic with jobs=1 and default chunkSize compiles
for me but it uses swap (not sure I tried in debug mode though).
My current default is mono+j1+chunk=3.

By the way, can't we take advantage of precompiled headers in our case
(http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html)?

Bruno

[Václav Šmilauer (eudoxos)]

Ok, sorry. chunkSize doesn't affect per-class builds, that was my mistake.

I think I experimented with precompiled headers already, but it didn't quite meet my expectations.

How much memory do you have? Get 4GB if you can and your computer can handle it.

[Bruno Chareyre (bruno-chareyre)]

Yes, I realized pch's are probably no big help if compile time is spent
in expanding macros... :(
Moreover, I just tried a monolithic with chunksize=4 and only one
modified file, most time is spent in link edition, not compilation.

I have 1GB memory, but I don't think I need more memory. I need a new
computer! :)

[Václav Šmilauer (eudoxos)]

Ah, nay, macros as _fast_. It is template code that is slow and uses loads of memory (it should improve with gcc 4.5 a bit). For linkage, install the bintuils-gold package (it replaces the default linker), it is faster by an order of magnitude.

[Bruno Chareyre (bruno-chareyre)]

I tried compiling the same trunk on a2orciere (updated to 2115), still no success and no error message. Compile witout debug is ok. I'm really curious about this... 2G RAM + 2G swap should be ok in per-class no?

[Bruno Chareyre (bruno-chareyre)]

The good news is after the failed compilation, yade seems to run normally... perhaps the error message is irrelevant, or I'm just lucky...

[Václav Šmilauer (eudoxos)]

Run top (or htop) as it compiles and watch how much RAM it takes. I can't guess at such distance.

The earlier build log seems to suggest that it went to the very end.

Have a look at scons manpage, it probably has some means to verbosely show what it does etc, but you have to sort this business out locally yourself...

[Bruno Chareyre (bruno-chareyre)]

 From htop, I wouldn't say the swap is used, or it is used and fulled
faster than my eye can see...
It looks like the compilation stops with the error message when RAM is
around 100% and swap 1-2% (i.e. roughly 2GB of memory, consistent with
the other PC stoping when RAM and swap were both full, with 1GB each).
Forget this. I'll have to try a fresh install in debug mode one day, and
see what happens.

[Václav Šmilauer (eudoxos)]

No updates, reopen if appropriate. Most likely specific to your machine and lack of RAM.