Missing -fPic option in codeblocks project

[teto]

Hi,

I think there is a missing "-fPic" option in the codeblocks project for linux fast math build. After adding it, the build works.

I take advantage of this post to ask for a little improvement - from my point of view - but maybe I am the only one working this way: I like to keep "debug" and "release" builds separated (because of compilation speed, it allows to have a WIP version and a working one etc...), for Irrlicht and for the final game as well .
With the current targets, when you build the debug version, it erases the release one (both are called libIrrlicht.so/dll). I wonder if it would be possible to have the debug target called differently, for example libIrrlichtDebug.so ?


I've seen other projects (SFML for example but I doubt it is the only one) doing this.

Well that's not a big deal if not possible, I will keep modifying the project ^^

Matt

[Bl00drav3n]

Would be nice if the build targets would be seperated. I modified the cbp too so that it outputs Irrlicht.a and Irrlichtd.a seperatly.

[hendu]

Why bother? For me the debug build is simply the release build with -g. Shipping is just a strip away.

[CuteAlien]

Thanks, I've changed it in svn trunk.

Build targets with different names have some advantages, some disadvantages. I guess some day we switch to cmake anyway (when it's C::B support starts being good enough) and maybe we can consider doing such changes then.

[hendu]

Please no, cmake is absolutely horrible for cross-compiling (mingw on linux, for example). It's not exactly nice for native builds either, with some customizations like install dirs or flags being very difficult to make it obey.

[CuteAlien]

Maybe we should write our own scripts to modify project files, but I guess that's pretty much the idea behind CMake. The problem is that we have lots of projects files which are affected on each change and cmake would theoretically allow us to get rid of that. Also people using unsupported IDE's (Eclipse mostly) would it have easier then. But yeah - results of CMake are still far from optimal in some cases, which is why I also stopped using it again in own projects. Certainly we could just add cmake files additionally - but that would mean supporting even one more project file.

I guess there's no perfect solution for this yet.

[hendu]

Solution is to not to use project files. Most IDEs can be made to call "make".

[CuteAlien]

That's not a solution - I can use CMake to generate makesfiles. But then you lose the features that make it worth using an IDE.

[hybrid]

I think the idea was to set up a generic project file for each IDE, and configure the file in such a way that all Irrlicht specific things are defined and configured in the Makefile. Just use, e.g., the c::b targets to call different makefile targets. This would be, to some extent, a more generic solution that what we have now. But I also see the downsides such as requiring the end user to deal with Makefiles if certain special configs are required. And that's probably enough downside already to skip this way. CMake could reduce the overall number of project files, though, in case we can generate the more exotic project files to CMake versions and only maintain two or three important tools manually.