Irrlicht Engine

Why is it that when compiling with the static builds on release/debug mode output the same file name? The compiler option for "Target Name" should really be set to output different file names when compiling with release vs debug.

For example, release mode would just output "Irrlicht.lib" where as debug mode would output "Irrlicht_Debug.lib" then we could do things like this: Making it painfully easy to compile our own applications on release/debug mode.

The same could even be said for the .dll builds, then you would just have the correct .dll in your release and debug folders.

if you are using visual studio you can add the vs project file for irrlicht to your solution and chain the build

if done properly you can have visual studio compile everything and dump everything in your target directory so changing debug to release is as easy as flipping it on top of the IDE

I pity the fools using Windows

Here in Linuxland every build is a debug build, and making it a so-called "release build" is done in a second by stripping it. That also works with mingw btw.

Granyte wrote:if you are using visual studio you can add the vs project file for irrlicht to your solution and chain the build

if done properly you can have visual studio compile everything and dump everything in your target directory so changing debug to release is as easy as flipping it on top of the IDE

That would clutter up your own projects Solution Explorer. It would still require you to change Irrlicht's build configuration and change it every time a new version of Irrlicht is released. It would be much simpler to just make the simple change to the project once and be done with it. Don't you think?

well i'm plugged straight on the svn and prevented tortoise from changing the project file when updating so I changed it only once and it will never be modified unless I ask for it

Sure that works but requires users to set up, what I'm proposing works out of the box and quite frankly, it should already be like this. :)

I personnally had a script changing the debug name of both static and dynamic target names to "Irrlich_d" (also for the .lib name, and the .pdb name). Sadly, I lost that script long ago in a computer crash, so now I just modify it by hand sometimes (when there are no added/deleted files in the revision). But I think it could be very beneficial to have a "_d" appended.

Thinking about it, the best would be to use something like CMake.

@hendu:

Here in Linuxland every build is a debug build, and making it a so-called "release build" is done in a second by stripping it. That also works with mingw btw.

I don't understand. You mean that release builds are done by only removing the debug symbols ?

I don't understand. You mean that release builds are done by only removing the debug symbols ?

Yes. Makes things quite simple.

Nonetheless darktib is right, it would be beneficial to at least have an _d appended.

hendu wrote:

I don't understand. You mean that release builds are done by only removing the debug symbols ?

Yes. Makes things quite simple.

That's a horrible idea. Debug and release builds exist for a reason. What about optimizations ? and optimization of dependencies (the CRT, for instance) ?

Or maybe you were sarcastic and I didn't see this one !

Debug builds still contain things like line number data. They usually also contain runtime checks, eg, zeroing the stack frame on entry. Stripping symbols does not create a release build from a debug build.

It is a pointless distinction in most cases. In all these years I have come across one or two issues that could not be debugged at full optimization.

The line numbers are part of debug symbols, and there is no special debug libc on linux that would do things like poison freed memory (to be entirely correct, the debug libc is intended for debugging the libc, useless for apps). In fact I could argue that VS is doing a disservice by having special debug libs with those properties, resulting in countless "it doesn't work in release mode" noob questions.

Move to a platform that has valgrind and be happy

Having debug build relying on #ifdef DEBUG or #ifdef NDEBUG all over the code is a blight.
Every preprocessor branch is possibly a new potential bug, also depending on multiple libraries depending on the build is even worse: you have to make sure everything is synched, also: every target will just double number of builds depending on every platform you support.

You should seriousy think about improving your pipeline.

The only difference in debug build should be few compiler options at most, and eventually few helper macros (like assert) without compiler directives spreading all over your files (that also makes your code unreadable).

the Most stuff you can automate without touching you source code better it is, this all depends on your environment and how you use it.

with GCC you just have to use 2/3 different compiler options when creating the target.
- Generate debug symbols : allow debugging with GNU tools
- Generate profile symbols : allow Gproof profiling
- Strip symbols : remove all non-externally visible symbols to reduce binary size (also override the options to generate debug and profile symbols)
- Optimizations : (- Os -O1 -O2 etc..) usually optimizations are not enable with debug symbols

I think hendu was referring to that (stripping is about generating a new binary without something, not about removing something from a pre-made binary)

One exception to what I said is having some overlay text in your application that shows what kind of build you are running (version number. debug? profile? release?) but you should never rely on manually changing compiler options for every build.

I think the point is being missed here. Compiling Irrlicht using it's debug build outputs a ton of extra information into your console at runtime. Adding a distinction between the output files when compiling Irrlicht in it's debug or release form alleviates you from the hassle of having to either recompile it each time you need that information or having to manually move the compiled debug/release build file into your project directory. All I propose is a little way to save a little time and it wouldn't hurt anything. I was really trying to refrain from saying this but every other library I use does this and it makes my life a little easier, I'm sure most if not all the libraries you guys use do the same thing.

Every preprocessor branch is possibly a new potential bug

And every line of code is a potential disaster. If well done, preprocessor can be really useful (and DEBUG or NDEBUG sometimes are really useful).

with GCC you just have to use 2/3 different compiler options when creating the target.
- Generate debug symbols : allow debugging with GNU tools
- Generate profile symbols : allow Gproof profiling
- Strip symbols : remove all non-externally visible symbols to reduce binary size (also override the options to generate debug and profile symbols)
- Optimizations : (- Os -O1 -O2 etc..) usually optimizations are not enable with debug symbols

That's roughly the same for visual c++. and also for clang. except options about floating-point model, architecture, vectorization and so on...

I think hendu was referring to that (stripping is about generating a new binary without something, not about removing something from a pre-made binary)

Maybe I misunderstood something then (english is not my mother language...). Still not sure.

Back to the point: I really think Irrlicht could use a CMake script, for those reasons:
- ability to put project files not in source tree
- ability to use the toolchain you want
- way easier to maintain (devs don't have to maintain a dozen different project files, just one script)
- more control (it would be possible to include a "build_all" option that would build Irrlicht + examples + documentation - in all possible configs, ie Release, Debug [_d], ReleaseWithDebugInfo [_rd] and MinSizeRelease [_rm])