The 19 July 2008 build (5142) is out.

[killerbot]

Dear All, I would advice to stop using this nightly build. I have discovered a serious regression due to rev 5124. We hope to have it fixed in tomorrows nightly.

[Jenna]

I reverted my repo back to r5115, please downgrade to this version if possible, until the cause for the regression is found.

More information about the regression: http://forums.next.codeblocks.org/index.php/topic,8833.msg64081.html.

I will be not at home until thursday or friday night, so I will not be able to update the repo earlier.

[Jenna]

Your compiler ran out of memory while compiling this file. There are already some other posts in the forum around regarding this file. I think the best solution was to disable optimizations for that file.

Here's a link to my post with a patch for "Makefile.am": http://forums.next.codeblocks.org/index.php/topic,8688.msg63715.html#msg63715

Thanks. Just a second ago, I found your post (used wrong search strings or overlooked the hit)
will apply the patch and recompile it.

I just added a patch to trunk that turns off optimization for headerfixip-plugin if "build-host" is "x86_64" (r5147).

EDIT:
Reverted conditional part: on 32bit systems there are also problems with optimization of "defaults.cpp", not as much memory needed as on 64bit, but way to much for most build-systems.
Sorry for the inconvenience.

It looks like I found a much better solution than to manually autobuild-system for one target:

I overworked "defaults.cpp" so that all names and headers are in a StringArray and get applied in a loop.
It was just a little bit of search and replace and put some variables and loops to it.

It might make sense to put the loops in an own function, to avoid to have the same code multiple times.
But it's a little late now and I will have a hard week at work and therefore I had to go to bed now.

So I just attach the 7zipped "defaults.cpp".

@Martin: please have a look at it, if you find the time.

Btw. compile time with optimization is about 1-2 seconds on my system.

[attachment deleted by admin]

[MortenMacFly]

Dear All, I would advice to stop using this nightly build. I have discovered a serious regression due to rev 5124. We hope to have it fixed in tomorrows nightly.

...which one? It works nice here...?!

Edit: Found the other post... ignore this question... I am looking into it.

[MortenMacFly]

@Martin: please have a look at it, if you find the time.

I had a look at it. The code sucks now (it looks ugly and is not anything I would like to have in my projects) but if the compiler is happy with it, then I am, too. Just commit I have no more complains.

I wonder if we should report this to the GCC gurus. I really would like to know why the slowdown really occurs. I mean: This is very simply code, so why the hell can any optimisation algorithm on that piece of code can freak out like that?!

[MortenMacFly]

Dear All, I would advice to stop using this nightly build. I have discovered a serious regression due to rev 5124. We hope to have it fixed in tomorrows nightly.

Good news! We have fixed this in R5149.
@killerbot: Probably another nightly as of today...?! ;-)

Ps.: Sorry for this. My fault.

[killerbot]

I am in a rush now, so nightly of tomorrow (maybe tomorrow morning ;-) )

[MortenMacFly]

I am in a rush now, so nightly of tomorrow (maybe tomorrow morning ;-) )

So it's probably going to be a "morningly"... :lol:
Just take your time...