Hello Jun Sun,
I hope now I understood your question.
First, let compare auto-tools to cmake: the three main steps involved in
building the system are about the same (though the cmake seems to use a
better cache system than 'configure' and it generates a something
optimized set of GNU Makefiles compared to auto-tools):
1) ./configure = cmake <path-to-src> = ccmake <path-to-src>
2) make (Makefile generated by ./configure) = make (GNU Makefile
generated by cmake)
3) make install = make install
So, I think your question is similar to the following auto-tools question:
- Should I pass a 'make' metavariable or should I use a 'configure'
command line option for obtaining 'xxx'?
I see that 'pass config options to cmake' (option #1) is better for
choosing things like modules (this strategy is used by many projects
like PHP, Apache, Lighttpd, freeradius, etc).
Thinking that way, I propose to you something like the following code:
# suppose 'A' module is built by default
SET(USE_A TRUE
CACHE BOOL
"This flag enables the 'A' module of the project.")
# suppose 'B' module is not built by default
SET(USE_B FALSE
CACHE BOOL
"This flag enables the 'B' module of the project.")
IF(USE_A)
ADD_DIRECTORY(module_A)
ENDIF(USE_A)
IF(USE_B)
ADD_DIRECTORY(module_B)
ENDIF(USE_B)
# ... some other code ...
IF(USE_A)
INCLUDE_DIRECTORIES(module_A/include)
# the final target needs to link against module_A
TARGET_LINK_LIBRARIES(myproject module_A)
ENDIF(USE_A)
IF(USE_B)
INCLUDE_DIRECTORIES(module_B/include)
# the final target needs to link against module_B
TARGET_LINK_LIBRARIES(myproject module_B)
ENDIF(USE_B)
This way, you get on ccmake (ncurses-based interface for UNIXes) and
CMakeSetup (for Windows), something like this:
USE_A TRUE <-- This flag enables the 'A' module of the project.
USE_B FALSE <-- This flag enables the 'B' module of the project.
If you would not like to use the ccmake nor CMakeSetup, and you need to
compile module_B and not module_A, for example, you would use the
following command-line to cmake:
# cmake -D USE_A:BOOL=FALSE -D USE_B:BOOL=TRUE
If you need to change some types of configuration variables, like the
installation prefix, for example (e.g. /usr/local), you would rather
pass this option to make itself than changing cmake cache (though the
both ways get to the same target). You would change the DESTDIR variable
for this purpose, like auto-tools (make DESTDIR="/home/me/mydist" install).
----
By using this cmake strategy you bring the same configuration options to
other systems like Windows and Mac OS X, by using cmake native
capabilities. If you use 'make' variables, you narrow your solution to
'Makefile' systems (then you need to check if all nmake/gmake/etc uses
identical metavariable passing), so you need to imitate the same
behavior on other systems by hand.
So, if your application should build on other systems different than
UNIXes, I think the option #1 is far the best one.
Regards,
Guilherme Balena Versiani.
Jun Sun escreveu:
Thanks for the pointer. But I was referring to the configuration
for the cmake itself. For example, one build may include module A
and another build may not include module B instead.
Now thing about it, what is the recommanded way of achieving this goal?
I can thinking of two ways:
1. Pass config options to cmake itself so that it generates two
different make systems that does two things
2. Somehow generate just one make system but the make system itself takes
an input argument that dictates which way to do the build.
Which one is better in cmake world? I was thinking about 1).
Thanks.
Jun
On Fri, May 11, 2007 at 02:22:46PM -0300, Guilherme Balena Versiani wrote:
AFAIK using cmake involves basically two steps:
1) something like configure & generate build files (GNU Makefile, MSVC,
KDevelop3, XCode, etc). For a tipical 'out-of-source' building:
# mkdir <build_dir>
# cmake ../<source_dir>
2) build software:
# make
Optionally, you can have a 'make install' (see INSTALL command), a 'make
package' (which means you are using CPack) and 'make test' (see CTest).
Regards,
Guilherme Balena Versiani.
Jun Sun escreveu:
My build process involves a configuration stage. It roughly looks like
this:
* Generate cmakefile.inc and config.h from .config file
* Use cmake to generate solution files or makefiles
* Build with native toolchain
It is not clear to me whether I should use an external script to do
step 1 or I can even do the first step with cmake itself.
I am very new to cmake. Sorry if this is a dumb question. :)
Cheers.
Jun
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
begin:vcard
fn:Guilherme Balena Versiani
n:Versiani;Guilherme
org:ComunIP S/A
adr;quoted-printable;quoted-printable:Bairro Funcion=C3=A1rios;;Rua Cl=C3=A1udio Manoel, 237;Belo Horizonte;MG;30140-100;Brasil
email;internet:[EMAIL PROTECTED]
tel;work:(+55/31) 3284-1007
url:http://www.comunip.com.br
version:2.1
end:vcard
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
