[CMake] [VS gen] Multiple configurations code
eric.noulard at gmail.com
Mon Jul 26 17:59:29 EDT 2010
2010/7/26 Olaf van der Spek <olafvdspek at gmail.com>:
> On Mon, Jul 26, 2010 at 10:12 PM, David Cole <david.cole at kitware.com> wrote:
>>> Is there a problem with multiple configures / build trees?
>> No, not at all. We do this all the time. But again, I thought from your
>> questions that you were trying to do it all in one build tree.
> I'm not familiar with the term build tree.
You may have a look at this part of the FAQ:
Basically from CMake point of view, all **generated** files are in the
Note that **generated** files does mean that those files are coming
from a compilation step
they may come from add_custom_command, execute_process etc...
One thing that interest you in the first place is that the project
file (or makefile etc...)
is GENERATED so it ends up in the build tree.
So having 2 separate build trees == having 2 separate project files.
The main idea behind the source-tree / build-tree separation is that
you may always delete the build tree because it may be regenerated from
the source tree.
This way if you use a VCS (CVS, svn git, etc...) you know that the VCS
is only concerned
by the source tree.
A last thing is that a source tree may be "shared" by several build trees.
> Let's describe what I'd like:
> I've got a single CMakeLists.txt for a lib named "xbt". I've got xbt.h
> and xbt.cpp. I'm using VS (2010).
> With a few simple commands, I should be able to build and package all
> possible configurations of this lib.
> In the ideal case, this would be cmake ., nmake ... or similar.
> It should not be necessary to modify CMakeLists or to have multiple
> copies of the source.
Currently you don't need several copies of the sources, you "only" need several
build trees configured with **differents** options from the SAME CMakeLists.txt.
Is it more clear, stated like that?
Membre de l'April - « promouvoir et défendre le logiciel libre » -
More information about the CMake