Hi there,
I was thinking of using CMake for building Irrlicht (the default build seems to be debug on GNU/Linux), and just found out that Erwin Coumans has already done the setup for his small project GameKit.
CMake is pretty convenient and one of the easiest solutions today, and I was wondering if you admins would consider adding (and using) it very soon. I can commit a first version if needed (I'll probably code it for my project anyway). Dunno when the 1.6 version is due, but it can be done quickly.
The only issue is that the multi-configuration system in Visual Studio is, in my experience, difficult to replicate in the same way as on other targets. If there is no clean enough solution, separate VC7/8/9 solutions and projects may be necessary. In any case, the nmake target (visual studio command line makefiles) works as well as the other targets.
cheers, thanks and keep up the good work
armando
standardizing on CMake short-term ?
Last time I tried CMake it had more issues. I wanted to use it because it had (among others) CodeBlocks support. But it turned out that support was limited to creating Makefile which could be called from CodeBlocks which is rather pointless as you basically drop all the IDE features that way. Once it starts creating real project files for c::b which actually work I would get interested in it again. The basic idea of creating native project files for all sort IDEs is nice. I would also be interested in other build-systems which can do that.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Hi,
I'll give it a try and send you what I have on this post probably later this week.
As for other good/promising systems, I would indicate the following:
- cmake/lua
- waf
-boost::build v2 with python
- scons (but I've read it was dropped from a project in favor of cmake..)
because all three are 'next-gen', i.e they're leveraging a full-fledged language, be it Lua or Python. They're in development but as Irrlicht build needs are pretty straightforward, perhaps their features are sufficient.
For now, some good references are using CMake : KDE, OpenSceneGraph, Bullet.
ciao,
armando
I'll give it a try and send you what I have on this post probably later this week.
As for other good/promising systems, I would indicate the following:
- cmake/lua
- waf
-boost::build v2 with python
- scons (but I've read it was dropped from a project in favor of cmake..)
because all three are 'next-gen', i.e they're leveraging a full-fledged language, be it Lua or Python. They're in development but as Irrlicht build needs are pretty straightforward, perhaps their features are sufficient.
For now, some good references are using CMake : KDE, OpenSceneGraph, Bullet.
ciao,
armando
CMake support first version completed
Hi again,
here is my work, with a readme that include the 'known issues' (see attached archive).
It is working and tested on {debug, release} x {static, shared} x {gnu/linux makefiles, CodeBlocks linux/win32-mingw, Visual Studio 2005, Microsoft nmake makefiles}. Library and examples are done, while tests and tools are missing for now. MacOS, Xbox and others untested.
As expected, some caveats on Visual Studio (messy file grouping, unrecognized config-postfixed install output directory); also, a codeblocks project per config is needed. Generally, I think existing Codeblocks and Visual Studio users may still use your tailored project files, and maybe transition later ; so, are you willing to propose both systems (existing and cmake) for this version ?
Otherwise, the current state is usable at least for me and probably welcomed by others ;)
Two quick remarks on the whole 'build/install dir per configuration' implications:
- there should be no need for platform subdirectories in the bin and lib folders or Irrlicht. Or you have to add all combinations of: os, compiler, config (debug/release/profiling/shipping/etc), arch (x86/x64), static/shared . Which is a lot. Separate build dirs are better IMHO !
- I setup the headers install to prefix/Irrlicht, so that it is compatible with installation in /usr/local . But ideally that would mean having the #include <Irrlicht.h> statements replaced with #include <Irrlicht/Irrlicht.h> . This is done by Qt, osg and many others but it would break existing client code, safe for a build file include dir adjustment or include statement correction.
Last notes:
- I had to patch two #if !defined (__MINGW32__) for win32 codeblocks mingw build. Patch is attached also.
- I had a compile error on example 17 (mobile) on some windows compiler or all.. you can edit its CMakeLists.txt or rename the directory to skip it.
TODO next:
- install media/ , pack installer/zip with CPack ?
- add tests and tools. Use CTest if compatible ?
hope this is clear enough..
The files are here (click on "Telecharger ce fichier"), they will expire in a month :
- myCMakeList.tar.gz, containing all CMakeLists.txt in subdirs, to unpack in Irrlicht root dir : http://dl.free.fr/a1pmmFO83 .
- readme_build_cmake.txt: http://dl.free.fr/aC0RbAW4K
- irrlicht.cpp patch for codeblocks mingw32: http://dl.free.fr/oewmruQBz
armand
here is my work, with a readme that include the 'known issues' (see attached archive).
It is working and tested on {debug, release} x {static, shared} x {gnu/linux makefiles, CodeBlocks linux/win32-mingw, Visual Studio 2005, Microsoft nmake makefiles}. Library and examples are done, while tests and tools are missing for now. MacOS, Xbox and others untested.
As expected, some caveats on Visual Studio (messy file grouping, unrecognized config-postfixed install output directory); also, a codeblocks project per config is needed. Generally, I think existing Codeblocks and Visual Studio users may still use your tailored project files, and maybe transition later ; so, are you willing to propose both systems (existing and cmake) for this version ?
Otherwise, the current state is usable at least for me and probably welcomed by others ;)
Two quick remarks on the whole 'build/install dir per configuration' implications:
- there should be no need for platform subdirectories in the bin and lib folders or Irrlicht. Or you have to add all combinations of: os, compiler, config (debug/release/profiling/shipping/etc), arch (x86/x64), static/shared . Which is a lot. Separate build dirs are better IMHO !
- I setup the headers install to prefix/Irrlicht, so that it is compatible with installation in /usr/local . But ideally that would mean having the #include <Irrlicht.h> statements replaced with #include <Irrlicht/Irrlicht.h> . This is done by Qt, osg and many others but it would break existing client code, safe for a build file include dir adjustment or include statement correction.
Last notes:
- I had to patch two #if !defined (__MINGW32__) for win32 codeblocks mingw build. Patch is attached also.
- I had a compile error on example 17 (mobile) on some windows compiler or all.. you can edit its CMakeLists.txt or rename the directory to skip it.
TODO next:
- install media/ , pack installer/zip with CPack ?
- add tests and tools. Use CTest if compatible ?
hope this is clear enough..
The files are here (click on "Telecharger ce fichier"), they will expire in a month :
- myCMakeList.tar.gz, containing all CMakeLists.txt in subdirs, to unpack in Irrlicht root dir : http://dl.free.fr/a1pmmFO83 .
- readme_build_cmake.txt: http://dl.free.fr/aC0RbAW4K
- irrlicht.cpp patch for codeblocks mingw32: http://dl.free.fr/oewmruQBz
armand
Re: CMake support first version completed
Thanks, it's certainly interesting work. Couldn't test it yet, but I got some questions:
First about Code::Blocks - do you know if cmake can by now generate real project files for C::B which allow debugging, searching in all project files, etc, or does it still just create empty project files which then refer to a Makefile?
First about Code::Blocks - do you know if cmake can by now generate real project files for C::B which allow debugging, searching in all project files, etc, or does it still just create empty project files which then refer to a Makefile?
Not exactly sure what you mean here. You mean keeping an own directory for each version? I have to do that already for 2 of the versions (because VS is the only Windows application not working with the ext2 filesystem I'm using) and it's a real pain to keep those synchronized. What would be the problem of adding all combinations? I usually do that in my projects and it's not been a problem so far. Allows me to work with a single project file, switching by a single menu-click in most IDE's and doesn't create conflicts or any hassle to keep stuff synchronized. But maybe I misunderstood you here...armandf wrote: Two quick remarks on the whole 'build/install dir per configuration' implications:
- there should be no need for platform subdirectories in the bin and lib folders or Irrlicht. Or you have to add all combinations of: os, compiler, config (debug/release/profiling/shipping/etc), arch (x86/x64), static/shared . Which is a lot. Separate build dirs are better IMHO !
Mhm, I already noticed that most libraries seem to do that by now. Might be something to consider also for Irrlicht, I would like it.armandf wrote: - I setup the headers install to prefix/Irrlicht, so that it is compatible with installation in /usr/local . But ideally that would mean having the #include <Irrlicht.h> statements replaced with #include <Irrlicht/Irrlicht.h> . This is done by Qt, osg and many others but it would break existing client code, safe for a build file include dir adjustment or include statement correction.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
hey,
1. the code::blocks projects have all the files (albeit in a dir structure rather than custom groups), so you can search/open/build/run/exec . It will probably be necessary to edit a parameter or two (the working dir and maybe the LD_LIBRARY_PATH on Linux) in order to start the example binaries.
It still uses a simple Makefile behind the scenes, which I think is a good thing (you can for instance build without the editor, just run 'make').
An important node: I'm not sure CMake supports codeblocks with other compilers (visual studio, intel compiler).. To test. If not supported, it will just be useful as a glorified editor with search/auto-open and CTags. Building and running will be done in the command-line (or by adding a custom command to the IDE tools).
Also, as I noted in my previous post, you'll need to have a codeblocks directory and project for the debug build, and another one for the release build. You'll hate this, but see point 2.
2. What I mean is that :
a) with Visual studio and some other IDEs, you have one directory with the source, the project files, the intermediate build files, the build output, and the final install files. All configs (debug-static-x86 /release-static-x86 / debug-shared-x86 / etc. ) are in various subdirectories.
This approach is consistent with having the install results in the same directory as the sources, and then you need to have subfolders in Irrlicht/lib (Win32-VisualStudio, Win64-VisualStudio, gcc, Linux (!?)). By the way you're missing a lot here (release/static, x86/x64, debug/release), and it's not consistent (shoud the linux gcc output go to gcc or linux ?).
b) with CMake and the common practices in the unix world, it is very different. You'll usually have:
- a single, non-modified source directory
- for each config (configuration-plaftorm-arch-compiler combo), a build directory with the configured makefiles and intermediate build files
- for each config, an install directory with the headers in subdir 'include', the output libs in 'lib', and the output binaries in 'bin'.
It is important to note that with this approach, you don't need to have plaftorm subfolders in those 'lib' and 'bin' output directories, because you will simply have different install directories for those different configurations (each with its include, bin, lib folders).
I know people used to IDEs may prefer their way (as you say, just need a click to change config) and may not want to change ; I respect that. CMake kind of enforces the second approach. I don't have a problem with it because it works well with Unix workflows. (You can automate things much more easily, you can manage several dependencies for a project (say, Bullet and Irrlicht) in exactly the same way because you'll have a debug install dir with Bullet and Irrlicht in it, and a release install dir with bullet and Irrlicht in it..)
That leads me to propose that we propose both systems for now. Forcing CMake on you and everybody would not be user-friendly.. Let people try it and choose ! But let me just say that the CMake approach, however weird it may seem to you, is very convenient for others. Already now, it is much easier setting up multiple builds of Irrlicht in 2 minutes on Linux than copying the whole source folder for debug and release and then hacking the makefiles.
I don't have the time to fully detail the sample directory structures with both approaches.. let me know if it's not clear. Also, please see the OpenSceneGraph build instructions, they will probably speak of separate build/install directories.
A final thing I forgot: there are problems when you try to install multiple configurations in the same output prefix : you'll need to have '_d' postfix for the debug libraries/binaries (and later _p for profiling, _v for verbose.. ? which creates a problem for building the final binaries in all versions). Also on Win32, the static library name conflicts with the shared library import file ; so successive build override each other, so in the end you are forced to have separate install dirs.
cheers
armand
1. the code::blocks projects have all the files (albeit in a dir structure rather than custom groups), so you can search/open/build/run/exec . It will probably be necessary to edit a parameter or two (the working dir and maybe the LD_LIBRARY_PATH on Linux) in order to start the example binaries.
It still uses a simple Makefile behind the scenes, which I think is a good thing (you can for instance build without the editor, just run 'make').
An important node: I'm not sure CMake supports codeblocks with other compilers (visual studio, intel compiler).. To test. If not supported, it will just be useful as a glorified editor with search/auto-open and CTags. Building and running will be done in the command-line (or by adding a custom command to the IDE tools).
Also, as I noted in my previous post, you'll need to have a codeblocks directory and project for the debug build, and another one for the release build. You'll hate this, but see point 2.
2. What I mean is that :
a) with Visual studio and some other IDEs, you have one directory with the source, the project files, the intermediate build files, the build output, and the final install files. All configs (debug-static-x86 /release-static-x86 / debug-shared-x86 / etc. ) are in various subdirectories.
This approach is consistent with having the install results in the same directory as the sources, and then you need to have subfolders in Irrlicht/lib (Win32-VisualStudio, Win64-VisualStudio, gcc, Linux (!?)). By the way you're missing a lot here (release/static, x86/x64, debug/release), and it's not consistent (shoud the linux gcc output go to gcc or linux ?).
b) with CMake and the common practices in the unix world, it is very different. You'll usually have:
- a single, non-modified source directory
- for each config (configuration-plaftorm-arch-compiler combo), a build directory with the configured makefiles and intermediate build files
- for each config, an install directory with the headers in subdir 'include', the output libs in 'lib', and the output binaries in 'bin'.
It is important to note that with this approach, you don't need to have plaftorm subfolders in those 'lib' and 'bin' output directories, because you will simply have different install directories for those different configurations (each with its include, bin, lib folders).
I know people used to IDEs may prefer their way (as you say, just need a click to change config) and may not want to change ; I respect that. CMake kind of enforces the second approach. I don't have a problem with it because it works well with Unix workflows. (You can automate things much more easily, you can manage several dependencies for a project (say, Bullet and Irrlicht) in exactly the same way because you'll have a debug install dir with Bullet and Irrlicht in it, and a release install dir with bullet and Irrlicht in it..)
That leads me to propose that we propose both systems for now. Forcing CMake on you and everybody would not be user-friendly.. Let people try it and choose ! But let me just say that the CMake approach, however weird it may seem to you, is very convenient for others. Already now, it is much easier setting up multiple builds of Irrlicht in 2 minutes on Linux than copying the whole source folder for debug and release and then hacking the makefiles.
I don't have the time to fully detail the sample directory structures with both approaches.. let me know if it's not clear. Also, please see the OpenSceneGraph build instructions, they will probably speak of separate build/install directories.
A final thing I forgot: there are problems when you try to install multiple configurations in the same output prefix : you'll need to have '_d' postfix for the debug libraries/binaries (and later _p for profiling, _v for verbose.. ? which creates a problem for building the final binaries in all versions). Also on Win32, the static library name conflicts with the shared library import file ; so successive build override each other, so in the end you are forced to have separate install dirs.
cheers
armand
Thanks for all the info. I guess I will experiment myself some more to find out about C::B support as that was one of the major problems I had last time (and as usual not really time before weekend, but maybe someone else from team plays with it before me). But doesn't sound too bad except the targets stuff (which would kill it for me).
I hope targets in C::B will be supported in CMake some day - they were already possible for VS for a while. So can't replace our current solutions yet - for now it's just one more configuration - but still in the long run CMake might help to replace other project files. For now it would at least allow some more project files (like KDevelop).
About non-gcc support in c::b - I'm not sure - but I think we haven't c::b support for other compilers anyway so far (but I would to have check).
And yeah - folder names are maybe not consistent yet. I use a lot more folder names in my own projects like "mingw_gcc release static". I'm also using names like IrrlichtD, etc. - not sure why you see that as problem - I think it's rather nice. Final binaries are simply named the same: myProject and myProjectD (or even more names depending on setup). I find having the same name for different versions more confusing.
edit: OK, I think I got the build-dir thing wrong at first.
You mean we have a build directory per configuration? I first thougth we already do that in Irrlicht, but I noticed by now that I only do that in my own customized version :-) So I'm all for that! I'm just a little confused as you don't seem to like all the different names, but that's only for install dirs - for build dirs all the names are also ok for you, right?
I understand it is currently trouble when using Makefiles as in that case it is like you wrote and you have to hack Makefiles and it's hard to keep more than one. This is indeed a disadvantage of the current solution (the main advantage being that it is currently really-really trivial to build Irrlicht on most systems without confusing beginners).
Setting up multiple builds in C::B is actually easier. I guess I could even beat your 2 minutes there ;-) Create a virtual target -> add all targets wanted in it. Click on compile :-) And afterwards it's always just a single click (in my current project target linux_all creates for example 5 different Irrlicht versions and has for each just to compile the changed files).
Something I don't remember anymore (or wasn't ever that sure back when I used CMake ...). Does CMake expect to be run on the user computer? So we wouldn't run it on our system and then deliver the resulting Projectfiles/Makefiles but it would be about delivering the CMakeLists and users build the Projectfiles/Makesfiles on their computer with ccmake? Or am I wrong there?
Also - will your solution overwrite any of the the current Makefiles or Projectfiles when run? I will find out anyway soon ...but asking here might save someone trouble who just runs it ;-)
I hope targets in C::B will be supported in CMake some day - they were already possible for VS for a while. So can't replace our current solutions yet - for now it's just one more configuration - but still in the long run CMake might help to replace other project files. For now it would at least allow some more project files (like KDevelop).
About non-gcc support in c::b - I'm not sure - but I think we haven't c::b support for other compilers anyway so far (but I would to have check).
And yeah - folder names are maybe not consistent yet. I use a lot more folder names in my own projects like "mingw_gcc release static". I'm also using names like IrrlichtD, etc. - not sure why you see that as problem - I think it's rather nice. Final binaries are simply named the same: myProject and myProjectD (or even more names depending on setup). I find having the same name for different versions more confusing.
edit: OK, I think I got the build-dir thing wrong at first.
You mean we have a build directory per configuration? I first thougth we already do that in Irrlicht, but I noticed by now that I only do that in my own customized version :-) So I'm all for that! I'm just a little confused as you don't seem to like all the different names, but that's only for install dirs - for build dirs all the names are also ok for you, right?
I understand it is currently trouble when using Makefiles as in that case it is like you wrote and you have to hack Makefiles and it's hard to keep more than one. This is indeed a disadvantage of the current solution (the main advantage being that it is currently really-really trivial to build Irrlicht on most systems without confusing beginners).
Setting up multiple builds in C::B is actually easier. I guess I could even beat your 2 minutes there ;-) Create a virtual target -> add all targets wanted in it. Click on compile :-) And afterwards it's always just a single click (in my current project target linux_all creates for example 5 different Irrlicht versions and has for each just to compile the changed files).
Something I don't remember anymore (or wasn't ever that sure back when I used CMake ...). Does CMake expect to be run on the user computer? So we wouldn't run it on our system and then deliver the resulting Projectfiles/Makefiles but it would be about delivering the CMakeLists and users build the Projectfiles/Makesfiles on their computer with ccmake? Or am I wrong there?
Also - will your solution overwrite any of the the current Makefiles or Projectfiles when run? I will find out anyway soon ...but asking here might save someone trouble who just runs it ;-)
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Ok, I also have a better understanding of your take on this.
1. I agree that a in-source build with multiple configs and one destination dir (the existing solution) has its advantages. It is simple, already-setup and easy for newcomers. And I won't beat your CodeBlocks virtual target magic (mine is a bash or python script ! or a .bat ..). That's why I think we should keep the current makefiles and projects for at least a version or two, maybe more or indefinitely (I'll come back on this below).
On the other hand, it can be seen by some as having a rigid workflow, it imposes naming and a set of build configurations. Creating a new config is more work for the user because the different lib names will have to be set in every client program.
2. Let me address your last two questions in one shot:
- Yes, CMake can be used by the dev team (you) to pre-generate project files for many platforms and configurations. There is a flag to CMake that tells it to generate 'final' makefiles or projects without auto-regeneration ; and you don't even need to provide the CMakeLists.txt sources.
In this approach, the generated project files would be redundant with the existing tailored projects and makefiles, so yes, they would 'overwrite' the current ones (there would be a choice to be made). And we would have to make a number of decisions regarding the naming of directories, the config postfixes (D or _d, etc.).
- But, I was mainly thinking of the other, simpler use of CMake: that is, to provide the CMakeLists.txt only (don't generate any project files), and the user generates his/her project or makefiles. This requires to have CMake installed, and to run it as many times as the plaftorm/configs (or a single time for MSVC), but the advantages are great:
a) You don't need to provide all the possible platform/config combinations project files and directories ! Indeed, the user will choose himself the build directory names, and he/she will usually need only one platform-compiler-arch per install, and will usually have chosen one of static or shared, so he/she will just have as many builds as configurations (debug/release/optim ..) but not more than that.
b) Also, this way, the user can also choose his workflow: whether to use multiple dirs or to install all things in one place in a similar way as the current system (yes, it is possible to do that with CMake with some work and most importantly, hard-coded 'decisions'). If opting for a single build/install dir he can choose the postfix and the directory naming (CMake has options for that, you can see in my files that there is commented code for that - look for IRR_NO_D_SUFFIX).
c) This allows to keep the currently provided build files exactly unchanged, which is desirable for the next version so that users don't need to change anything. The CMakeLists.txt are just there in addition, to be used by those who choose it. EDIT: and it is recommended to build out of source, and install out of source (in a common lib dir of the system or of the client game project), so that it leaves things clean and allows having the standard build and install in-source at the same-time.
3. Here is what I would suggest for right now:
- keep all currently provided makefiles and project files as-is.
- add the CMakeLists.txt (as in the archive I sent), but don't pre-generate any project files.
Then, later, with user approval, perhaps some currently provided projects or makefiles will be replaced by CMake pre-generated equivalents. This can be done soon for the current unix makefiles, but the CodeBlocks/Visual Studio situation is more complex due to that difference of methodology, so I guess both solutions would stay (or, CMakeLists.txt can be adapted to support the single build/install dir, but choices need to be made concerning the naming, that could have been user choices otherwise).
Again, as a reference, you can see that Bullet provides already generated project files (hand-made or CMake, I don't know), but in addition to that they also give the CMakeLists.txt (and also Jam files ! and automake files ! they're crazy). But additional projects can be required for specific platforms (Codewarrior/Wii, etc.). PS3 and Xbox360 are maybe supported transparently with the Visual Studio and its add-ins. To be confirmed.
So here it is, I hope the team reaches a consensus on this minimal-change scenario.
cheers,
Armand
PS: as an appendix, just to make my point on the hassle of having a correct set of lib and bin directories when building in-source and providing all the projects: yes I believe the current state of build dirs is inconsistent and lacking (with all due respect to the authors, I know how development works ;) ) . You would need all the following directories both in /lib and /bin (under each of those you'd have all the examples, or alternatively you would have all the following under each example dir):
vc7.1_mt_debug_static
vc7.1_mt_release_static
vc7.1_mtdll_debug_static
vc7.1_mtdll_debug_dll
vc7.1_mtdll_release_static
vc7.1_mtdll_release_dll
vc8_sp1_mtdll_debug_static
vc8_sp1_mtdll_debug_dll
vc8_sp1_mtdll_release_static
vc8_sp1_mtdll_release_dll
vc8_sp1_mtdll_debug_static_x64
vc8_sp1_mtdll_debug_dll_x64
vc8_sp1_mtdll_release_static_x64
vc8_sp1_mtdll_release_dll_x64
vc8_sp1_debug_static_xbox
vc8_sp1_release_static_xbox
vc8_sp1_profile_static_xbox
vc8_sp1_shipping_static_xbox
vc9_sp1_mtdll_debug_static
vc9_sp1_mtdll_debug_dll
vc9_sp1_mtdll_release_static
vc9_sp1_mtdll_release_dll
vc9_sp1_mtdll_debug_static_x64
vc9_sp1_mtdll_debug_dll_x64
vc9_sp1_mtdll_release_static_x64
vc9_sp1_mtdll_release_dll_x64
vc9_sp1_debug_static_xbox
vc9_sp1_release_static_xbox
vc9_sp1_profile_static_xbox
vc9_sp1_shipping_static_xbox
cb_mingw_debug_static
cb_mingw_debug_dll
cb_mingw_release_static
cb_mingw_release_dll
..
..
(this is only a part of win32, there is still Linux and MacOS to do..)
..
These can be either directories, or combining a few directories (platforms ?) with some postfixes (for debug/release, shared/static?).
But the point is that this is a user choice. He or she should be able to decide how to build (and that will be simple because usually, for one irrlicht install, you are on one platform with one compiler version (that doesn't need to be defined ! VC10 will work with Nmake, any gcc with make or codeblocks makefiles), and you know whether you want shared or static, so the combinatorial is reduced to just the configurations: debug/release/profiling.) This is reducing the complexity both for the dev team and the users. Think about this :)
1. I agree that a in-source build with multiple configs and one destination dir (the existing solution) has its advantages. It is simple, already-setup and easy for newcomers. And I won't beat your CodeBlocks virtual target magic (mine is a bash or python script ! or a .bat ..). That's why I think we should keep the current makefiles and projects for at least a version or two, maybe more or indefinitely (I'll come back on this below).
On the other hand, it can be seen by some as having a rigid workflow, it imposes naming and a set of build configurations. Creating a new config is more work for the user because the different lib names will have to be set in every client program.
2. Let me address your last two questions in one shot:
- Yes, CMake can be used by the dev team (you) to pre-generate project files for many platforms and configurations. There is a flag to CMake that tells it to generate 'final' makefiles or projects without auto-regeneration ; and you don't even need to provide the CMakeLists.txt sources.
In this approach, the generated project files would be redundant with the existing tailored projects and makefiles, so yes, they would 'overwrite' the current ones (there would be a choice to be made). And we would have to make a number of decisions regarding the naming of directories, the config postfixes (D or _d, etc.).
- But, I was mainly thinking of the other, simpler use of CMake: that is, to provide the CMakeLists.txt only (don't generate any project files), and the user generates his/her project or makefiles. This requires to have CMake installed, and to run it as many times as the plaftorm/configs (or a single time for MSVC), but the advantages are great:
a) You don't need to provide all the possible platform/config combinations project files and directories ! Indeed, the user will choose himself the build directory names, and he/she will usually need only one platform-compiler-arch per install, and will usually have chosen one of static or shared, so he/she will just have as many builds as configurations (debug/release/optim ..) but not more than that.
b) Also, this way, the user can also choose his workflow: whether to use multiple dirs or to install all things in one place in a similar way as the current system (yes, it is possible to do that with CMake with some work and most importantly, hard-coded 'decisions'). If opting for a single build/install dir he can choose the postfix and the directory naming (CMake has options for that, you can see in my files that there is commented code for that - look for IRR_NO_D_SUFFIX).
c) This allows to keep the currently provided build files exactly unchanged, which is desirable for the next version so that users don't need to change anything. The CMakeLists.txt are just there in addition, to be used by those who choose it. EDIT: and it is recommended to build out of source, and install out of source (in a common lib dir of the system or of the client game project), so that it leaves things clean and allows having the standard build and install in-source at the same-time.
3. Here is what I would suggest for right now:
- keep all currently provided makefiles and project files as-is.
- add the CMakeLists.txt (as in the archive I sent), but don't pre-generate any project files.
Then, later, with user approval, perhaps some currently provided projects or makefiles will be replaced by CMake pre-generated equivalents. This can be done soon for the current unix makefiles, but the CodeBlocks/Visual Studio situation is more complex due to that difference of methodology, so I guess both solutions would stay (or, CMakeLists.txt can be adapted to support the single build/install dir, but choices need to be made concerning the naming, that could have been user choices otherwise).
Again, as a reference, you can see that Bullet provides already generated project files (hand-made or CMake, I don't know), but in addition to that they also give the CMakeLists.txt (and also Jam files ! and automake files ! they're crazy). But additional projects can be required for specific platforms (Codewarrior/Wii, etc.). PS3 and Xbox360 are maybe supported transparently with the Visual Studio and its add-ins. To be confirmed.
So here it is, I hope the team reaches a consensus on this minimal-change scenario.
cheers,
Armand
PS: as an appendix, just to make my point on the hassle of having a correct set of lib and bin directories when building in-source and providing all the projects: yes I believe the current state of build dirs is inconsistent and lacking (with all due respect to the authors, I know how development works ;) ) . You would need all the following directories both in /lib and /bin (under each of those you'd have all the examples, or alternatively you would have all the following under each example dir):
vc7.1_mt_debug_static
vc7.1_mt_release_static
vc7.1_mtdll_debug_static
vc7.1_mtdll_debug_dll
vc7.1_mtdll_release_static
vc7.1_mtdll_release_dll
vc8_sp1_mtdll_debug_static
vc8_sp1_mtdll_debug_dll
vc8_sp1_mtdll_release_static
vc8_sp1_mtdll_release_dll
vc8_sp1_mtdll_debug_static_x64
vc8_sp1_mtdll_debug_dll_x64
vc8_sp1_mtdll_release_static_x64
vc8_sp1_mtdll_release_dll_x64
vc8_sp1_debug_static_xbox
vc8_sp1_release_static_xbox
vc8_sp1_profile_static_xbox
vc8_sp1_shipping_static_xbox
vc9_sp1_mtdll_debug_static
vc9_sp1_mtdll_debug_dll
vc9_sp1_mtdll_release_static
vc9_sp1_mtdll_release_dll
vc9_sp1_mtdll_debug_static_x64
vc9_sp1_mtdll_debug_dll_x64
vc9_sp1_mtdll_release_static_x64
vc9_sp1_mtdll_release_dll_x64
vc9_sp1_debug_static_xbox
vc9_sp1_release_static_xbox
vc9_sp1_profile_static_xbox
vc9_sp1_shipping_static_xbox
cb_mingw_debug_static
cb_mingw_debug_dll
cb_mingw_release_static
cb_mingw_release_dll
..
..
(this is only a part of win32, there is still Linux and MacOS to do..)
..
These can be either directories, or combining a few directories (platforms ?) with some postfixes (for debug/release, shared/static?).
But the point is that this is a user choice. He or she should be able to decide how to build (and that will be simple because usually, for one irrlicht install, you are on one platform with one compiler version (that doesn't need to be defined ! VC10 will work with Nmake, any gcc with make or codeblocks makefiles), and you know whether you want shared or static, so the combinatorial is reduced to just the configurations: debug/release/profiling.) This is reducing the complexity both for the dev team and the users. Think about this :)
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
I don't think that we need more than one version per IDE (besides debug/release, but that's handled by rogerborg in a task on the bug tracker). I highly doubt that people will start to create versions with every MSVC they have installed so far, just for the fun of generating binaries. Instead, having a directory for win32-msvc and win32-gcc is enough, because there's also no need for having c::b and dev-cpp in parallel.
IMHO the currently used Makefile will be much harder to pot properly, as it provides targets for multiple platforms as well as targets for cross-compilation. Creating the X11-binary under OSX and generating a win32 binary under Linux needs a careful setup.
Before we can get rid of any of the current project files we need a CMake setup which creates properly grouped, clean files. This is very important for the examples directory (where one or two projects would be enough with custom project files, though, the others could be generated or - as we do now - copied from the other directories). These are the files people use for their own projects.
IMHO the currently used Makefile will be much harder to pot properly, as it provides targets for multiple platforms as well as targets for cross-compilation. Creating the X11-binary under OSX and generating a win32 binary under Linux needs a careful setup.
Before we can get rid of any of the current project files we need a CMake setup which creates properly grouped, clean files. This is very important for the examples directory (where one or two projects would be enough with custom project files, though, the others could be generated or - as we do now - copied from the other directories). These are the files people use for their own projects.
For work I had to build a library, targeting three versions of Visual Studio. And that wasn't for fun, believe me :)
If anyone wants to build a tool that links with Irrlicht and they need to distribute binaries, they'll likely have this sort of requirements.
But anyway, I won't fight over your build naming. Just advocating another system side-by-side, that can be useful. See point 3 above. The thread title should be changed to "adding CMake support short-term ?" :)
The examples group correctly on, I believe, all systems including C::B and MSVC.
The issue is with the whole set of files for the Irrlicht lib. Things can be grouped as in the original VS project, but that means specifying all files to be specified in the CMakeLists.txt (as is done in the .vcproj) whereas I currently just glob all the files (for simplicity and maintenance). And those groups don't apply to C::B, which apparently uses the folder structure only. That may change in a future version of CMake.. or not.
Anyway, proper grouping is usually done transparently in the filesystem folder structure, and even sub-libs, so I think you're not tackling the problem at the root. CMake would handle that well without the need to specify the file list in the CMakeLists.txt . (Of course I'm not telling you to change all this.. but I think if you want to solve those issues, it should not be done at the IDE level.)
If anyone wants to build a tool that links with Irrlicht and they need to distribute binaries, they'll likely have this sort of requirements.
But anyway, I won't fight over your build naming. Just advocating another system side-by-side, that can be useful. See point 3 above. The thread title should be changed to "adding CMake support short-term ?" :)
The examples group correctly on, I believe, all systems including C::B and MSVC.
The issue is with the whole set of files for the Irrlicht lib. Things can be grouped as in the original VS project, but that means specifying all files to be specified in the CMakeLists.txt (as is done in the .vcproj) whereas I currently just glob all the files (for simplicity and maintenance). And those groups don't apply to C::B, which apparently uses the folder structure only. That may change in a future version of CMake.. or not.
Anyway, proper grouping is usually done transparently in the filesystem folder structure, and even sub-libs, so I think you're not tackling the problem at the root. CMake would handle that well without the need to specify the file list in the CMakeLists.txt . (Of course I'm not telling you to change all this.. but I think if you want to solve those issues, it should not be done at the IDE level.)
-
erwincoumans
- Posts: 46
- Joined: Tue Oct 02, 2007 6:46 am
- Contact:
Sounds good, I'm glad to hear the CMake-Irrlicht support in GameKit inspired this work, CMake is a very nice build tool.
Thanks,
Erwin
That sounds handy, what flag is that? One minor drawback of CMake is that is can be hard to find how to enable certain featuresarmandf wrote:There is a flag to CMake that tells it to generate 'final' makefiles or projects without auto-regeneration ; and you don't even need to provide the CMakeLists.txt sources.
Thanks,
Erwin