Page 1 of 1

Cmake can really generate normal MSVC++ projects?

Posted: Tue Dec 22, 2009 12:16 am
by ahmedali
I wasted to days of learning Scons just to realize that it generates MSVS project which is hooked to Scons, no individual file compiling nor debugging...

I could just experiment with premake or cmake or any other project generator but can any one confirm that Cmake/Premake generate MSVS projects files with no frills or strings attached to its own build thingy... Can i really work on the generated project like a "NORMAL" msvc++ project..

It will really save some time...

Re: Cmake can really generate normal MSVC++ projects?

Posted: Tue Dec 22, 2009 12:22 am
by jacmoe
Of course. :)
Only caveat is that the paths are absolute, ie you can't move the project around.
So if you need to generate solution/projects for distrubution, you need to do those by hand, or premake/whatever.
But, yes: the purpose of CMake is to use native toolchains.

Re: Cmake can really generate normal MSVC++ projects?

Posted: Tue Dec 22, 2009 12:35 am
by ahmedali
absolute path is ok, it can be get around. eventhough i find lua based premake simpler but because it seems cmake has larger userbase including ogre so im with cmake here.

Re: Cmake can really generate normal MSVC++ projects?

Posted: Tue Dec 22, 2009 10:14 am
by jonim8or
I must agree that Cmake can create MSVC++ projects. However, it depends on the structure of the cmake files, whether the generated visual studio project is easy to use or not. The Ogre Cmake files give a good, useful solution.

I'm not sure about the "hookedness" of the generated msvc project to cmake. That's because the idea is that the cmake project remains usable as a cmake project (so also for other compilers). Therefore adding source files, moving source files, etc. results in changes to the cmake files and re-running cmake. (at least, afaik)

Re: Cmake can really generate normal MSVC++ projects?

Posted: Tue Dec 22, 2009 10:55 am
by CABAListic
Yes, well, the generated VS solutions are not independent from CMake, but that's not the point. After all, if you wanted independent solutions, just create them. The solutions generated by CMake do call CMake to ensure they are up to date, and if you manually add new files or change build settings, then you will lose those changes when CMake is rerun. But that's exactly what you want if you use CMake, because then CMake is responsible for the build.

Re: Cmake can really generate normal MSVC++ projects?

Posted: Tue Dec 22, 2009 11:26 am
by jacmoe
jonim8or wrote:I'm not sure about the "hookedness" of the generated msvc project to cmake. That's because the idea is that the cmake project remains usable as a cmake project (so also for other compilers). Therefore adding source files, moving source files, etc. results in changes to the cmake files and re-running cmake. (at least, afaik)
The projects are read-only. Don't touch them, touch the CMake script.
Normally, the ZERO_CHECK project will ensure that CMake is rerun if changes has been detected.

Re: Cmake can really generate normal MSVC++ projects?

Posted: Tue Dec 22, 2009 12:01 pm
by Klaim
By the way, is there a relative-path alternative solution to CMake? I'm using custom python build scripts in my project but looks for a better solution...

Re: Cmake can really generate normal MSVC++ projects?

Posted: Mon Dec 28, 2009 7:50 pm
by starkos
The files generated by Premake are not hooked to Premake in any way; they can be distributed and used without needing Premake installed.

Premake uses relative paths.

Like CMake, any changes to the project settings (defines, include paths, build flags, etc.) should be done in the Premake script, otherwise they will be overwritten the next time you generate the project files. The exception to the rule is files: if you use wildcards in your Premake script (i.e. *.h, *.cpp) then you can add files from the IDE without needing to update the script (I assume CMake is the same in this regard).

Since discussion about Premake is a bit off-topic for this forum, feel free send questions to the Premake forums at http://industriousone.com/forums/premake and I'll be glad to help out.

All that said, if you are creating something to be used with Ogre, and you plan to share it, you should probably use the same build system as Ogre.

Re: Cmake can really generate normal MSVC++ projects?

Posted: Tue Jan 26, 2010 4:32 pm
by ecoumans
With the right options, cmake can create normal MSVC projectfiles that use relative paths and that are independent of cmake. So you can distribute those projectfiles.
In a nutshell, you need those two options: CMAKE_SUPPRESS_REGENERATION and CMAKE_USE_RELATIVE_PATHS, and my patch for the cmake 2.8 issue with relative pdb file names. This patch been applied to their trunk to next version has it. If you are adventurous you can try out this precompiled patched binary cmake.exe, just copy it in your C:\Program Files (x86)\CMake 2.8\bin folder.

You can try the cmake pre-generated MSVC projectfiles as part of OgreKit.zip, using a recent SVN trunk version of Ogre 1.7 here:
http://code.google.com/p/gamekit/downloads/list

Thanks,
Erwin

By the way, premake seems a cool project too, it can create Xbox and PS3 project files (would be nice if it supported SPUs...)

Re: Cmake can really generate normal MSVC++ projects?

Posted: Wed Jan 27, 2010 3:47 pm
by sinbad
Interesting, I tried precisely these 2 options several times in the past and they've never worked for me (irrespective of the pdb issue), absolute paths were still littered around the project files. At what point in the project files did you define them?

Re: Cmake can really generate normal MSVC++ projects?

Posted: Mon Feb 01, 2010 5:17 am
by ecoumans
Right at the start of the first CMakeLists.txt

it seems to work fine, I'm also using it for the upcoming Bullet physics releases.
Cheers,
Erwin

Re: Cmake can really generate normal MSVC++ projects?

Posted: Mon Feb 01, 2010 11:17 am
by sinbad
Ok, ours was inside the project definition, maybe that's the problem.

Once the pdb fix is in the mainstream releases I'll look at this again for ours.