CMake or not CMake

Brocan · Post by **Brocan** » Fri Apr 27, 2012 12:59 pm

Hi everyone!

We are currently developing a medium-size project, that needs to run both windows and linux. Currently we are using VisualStudio because is really great for coding and debugging. The problem is that we need to compile it in linux (fedora/suse, i guess) and the VS project (obviously) doesn't compile in linux.

So, here comes my doubt, what is better from the point of view that the project needs to be continuously developed?

- Create a VS project for windows, and makefiles for linux? Then, both must be synchronized by hand, but we get directories, debug paths, VS debugging and post-compilation steps perfectly controlled.

- Or create a CMake config files, and regenerate the projects? Then only the CMake needs to be update with new files, but, from the developer point of view (as far as i know about cmake), i see very dissapointing need to regenerate the VSProject each time you want to add a new file to the project. And i see that the path configuration is hard to set paths like "WorkingDirectory" for debugging.

I think that CMake is more suitable for compile complete libs/sdks and use them in your own project/vs solution, not for continuous develop.

What do you think? Any other tools or recomendations we should use?

Thanks in advance!

Post by **CABAListic** » Fri Apr 27, 2012 1:26 pm

I think that it comes down to how many developers with different programming environments you have. If you have a team of programmers who all use Visual Studio with the exact same path setup, then CMake provides no benefits.
However, the more different environments you have in your team, the more troublesome it becomes to maintain properly working build systems without a tool like CMake or premake.

In your case, if you are fine with maintaining both build systems, then that's ok. But consider that you need to keep both of them up to date. It may be strange to a Visual Studio developer to have to add a new file to a CMakeLists.txt instead of adding it via the Visual Studio interface - however, you would have to add the file to your Linux makefiles, anyway, so you can't avoid that. That's why I, personally, always use CMake whenver I develop for more than one platform or in a team with someone else who might have setup his environment a little differently.

However, if you are not experienced with CMake, then it can be quite difficult to port an already existing project. I spent quite some time on writing the initial CMake build system for Ogre, and from there it's evolved quite a bit to its current state. So there's definitely an initial cost in time and effort that you would also have to consider.

Post by **jacmoe** » Fri Apr 27, 2012 1:29 pm

I use CMake a lot, and it is indeed possible to tell it to set the proper debugging options so that you can treat the project files as read-only.
You can also set things like source code filters, solution folders, etc.
And there are other options which would be tedious or hard to do in VS, like custom commands and dependent project processes.
I see no reason to maintain build scripts for several platforms..

For instance, when we configure and generate build scripts for Ogitor, all one has to do is choose qtOgitor as startup project and hit the F5 button.
And that's it.
Everything is set up through CMake.

Another benefit is that users on all platforms can use the generators, or the cmake scripts directly, to load/generate from almost any IDE they want: QtCreator, KDevelop, NetBeans, Eclipse, even Code::Blocks.

So, think twice.

And ask CMake gurus if you need help.

Post by **spacegaier** » Fri Apr 27, 2012 1:34 pm

We over at Ogitor are you using CMake without any major troubles since we have Win, Linux and Mac devs. Of course you have to edit the CMake files when you add new code files, but that is not that big a deal. So from our PoV the benefits far outweigh the minor drawbacks

.

EDIT: Should have updated the page before replying. jacmoe of course was faster in mentioning Ogitor

Post by **jacmoe** » Fri Apr 27, 2012 1:58 pm

One thing that I forgot to mention:
CMake fits perfectly with source control because it's regular text files.
And it makes it really easy to perform out of source builds.
If you keep your build directory separate from the source directory, you never pollute your source with generated files.
And it's easier to follow the golden rule of CMake: never touch/edit/modify anything in your build directory.

<edit>
I like CMake. Some people hate it.
It's up to you what you choose to use.
I just have a suspicion that you will save yourself both time and work if you choose to use it.

</edit>

Klaim · Post by **Klaim** » Fri Apr 27, 2012 3:04 pm

If you consider CMake, it may be a good idea to consider Premake too, as it might fit your need better, depending on... lot of things.

Brocan · Post by **Brocan** » Wed May 02, 2012 8:14 am

Thanks for your fast replies (i've been out of the work these days).

I'm trying cmake but i'm getting a lot of problems to make my paths as we want (ie: output path without /debug or /release suffixes, working dir for debugging, etc...). I'm going to try Premake too, it seems to be more suitable for our needs (we don't need very advanced features, and premake seems to be easier to understand and mantein).

Cheers!

Brocan · Post by **Brocan** » Wed May 02, 2012 8:49 am

I'm my VS project, i've this project structure:

Project/bin: output for DLLs and exes (the dlls are copied using a post-build copy command)
Project/lib: output for DLLs and libs

The paths are the same for both debug and release, the debug targets append a "_d" suffix.

But when i try to move this to CMAKE, i'm able to set this directories overloading the following vars:

set (LIBRARY_OUTPUT_PATH ${Project_SOURCE_DIR}/lib)
set (EXECUTABLE_OUTPUT_PATH ${Project_SOURCE_DIR}/bin)

The problem is that cmake appens the whole time the configuration name to this paths: Project/bin/Debug, Project/bin/Release, etc... and i don't want it, since i've a lot of files that must be used by both versions and i don't want to duplicate it.

Any ideas of how this can be achieved?

Post by **jacmoe** » Wed May 02, 2012 8:57 am

I see that you are using the source directory - any reason for doing that?
Keep source and build separate. That's 'best practice'.

This works well:

Code: Select all

set(LIBRARY_OUTPUT_PATH ../lib)

This is also useful:

Code: Select all

if(WIN32)
set(CMAKE_DEBUG_POSTFIX "_d")
endif(WIN32)

If you want to have debugging options set, take a look at either Ogre source and/or Ogitor source.
It actually works.

(Hint: configure_file)

zootlewurdle · Post by **zootlewurdle** » Wed May 02, 2012 12:38 pm

Personally I'd say cmake is worth persevering with even for Visual Studio. I was pretty resistent to using it at first but couldn't see myself not using it now. If only because it servers as a great way to generate all the sln/proj files in the even that they screw up (and hey, its VS, I've had my project files borked on several occasions).

Also easier to set up out-of-source build targets I think. Never tried it manually in VS though. I like to have all the VS project files separate from the raw source, i.e., in a 'build' location.

The fact it's cross-platform is a bonus for me. I really must figure out how to get Ogre compiling on my Mac...

Brocan · Post by **Brocan** » Thu May 03, 2012 8:34 am

Well, i've the cmake running, not difficult as it seems

. I've one last questions (stupid details

)

- I've my projects organized by folders "set_target_properties(blabla ... FOLDER ...)" for VS organization, but how can you move the ALL_BUILD target to a folder?
- How you can specify a startup project? because now ALL_BUILD is always set as startup project

- And the last, when i looking for the dependencies directory, is it possible to copy the dependant binaries at configuration/generation time? . If not, i think that copy the dependant dlls (if not found) each time that Core is built would be the best idea.

zootlewurdle · Post by **zootlewurdle** » Thu May 03, 2012 9:06 am

ALL_BUILD is a VS project, it can't be a folder in the solution.

Sadly, you cannot set a start-up project. You just have to remember to manually set that. You may also need to remember to manually set debug/release working directories in the debugging properties panel. Other than that I don't think you normally need to manually set anything (at least, I don't).

You can have cmake copy other binaries around at config/generation time, but whether you should be depends on what you are actually wanting to copy. I'm not sure if this is what you mean, but in my main cmake file I have this:

Code: Select all

if(WIN32)
	file(COPY ${OGRE_PLUGIN_DIR_DBG} DESTINATION system FILES_MATCHING PATTERN "*.dll" )
	file(COPY ${OGRE_PLUGIN_DIR_REL} DESTINATION system FILES_MATCHING PATTERN "*.dll" )
	file(COPY ${PROJECT_SOURCE_DIR}/dependencies/libogg/win32 DESTINATION system FILES_MATCHING PATTERN "*.dll" )
	file(COPY ${PROJECT_SOURCE_DIR}/dependencies/libvorbis/win32 DESTINATION system FILES_MATCHING PATTERN "*.dll" )
	file(COPY ${PROJECT_SOURCE_DIR}/system DESTINATION . FILES_MATCHING PATTERN "*.cfg" )
endif(WIN32)

which copies Ogre dlls, some other dependencies, and my default run-time config files from their standard location to where my 'build' directory is (and to a 'system' directory within that) created by cmake.

edit: You shouldn't need to worry about manually setting the start-up project too much. When you add new files, or otherwise update your cmake files, and rebuild within VS, it will update your projects but the start-up project shouldn't change. At least not in my experience. Only if you are rebuilding from fresh, no pre-existing VS files are around, do you need to set the start-up project.

Brocan · Post by **Brocan** » Thu May 03, 2012 10:23 am

Thanks for your fast response zootlewurdle!

I've look for the binary files with this code:

Code: Select all

macro(get_runtime_names PREFIX)
  foreach(i ${${PREFIX}})
    set(${PREFIX}_RUNTIME ${${PREFIX}_RUNTIME} ${i}${CMAKE_SHARED_LIBRARY_SUFFIX})
  endforeach(i)
endmacro(get_runtime_names)

macro(get_runtime_dgb_names PREFIX)
  foreach(i ${${PREFIX}})
    set(${PREFIX}_DBG_RUNTIME ${${PREFIX}_DGB_RUNTIME} ${i}d${CMAKE_SHARED_LIBRARY_SUFFIX} ${i}D${CMAKE_SHARED_LIBRARY_SUFFIX} ${i}_d${CMAKE_SHARED_LIBRARY_SUFFIX} ${i}_D${CMAKE_SHARED_LIBRARY_SUFFIX} ${i}_debug${CMAKE_SHARED_LIBRARY_SUFFIX} ${i}${CMAKE_SHARED_LIBRARY_SUFFIX})
  endforeach(i)
endmacro(get_runtime_dgb_names)

get_runtime_names(VP_POCO_FOUNDATION_NAMES)
get_runtime_dgb_names(VP_POCO_FOUNDATION_NAMES)

find_file(VP_POCO_RUNTIME_REL NAMES ${VP_POCO_FOUNDATION_NAMES_RUNTIME} HINTS ${VP_POCO_BIN_SEARCH_PATH})
find_file(VP_POCO_RUNTIME_DBG NAMES ${VP_POCO_FOUNDATION_NAMES_DBG_RUNTIME} HINTS ${VP_POCO_BIN_SEARCH_PATH})

And copied the dlls with this code:

Code: Select all

if (VP_POCO_RUNTIME_FOUND)
	file(COPY ${VP_POCO_RUNTIME_REL} DESTINATION ${VP_WORKING_DIR})
	file(COPY ${VP_POCO_RUNTIME_DBG} DESTINATION ${VP_WORKING_DIR})
endif(VP_POCO_RUNTIME_FOUND)

And works perfect

As you said, its true that the startup project doesn't change in recursive project changes, so perfect

The only thing remaining is i don't know why ZERO_CHECK is moved to a "CMakePredefinedTargets" VS folder, but ALL_BUILD is in the solution root

Mikachu · Post by **Mikachu** » Thu May 03, 2012 10:37 am

zootlewurdle wrote:You may also need to remember to manually set debug/release working directories in the debugging properties panel.

There's a workaround for that, with a template user file, which is used in Ogre.

Code: Select all

# create vcproj.user file for Visual Studio to set debug working directory
function(ogre_create_vcproj_userfile TARGETNAME)
  if (MSVC)
    configure_file(
          ${OGRE_TEMPLATES_DIR}/VisualStudioUserFile.vcproj.user.in
          ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}.vcproj.user
          @ONLY
        )
    configure_file(
          ${OGRE_TEMPLATES_DIR}/VisualStudioUserFile.vcxproj.user.in
          ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}.vcxproj.user
          @ONLY
        )
  endif ()
endfunction(ogre_create_vcproj_userfile)

Brocan · Post by **Brocan** » Thu May 03, 2012 10:44 am

Yeah, i'm doing the same to configure project working directory for debugging when generating for VS:

debug_dir.vcxproj.user.in

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
    <LocalDebuggerWorkingDirectory>@VP_WORKING_DIR@</LocalDebuggerWorkingDirectory>
    <DebuggerFlavor>WindowsLocalDebugger</DebuggerFlavor>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
    <LocalDebuggerWorkingDirectory>@VP_WORKING_DIR@</LocalDebuggerWorkingDirectory>
    <DebuggerFlavor>WindowsLocalDebugger</DebuggerFlavor>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='RelWithDebInfo|Win32'">
    <LocalDebuggerWorkingDirectory>@VP_WORKING_DIR@</LocalDebuggerWorkingDirectory>
    <DebuggerFlavor>WindowsLocalDebugger</DebuggerFlavor>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='MinSizeRel|Win32'">
    <LocalDebuggerWorkingDirectory>@VP_WORKING_DIR@</LocalDebuggerWorkingDirectory>
    <DebuggerFlavor>WindowsLocalDebugger</DebuggerFlavor>
  </PropertyGroup>
</Project>

And in the projects that need a working directory (basically exes) i made:

Code: Select all

# add a user file to auto config the working directory for debugging
configure_file(${CMAKE_TEMPLATE_DIR}/debug_dir.vcxproj.user.in ${CMAKE_CURRENT_BINARY_DIR}/UnitTest_Core.vcxproj.user @ONLY)

Post by **jacmoe** » Thu May 03, 2012 2:42 pm

The reason why ALL_BUILD is not put into the CMake solution folder is because it is a special project: you generally want to build it instead of individual projects as it is tied to your main CMake script.
If you have configure actions defined in the main CMake script, then they will be fired when you run ALL_BUILD which again will fire other scripts.
ZERO_CHECK runs first and determines if CMake needs to be reconfigured.
(You can also build that to refresh the configuration, although VisualStudio is totally paranoid about that. :p)

Building any other project is not guaranteed to trigger all scripts - they might do that, or they might not..
ALL_BUILD should - which is why it's special.
The exception is INSTALL which is directly dependent on ALL_BUILD.

Brocan · Post by **Brocan** » Fri May 04, 2012 8:05 am

Thanks jacmoe.

One last question, how i must work with new files? now i'm creating by hand and then i'm adding it to CMakeFiles.txt. After all, i go to VS and generate the ZeroCheck solution, but i got a bunch of error messages (about stopping compilation, HRESULT error, etc...) and half of times i need to go to CMake an regenerate the whole solution.

Is there any other easiest process?

Post by **jacmoe** » Fri May 04, 2012 9:56 am

Close Visual Studio and configure/configure/generate in CMake-GUI instead, after each change of CMake scripts.
VS is screwed up and does not like that CMake changes the projects 'behind it's back'.

KDevelop handles this quite well, and QtCreator too, but Visual Studio has zero CMake support, unfortunately.

So, just use CMake-GUI to configure x 2 and generate (don't forget that step

) - and all should be fine.
That is by far the easiest way.

If you run into build errors: delete the CMake cache - look for it in CMake-GUI (file, I think?) and do a configure/configure/generate dance.

themean · Post by **themean** » Fri May 04, 2012 3:26 pm

I'm too lazy to read all post but i get the essence
I work on project linux/win and use qt creator and qmake. I think this is right choice
You can use qmake with visual studio

zootlewurdle · Post by **zootlewurdle** » Fri May 04, 2012 3:52 pm

Most of the time, if I'm just adding or removing source files, just changing the cmakelists.txt file and hitting rebuild all within Visual Studio works fine for me. You'll get a couple of dialogs popping up about the project/solution files having changed or something, just let it continue.

Occasionally the project gets in a mess but I don't see that too often. At least this is true of VS9.

If you're doing anything more involved than add/remove files then I'd always go the cmake-gui route to reconstruct the project files.

Klaim · Post by **Klaim** » Sat May 05, 2012 5:37 pm

From what I understood in the mailing list, they plan to provide (maybe in the last version) a way to set the startup project.

zootlewurdle · Post by **zootlewurdle** » Sat May 05, 2012 6:08 pm

It's not in 2.8, unless it's well hidden.

Post by **jacmoe** » Tue May 08, 2012 9:49 pm

themean wrote:I'm too lazy to read all post but i get the essence
I work on project linux/win and use qt creator and qmake. I think this is right choice
You can use qmake with visual studio

Nah - qmake really sucks.

If you develop Qt applications, no need to mess around with that peculiar build system: CMake is the official build system for KDE, so use that and stay sane.
You don't need to fuzz with Visual Studio and post/pre build steps, etc. etc. - just use some Qt specific CMake macros and that's it.
You don't need the Visual Studio addin either.

Klaim · Post by **Klaim** » Wed May 09, 2012 11:10 am

Even the Qt teams acknowledge that qmake sucks, they made several posts about it and about switching to something better.

Although, qmake is interesting only if you need Qt.

Brocan · Post by **Brocan** » Thu May 10, 2012 11:12 am

Uhm, i'm running in a new problem, i need to find some dlls which have incremental versions (today avcodec-54.dll, tomorrow maybe avcodec-55.dll or avcodec-4843.dll), i'm trying to use some kind of pattern, i've used file GLOB also, no success.

Code: Select all

file(GLOB VP_FFMPEG_AVCODEC_RUNTIME ${VP_FFMPEG_BIN_SEARCH_PATH} "avcodec*${CMAKE_SHARED_LIBRARY_SUFFIX}")
or
find_file(VP_FFMPEG_AVCODEC_RUNTIME NAMES "avcodec*${CMAKE_SHARED_LIBRARY_SUFFIX}" HINTS ${VP_FFMPEG_BIN_SEARCH_PATH})

Any ideas?

Ogre Forums

CMake or not CMake

CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake

Re: CMake or not CMake