The 17 June 2012 build (8059) is out.

[raynebc]

Can you provide a minimal test case?

I opened one of my old projects that had only one source file.  I added a second source file to it and when I did a full rebuild of the project, it compiled them out of alphabetical order.  Both files had a build priority weight of 50, but even after I set the priority for each file to 0, they still built out of alphabetical order.  I don't think I can really simplify the problem further, since two files is the minimum for this problem to even be possible.

[stahta01]

Possible build issue on Windows.

Building the SDK now causes an zip command error on post build steps.
Happens if the folders CodeBlocks does not exist.
Months ago, the problem did not exist.
Now, I have to create the folders  share/CodeBlocks or run the update.bat after I delete or rename the devel folder.

Code

zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc

Note: It is possible the zip command I used has changed.

Tim S.

[ollydbg]

Possible build issue on Windows.

Building the SDK now causes an zip command error on post build steps.
Happens if the folders CodeBlocks does not exist.
Months ago, the problem did not exist.
Now, I have to create the folders  share/CodeBlocks or run the update.bat after I delete or rename the devel folder.

Code

zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc

I have the same error here: When build C::B (from a refresh git clone)

See the log:

Creating library file: devel\libcodeblocks.a
Output size is 52.62 MB
[ 50.0%] Running target post-build steps
[100.0%] zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
zip I/O error: No such file or directory
zip error: Could not create output file (devel/share/CodeBlocks/manager_resources.zip)
Process terminated with status 15 (13 minutes, 41 seconds)
0 errors, 16 warnings (13 minutes, 41 seconds)

Can zip command automatically create a folder?

[Jenna]

Can zip command automatically create a folder?

I think we should revert the commit 7972 completely and instead call update[.bat] from the projects post-build step.
Or would this break anything else ?
If I understand correctly, this patch was made to be able to run C::B from inside (or outside) without explicitely call update[.bat], to avoid crashes because of missing xrc-files.

It never made it into linux by the way.

[ollydbg]

Can zip command automatically create a folder?

I think we should revert the commit 7972 completely and instead call update[.bat] from the projects post-build step.
Or would this break anything else ?
If I understand correctly, this patch was made to be able to run C::B from inside (or outside) without explicitely call update[.bat], to avoid crashes because of missing xrc-files.

It never made it into linux by the way.

After I read the file "update.bat", I agree with you. "update.bat" do more things than just compact the xrc files.

call update[.bat] from the projects post-build step

If so, which target can we put the "update.bat" in post-build step?

[Jenna]

If so, which target can we put the "update.bat" in post-build step?

[...] call update[.bat] from the projects post-build step.

[japplegame]

There is critical bug in C++ parser. If you insert "magic" code in any unit/header file (included in C++ project) then Code::Blocks will hangs up.
Magic code (copy exactly all quote):

    typedef std::enable_if<N > 1, get_type_N<N-1, Tail...>> type;

Looks like parser gets stuck on "N > 1". If to surround it by parentheses, then all works fine.

[MortenMacFly]

If I understand correctly, this patch was made to be able to run C::B from inside (or outside) without explicitely call update[.bat], to avoid crashes because of missing xrc-files.

True. We basically use two ways to update the resources in all plugins / projects: Either we call an update.bat or we zip the resources form inside the project's post-build steps (in that case these steps should always be executed - that is a common error).
So I see two solutions: Either we add a pre-build command which creates the required output folders OR we run update.bat as project's post-build step as Jens suggested. The latter has one drawback though: If you compile a specific target (like I do sometimes) this won't work probably. That's why I liked the idea of having the steps bound to the targets. So I tend to solution 1: Add the creation of that output folders either to the pre- or post-build steps.

[Jenna]

[...]
The latter has one drawback though: If you compile a specific target (like I do sometimes) this won't work probably.
[...]

What does not work ?
A project postbuild step should be executed for single targets and for the whole project.
And normally it should be enough to execute it only if the target project was not uptodate.

[stahta01]

Calling update.bat will mean that the output folder copy of Code::Blocks can not be used to build the devel copy of code::blocks.

Tim S.

[ptDev]

If the required directory structure is to be created from pre- and post-build steps by the plugin projects, maybe adding those steps to the C::B plugin project generated by the wizard would be a good idea.

[Jenna]

If the required directory structure is to be created from pre- and post-build steps by the plugin projects, maybe adding those steps to the C::B plugin project generated by the wizard would be a good idea.

the wizard created plugins should create a cbplugin-file (packed library and resources), that can be installed by C::B's pluginmanager.
Doing this in pre- and postbuild steps would make the compiled plugins undeployable.

[ptDev]

If the required directory structure is to be created from pre- and post-build steps by the plugin projects, maybe adding those steps to the C::B plugin project generated by the wizard would be a good idea.

the wizard created plugins should create a cbplugin-file (packed library and resources), that can be installed by C::B's pluginmanager.
Doing this in pre- and postbuild steps would make the compiled plugins undeployable.

I don't understand what the problem is.
Doing it in the pre- and postbuild steps instead of in deployment would break deployment, of course. But if this step is also done when a build is done, it would make development much easier.

[ollydbg]

So I tend to solution 1: Add the creation of that output folders either to the pre- or post-build steps.

I like this solution, because I think each target should contain its own "update" script(not copy or zip other target's data).
I think put the creation of folders in the target's post-build step is better than pre-build

This can also solve the problem as Tim said:

Calling update.bat will mean that the output folder copy of Code::Blocks can not be used to build the devel copy of code::blocks.

Tim S.

Mainly, the update.bat do three things:
1, create necessary folders under devel folder
2, copy/zip necessary XRC files to devel folder
3, copy all the necessary files from devel folder to output folder, and run strip.

I think the step 3 is not necessary when I'm developing/debugging C::B.

[ollydbg]

There is critical bug in C++ parser. If you insert "magic" code in any unit/header file (included in C++ project) then Code::Blocks will hangs up.
Magic code (copy exactly all quote):

    typedef std::enable_if<N > 1, get_type_N<N-1, Tail...>> type;

Looks like parser gets stuck on "N > 1". If to surround it by parentheses, then all works fine.

The code is toooooo magic for me that I can't understand the grammar, but the parser should not hang in any case, so I will dig into it.