Re: [CMake] What does `cross-platform' mean?
Good morning, On Monday 10 November 2008 16:46, Bill Hoffman wrote: OK, so perhaps the FindFoo.cmake modules should always use a try-compile to test the library that is found works with the current ABI. This will likely slow things down quite a bit... This would require some extra thought Sure, this is what most people tell about autotools. They are slow. That is for a huge amount because of exactly that reason, that they test what they need to test. And this usually includes starting up a compiler, compiling a small testprogram pulling half of the includes of the installed system, linking, executing, testing return value Perhaps the abi can be determined without a try-compile, but I am not sure that would work on all platforms. That would be indeed the way cmake handles these things. But this requires plenty of special case handling. Think of linker scripts on gnu binutils based systems. This is a simple text file doing complicated things with some elf binaries. look into /usr/lib/libc.so of a recently new libc (here suse 10) - understand the documentation from 'info ld' regarding 'Scripts', read that linker script file from cmake and reimplement the semantics of the linker scripts with cmake, just to see if you could later link with that file. Ok, I forgt, you also need to track further development of gnu ld's scripts to make cmake work in the future - may be decide which version of ld is installd to simulate different versions behaviour of ld. Ok, done so far, now we have just handled gnu ld based systems. That is mostly 'linux systems'. To be real 'cross platform' now start thinking about all the other unix flavours with all those merits and they have. There is a, if I remember right, 700 page red book describing linking on AIX. They have plenty of good and usefull and at some places strange ideas at IBM, but you need to know and understand all those ideas, if you want to make cmake decide if you could link with a library. All the nice stuff HP has hiden in the shared library handling. With all the problems introduces with files explicitly linked with full paths. Just to name some things you need to know and learn and maintain if you want to make cmake aware of that problem. And all that stuff, just to know if you can link with such a library? Any again, it does not help the final build if cmake *thinks* the linker can link with such a library. For the build, the linker must be able to link. ... Test what you need. Also think of debugging transparency for the user of cmake. This is a problem with all of the configuration systems I know. You have a black box and you do not know what happens inside. Suppose you have installed a system with library 'a' installed and you have downloaded project 'b' based on cmake. But that project claims not to find liba. Why? liba is there, I can link with it, I can run programs with it, it works pretty well, but cmake's black box system has decided not to find it... ??? Being able to link a program and run it with that library is IMO a good and *simple* thing a user can easily test. And if this does not work, a user can isolate the test case and run that test compile/link with more verbose flags and see why it breaks or not. This is much harder for a user if this is all done somewhere in the c++ code in some subtile different way than the linker does it later at compile time ... ... my 2 cents for that problem. ... and yes, at some point in the future somebody will start beating cmake because of being so slow. This guy will then start a new project for a build system. And people need again tell this guy that the other systems in this area are slow for a good reason. :) Greetings and thanks Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Precompiled headers
Sorry to ask again, but speeding up my build would really help me and my colleagues in the context of a continuous build... Does CMake support precompiled headers when generating Makefiles? From: Yves Martelli Sent: 04 November 2008 17:54 To: cmake@cmake.org Subject: Precompiled headers Hi, I tried looking for precompiled header support in CMake for Makefiles, but the information on the net is quite sparse and it is not easy to see if it is up to date. I saw that gcc supports precompiled headers and that you just have to give the header to it with an output file. So the question, can I use precompiled headers with Cmake for Makefiles? Thanks, Yves ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making Nightly builds easier to setup
Hi all,
writing the CMakeCache.txt in advance works fine, thanks. Anyway, I
haven't been able to get some things to work which work for my
experimental setup,
which uses old-style CTest scripts. Memory checking and coverage tests
do not work anymore. I searched through the sources of CMake a bit, but
I could not get
it to work yet. As I currently do not have the time to fiddle around
with all these undocumented changes, I will stay with my old setup for
the time being.
When the documentation of this new-style scripting improves, I will give
it another try.
Regards,
Martin
David Cole wrote:
The variable CTEST_INITIAL_CACHE is ignored in new-style
(CTEST_BUILD() command based) ctest scripts.
Instead, you should use:
FILE(WRITE ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt
MAKECOMMAND:STRING=nmake -i
CMAKE_MAKE_PROGRAM:FILEPATH=nmake
CMAKE_GENERATOR:INTERNAL=NMake Makefiles
BUILDNAME:STRING=Win32-nmake71
SITE:STRING=VOGON.kitware
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
)
(But only on a clean build, after calling
CTEST_EMPTY_BINARY_DIRECTORY(${CTEST_BINARY_DIRECTORY}), or perhaps
only if the CMakeCache.txt does not exist in the first place...)
HTH,
David
On Mon, Nov 10, 2008 at 5:33 AM, Martin Apel [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Eric Noulard wrote:
2008/11/9 Alexander Neundorf [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
[...]
commands can be executed.
IMO this can make setting up Nightly builds much easier.
Looks interesting, I didn't ever thought ctest scripting was
done for that.
I did shell scripts for that and was wondering how to do it on
Windows :-)
Now I know.
What do you think ?
One thing which is still missing is a way how to get variables
predefined into
the cmake-configure run during ctest_configure().
Does this have to be done by writing an initial CMakeCache.txt ?
This seems possible using CTEST_INITIAL_CACHE
as shown here:
http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
http://www.vtk.org/Wiki/CMake_Script-disableding_Of_CTest
# this is the initial cache to use for the binary tree, be
careful to escape
# any quotes inside of this string if you use it
SET (CTEST_INITIAL_CACHE
MAKECOMMAND:STRING=nmake -i
CMAKE_MAKE_PROGRAM:FILEPATH=nmake
CMAKE_GENERATOR:INTERNAL=NMake Makefiles
BUILDNAME:STRING=Win32-nmake71
SITE:STRING=VOGON.kitware
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
)
I recently played around with nightly builds as well. I used to have a
setup for experimental builds, but never could get the svn checkout to
run. With the approach described above, I was finally able
to run checkout from svn from within ctest. Unfortunately it seems
that
some variables are not used anymore with this approach of
generating builds.
I found that CTEST_INITIAL_CACHE as well as CTEST_ENVIRONMENT seem
to be
ignored, when using CTEST_BUILD etc. For the environment variables I
could get it to work by setting
the environment variables explicitly, e.g. 'SET (ENV{CC} gcc-4.2)'.
That means that the approach proposed above does not work, at
least not
for me.
After all I'm somewhat confused about this new approach ignoring
some of
the variables. Maybe someone with a deeper knowledge of ctest could
explain, what's going on here.
Regards,
Martin
Virus checked by G DATA AntiVirus
Version: AVF 19.138 from 09.11.2008
___
CMake mailing list
CMake@cmake.org mailto:CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Virus checked by G DATA AntiVirus
Version: AVF 19.140 from 10.11.2008
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTANT!! SET CACHE FORCE not wortking with UNINITIALIZED variables
Eric NOULARD wrote:
Le Tue, 11 Nov 2008 11:47:20 -0200,
Fernando Cacciola [EMAIL PROTECTED] a écrit :
Hi,
Since my last post about this got unnoticed I'm reposting it, this
time with additional information.
Sorry, I did see your post, and I am busy...
So, you also mentioned this case:
SET( VAR 321 CACHE STRING FORCE )
set(VAR )
message(${VAR}) - prints out 321
So, this was intentional. set(var ) removes the value of var, and var
becomes unset. This then re-exposes the cache variable VAR.
The culprint is in the following section of the cmake sources:
void cmMakefile::AddCacheDefinition(const char* name, const char*
value, const char* doc,
cmCacheManager::CacheEntryType
type) {
const char* val = value;
cmCacheManager::CacheIterator it =
this-GetCacheManager()-GetCacheIterator(name);
if(!it.IsAtEnd() (it.GetType() ==
cmCacheManager::UNINITIALIZED)
it.Initialized())
{
val = it.GetValue();
As you can see, when SET sees an UNINITIALIZED variable it just
ignores the value being passed on and just keeps the previous value.
After some CVS history browsing, the code is there at least since
CMake 2.4.4 (may be older).
IMO this is a bug, and I even wonder if that comparison didn't intend
to be != instead ??
The bug, if ever this is one should be elsewhere.
Fortunately, the variable is nevertheless overwritten into the cache,
with the old (wrong) value but the correct type, hence, the following
works around the bug:
SET( VAR 321 CACHE STRING FORCE )
SET( VAR 321 CACHE STRING FORCE )
MESSAGE( STATUS VAR=${VAR} )
That is, the first SET fixes the type, allowing the second SET to
do what it should.
Shall I add this to the tracker or is this behaviour on purpose??
So, I think this was intentional, sort of...
The issue is that we want the command line to be used. So, if you have:
cmake -DFOO=456
Then, FOO should be set in the cache to the value 456 and something like
this:
SET( VAR 123 CACHE STRING )
Should not set VAR to 123, but it should set the type to STRING. The
bug seems to be that if you have:
SET( VAR 123 CACHE STRING FORCE)
It should do a FORCE and override the command line.
If you can provide a patch that does that, I will apply it, as FORCE
should always force. We just need to be careful that we don't break the
non-force case that should only set the type.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTANT!! SET CACHE FORCE not wortking with UNINITIALIZED variables
Hi Bill,
Eric NOULARD wrote:
Le Tue, 11 Nov 2008 11:47:20 -0200,
Fernando Cacciola [EMAIL PROTECTED] a écrit :
Hi,
Since my last post about this got unnoticed I'm reposting it, this
time with additional information.
Sorry, I did see your post, and I am busy...
Understandable.
So, you also mentioned this case:
SET( VAR 321 CACHE STRING FORCE )
set(VAR )
message(${VAR}) - prints out 321
Actually I said that it prints 123 in 2.6.2 but 321 in 2.4.*
So, this was intentional. set(var ) removes the value of var, and var
becomes unset. This then re-exposes the cache variable VAR.
I know, I purposedly added the SET(VAR) line to discover the value in
the cache so as to confirm that if its type is UNINITIALIZED then FORCE
doesn't override it.
(IOW just to make sure I wasn't seeing the in-memory value instead)
So, I think this was intentional, sort of...
The issue is that we want the command line to be used.
Me too :)
So, if you have:
cmake -DFOO=456
Then, FOO should be set in the cache to the value 456 and something like
this:
SET( VAR 123 CACHE STRING )
Should not set VAR to 123
Right, I agree with this.
but it should set the type to STRING.
Hmm, OK.
From reading the source code I see that:
If I said -DFOO:BOOL=ON
SET( VAR OFF CACHE STRING )
Does not even change the type.
So what you want is that *untyped* command line variables can be given a
type via SET command, even without FORCE?
And you implement that via UNINITIALIZED, this is why there is this test
for UNINITIALIZED in cmSetCommand.cxx:
if(!it.IsAtEnd() (it.GetType() != cmCacheManager::UNINITIALIZED))
{
// if the set is trying to CACHE the value but the value
// is already in the cache and the type is not internal
// then leave now without setting any definitions in the cache
// or the makefile
if(cache type != cmCacheManager::INTERNAL !force)
{
return true;
}
}
so SET doesn't bail early in all cases it sees the var already without
FORCE and gets a chance to change the type later in AddCacheDefinition,
which is purposedly keeping the previous value in the case of an
UNINITIALIZED variable as it's purpose in this context is to only change
the type.
Right?
OK, then IMO what we need is to pass the force boolean down to
AddCacheDefinition, so it can do the right thing:
void cmMakefile::AddCacheDefinition(const char* name, const char* value,
const char* doc,
cmCacheManager::CacheEntryType type
bool force
)
{
const char* val = value;
cmCacheManager::CacheIterator it =
this-GetCacheManager()-GetCacheIterator(name);
if(!it.IsAtEnd() (it.GetType() == cmCacheManager::UNINITIALIZED)
it.Initialized())
{
if ( ! force )
val = it.GetValue();
I can generate proper diff patches if that looks OK to you, but I have
no idea how to test it except manually.
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] set CPACK_SOURCE_PACKAGE_FILE_NAME when running make package_source
Works great. Good for learning new tricks, too ;-) Thanx. On Tue, Nov 11, 2008 at 6:05 PM, Eric NOULARD [EMAIL PROTECTED] wrote: Le Tue, 11 Nov 2008 17:55:03 +0200, Ioan Calin Borcoman [EMAIL PROTECTED] a écrit : Hi, Is it possible to change the CPACK_SOURCE_PACKAGE_FILE_NAME when I run make package_source? I don't know, but I decide to do it differently. I would like to set it to a value like foo-`date +%Y%m%d_%H%M`. Is it possible? I do use a custom made UsePackageBackup.cmake macro attached to this mail for the same need. If you add: INCLUDE(UsePackageBackup) after INCLUDE(CPack) in your main CMakeLists.txt then you will have new package_source_backup target which will create a dated source package file. The macro use TGZ generator but you may change this easily from within the UsePackageBackup.cmake -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FILE(REMOVE ...)
Hi, how does FILE(REMOVE filename.h) works. If I use this command in my CMakeLists-file nothing happens. Regardless wheather the filename represents an existing or non-existing file. Greetings Michael ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Andreas,
On 11.11.08 14:12:39, Fernando Cacciola wrote:
Hi Andreas,
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker flags that were used to build the CGAL library.
These are all settings that affect any target added after the
inclusion of UseCGAL.cmake.
However, following the recommended practice (according to the
documentation of the deprecated link_libraries command), UseCGAL DOES
NOT call link_libraries. Instead, it realies on the user calling
target_link_libraries himself.
Well, I'm questioning this recommended practice because it's half
baked: It makes sense to allow users to control which targets are
linked against CGAL, but NOT if OTOH they cannot control which
targets are given the CGAL include directories, definitions and
flags.
That is, IMO, target_link_libraries makes little sense in the absence
of target_include_directories, target_add_definitions and
target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
Or am I missing something?
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Who is you in your sentence?
The UseXYZ modules which depends on the parameters to find_package(XYZ)
certainly knows it.
No it doesn't. UseXXX is a global thing, so it can't know which of the
targets in a project need which files.
Right, but the again a typical UseXYZ would do:
include_directories( ${XYZ_INCLUDE_DIR} )
add_definitions( ${XYZ_DEFINITIOS} )
set( CMAKE_CXX_FLAGS $XYZ_CXX_FLAGS) )
So it doesn't know which of your targets need the include dirs, the
definitions and the flags.. and it doesn't care.
Boost is a good example (albeit it doesn't use cmake to build itself).
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
And BOOST_LIBRARIES is defined as a list of all libraries indicated by
the user as boost components.
Right, but those are all I'm going to use in my project, which might or
might not be different from those that I want on target A and B.
Right.
So, if there where a UseBoost.cmake file
which would do
include_directories( ${BOOST_INCLUDE_DIR} )
add_definitions( ${BOOST_DEFINITIONS} )
then wouldn't it make sense for it to do
link_libraries( ${BOOST_LIBRARIES} )
as well?
That would mean _all_ my targets link against those libraries, which is
completely wrong.
Right.
In fact I don't understand why include_directories and
add_definitions are not deprecated as well
Which is precisely my point!! :)
target_link_libraries, which is GREAT, is actually pretty useless
without target_include_directories, target_add_definitions and
TARGET_CMAKE_CXX_FLAGS.
Yet OTOH given that those do not exists, it is just plain silly to
recommend not using link_libraries, because it gets less than half the
story right.
And IMO is equally silly to follow the recomendation and end up doing
what most Use files typically do: to set so much that affects all
subsequent targets, even compiler and linker flags, BUT simply define a
variable XYZ_LIBRARY so a user can decide which target to link againt
XYZ_LIBRARY.
I mean, being able to control this is cool, sure, but why can I only
control that and not the other equally critical settings???
IMO, if a user won't have real control over which targets actually use
XYZ (in all the extent to which using XYZ, as defined by
find_package(XYZ), means) then I rather don't bother them requiring
users to call target_link_libraries by hand (while everything else is
setup by the Use file itself). It's just silly.
So to restat my point, if a UseFile does this:
include_directories( ${XYZ_INCLUDE_DIR} )
add_definitions( ${XYZ_DEFINITIOS} )
set( CMAKE_CXX_FLAGS $XYZ_CXX_FLAGS) )
which shouldn't under the argument of what if I don't want that for all
my targets, then it should do this as well:
link_libraries( ${XYZ_LIBRARIES} )
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTANT!! SET CACHE FORCE not wortking with UNINITIALIZED variables
Le Tue, 11 Nov 2008 11:47:20 -0200,
Fernando Cacciola [EMAIL PROTECTED] a écrit :
Hi,
Since my last post about this got unnoticed I'm reposting it, this
time with additional information.
[...]
May be CMake devel are busy :-)
The culprint is in the following section of the cmake sources:
void cmMakefile::AddCacheDefinition(const char* name, const char*
value, const char* doc,
cmCacheManager::CacheEntryType
type) {
const char* val = value;
cmCacheManager::CacheIterator it =
this-GetCacheManager()-GetCacheIterator(name);
if(!it.IsAtEnd() (it.GetType() ==
cmCacheManager::UNINITIALIZED)
it.Initialized())
{
val = it.GetValue();
As you can see, when SET sees an UNINITIALIZED variable it just
ignores the value being passed on and just keeps the previous value.
After some CVS history browsing, the code is there at least since
CMake 2.4.4 (may be older).
IMO this is a bug, and I even wonder if that comparison didn't intend
to be != instead ??
The bug, if ever this is one should be elsewhere.
Fortunately, the variable is nevertheless overwritten into the cache,
with the old (wrong) value but the correct type, hence, the following
works around the bug:
SET( VAR 321 CACHE STRING FORCE )
SET( VAR 321 CACHE STRING FORCE )
MESSAGE( STATUS VAR=${VAR} )
That is, the first SET fixes the type, allowing the second SET to
do what it should.
Shall I add this to the tracker or is this behaviour on purpose??
I would say that this deserve a bug report at least in order to add
some documentation about the current behavior.
Nevertheless CMake 2.6.2 documentation (cmake --help) says:
-D var:type=value = Create a cmake cache entry.
and cmake --help-command SET says:
If CACHE is present, then the variable is put in the cache.
type and docstring are then ***required***.
Does this mean that in order to have a proper CACHE entry one MUST
specify type. Or more generally what is the purpose of
UNINITIALIZED cache entry.
I'm afraid we'll have to wait peacefully for CMake
developper spare time in order to have technical answer for this :=)
--
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] set CPACK_SOURCE_PACKAGE_FILE_NAME when running make package_source
Hi, Is it possible to change the CPACK_SOURCE_PACKAGE_FILE_NAME when I run make package_source? I would like to set it to a value like foo-`date +%Y%m%d_%H%M`. Is it possible? Thanx Ionutz ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] IMPORTANT!! SET CACHE FORCE not wortking with UNINITIALIZED variables
Hi,
Since my last post about this got unnoticed I'm reposting it, this time
with additional information.
If you run cmake with a definition in the command-line, like so:
cmake -DVAR=123 .
in 2.6.2 that goes into the cache as an UNINITIALIZED variable:
VAR:UNINITIALIZED=123
And, since it is of UNINITIALIZED type, SET doesn't set the value
indicated even if FORCE is used.
That is, with the following script:
SET( VAR 321 CACHE STRING FORCE )
MESSAGE( STATUS VAR=${VAR} )
Calling
cmake -DVAR=123 .
prints
-- VAR=123
While calling
cmake -DVAR:STRING=123 .
prints
-- VAR=321
The culprint is in the following section of the cmake sources:
void cmMakefile::AddCacheDefinition(const char* name, const char* value,
const char* doc,
cmCacheManager::CacheEntryType type)
{
const char* val = value;
cmCacheManager::CacheIterator it =
this-GetCacheManager()-GetCacheIterator(name);
if(!it.IsAtEnd() (it.GetType() == cmCacheManager::UNINITIALIZED)
it.Initialized())
{
val = it.GetValue();
As you can see, when SET sees an UNINITIALIZED variable it just ignores
the value being passed on and just keeps the previous value.
IMO this is a bug, and I even wonder if that comparison didn't intend to
be != instead ??
Fortunately, the variable is nevertheless overwritten into the cache,
with the old (wrong) value but the correct type, hence, the following
works around the bug:
SET( VAR 321 CACHE STRING FORCE )
SET( VAR 321 CACHE STRING FORCE )
MESSAGE( STATUS VAR=${VAR} )
That is, the first SET fixes the type, allowing the second SET to do
what it should.
Shall I add this to the tracker or is this behaviour on purpose??
TIA
Fernando Cacciola
if
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Am Tuesday 11 November 2008 19:13:43 schrieb Fernando Cacciola: target_link_libraries, which is GREAT, is actually pretty useless without target_include_directories, target_add_definitions and TARGET_CMAKE_CXX_FLAGS. Did you notice set_property(TARGET .)? There, you can do add target specific definitions (even per build type) and other stuff. Sadly, this is no replacement for target_include_directories() as you have to know the compiler syntax. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTANT!! SET CACHE FORCE not wortking with UNINITIALIZED variables
Eric NOULARD wrote:
Le Tue, 11 Nov 2008 11:47:20 -0200,
Fernando Cacciola [EMAIL PROTECTED] a écrit :
Hi,
Since my last post about this got unnoticed I'm reposting it, this
time with additional information.
[...]
May be CMake devel are busy :-)
Fair enough.
The culprint is in the following section of the cmake sources:
void cmMakefile::AddCacheDefinition(const char* name, const char*
value, const char* doc,
cmCacheManager::CacheEntryType
type) {
const char* val = value;
cmCacheManager::CacheIterator it =
this-GetCacheManager()-GetCacheIterator(name);
if(!it.IsAtEnd() (it.GetType() ==
cmCacheManager::UNINITIALIZED)
it.Initialized())
{
val = it.GetValue();
As you can see, when SET sees an UNINITIALIZED variable it just
ignores the value being passed on and just keeps the previous value.
After some CVS history browsing, the code is there at least since
CMake 2.4.4 (may be older).
IMO this is a bug, and I even wonder if that comparison didn't intend
to be != instead ??
The bug, if ever this is one should be elsewhere.
Or the this bug only shows up now because in 2.4.* variables specified
in the command line ARE NOT added into the cache as UNINITIALIZED.
I reported this in my previous post.
I mean, look at it and tell me honestly why on earth would the cached
value of variable of type UNINITIALIZED take precedence over the value
indicated on SET, for whatever UNINITIALIZED could possibly mean other
than, say, UNMUTABLE or so, in which case variables passed untyped on
the command line should not be of that type if it meant unmutable.
Fortunately, the variable is nevertheless overwritten into the cache,
with the old (wrong) value but the correct type, hence, the following
works around the bug:
SET( VAR 321 CACHE STRING FORCE )
SET( VAR 321 CACHE STRING FORCE )
MESSAGE( STATUS VAR=${VAR} )
That is, the first SET fixes the type, allowing the second SET to
do what it should.
Shall I add this to the tracker or is this behaviour on purpose??
I would say that this deserve a bug report at least in order to add
some documentation about the current behavior.
Nevertheless CMake 2.6.2 documentation (cmake --help) says:
-D var:type=value = Create a cmake cache entry.
and cmake --help-command SET says:
If CACHE is present, then the variable is put in the cache.
type and docstring are then ***required***.
Notice that this speaks of the SET command.
The UNINITIALIZED comes form defining the variable in the command-line
without a type.
Does this mean that in order to have a proper CACHE entry one MUST
specify type.
In the SET command, sure. I do that of course, it's even a syntax error
not to specify the TYPE.
In the command line however my users DON'T indicate any type, and I
don't think they should be expected to do so. I don't think this has
ever been the intention since most examples of variables given in the
command line are typeless.
So, if it is matter of improving documentation then it would be in the
command-line specification of variables where it should say that types
are required... if that's indeed the case, which I hope not.
Or more generally what is the purpose of
UNINITIALIZED cache entry.
I'm not sure and it's not even documented.
Yet you can see it in the cache.
I'm afraid we'll have to wait peacefully for CMake
developper spare time in order to have technical answer for this :=)
I'm afraid so
And not so peacefully in my case since I am pushing the deadline and I
still don't know if I should require my users to specify the type when
defining variables in the command line or not.. and when I said they
should, my earlier tester complained up front since they've never seen
this requirement before with cmake.
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
On 11.11.08 14:12:39, Fernando Cacciola wrote:
Hi Andreas,
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker flags that were used to build the CGAL library.
These are all settings that affect any target added after the
inclusion of UseCGAL.cmake.
However, following the recommended practice (according to the
documentation of the deprecated link_libraries command), UseCGAL DOES
NOT call link_libraries. Instead, it realies on the user calling
target_link_libraries himself.
Well, I'm questioning this recommended practice because it's half
baked: It makes sense to allow users to control which targets are
linked against CGAL, but NOT if OTOH they cannot control which
targets are given the CGAL include directories, definitions and
flags.
That is, IMO, target_link_libraries makes little sense in the absence
of target_include_directories, target_add_definitions and
target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
Or am I missing something?
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Who is you in your sentence?
The UseXYZ modules which depends on the parameters to find_package(XYZ)
certainly knows it.
No it doesn't. UseXXX is a global thing, so it can't know which of the
targets in a project need which files.
Boost is a good example (albeit it doesn't use cmake to build itself).
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
And BOOST_LIBRARIES is defined as a list of all libraries indicated by
the user as boost components.
Right, but those are all I'm going to use in my project, which might or
might not be different from those that I want on target A and B.
So, if there where a UseBoost.cmake file
which would do
include_directories( ${BOOST_INCLUDE_DIR} )
add_definitions( ${BOOST_DEFINITIONS} )
then wouldn't it make sense for it to do
link_libraries( ${BOOST_LIBRARIES} )
as well?
That would mean _all_ my targets link against those libraries, which is
completely wrong. In fact I don't understand why include_directories and
add_definitions are not deprecated as well, those might not be wanted or
can possibly even cause problems when building targets that don't depend on
them.
My point is that if a UseXYZ file defines taget-wide settings such as
Its not target-wide, its project-wide - or at least directory wide. So even
if you have all boost-linking targets of your project in one directory, you
might not want all of them to link against all the boost libs you use.
Maybe there are one or two libs that only need a subset of the boost-libs.
Andreas
--
You have a reputation for being thoroughly reliable and trustworthy.
A pity that it's totally undeserved.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Precompiled headers
2008/11/11 Yves Martelli [EMAIL PROTECTED]: Sorry to ask again, but speeding up my build would really help me and my colleagues in the context of a continuous build... Does CMake support precompiled headers when generating Makefiles? Not in mainstream CMake but there is [at least] one bug open on the subject: http://public.kitware.com/Bug/view.php?id=1260 -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] set CPACK_SOURCE_PACKAGE_FILE_NAME when running make package_source
Le Tue, 11 Nov 2008 17:55:03 +0200,
Ioan Calin Borcoman [EMAIL PROTECTED] a écrit :
Hi,
Is it possible to change the CPACK_SOURCE_PACKAGE_FILE_NAME when I run
make package_source?
I don't know, but I decide to do it differently.
I would like to set it to a value like foo-`date +%Y%m%d_%H%M`. Is it
possible?
I do use a custom made UsePackageBackup.cmake macro attached to this
mail for the same need.
If you add:
INCLUDE(UsePackageBackup)
after
INCLUDE(CPack)
in your main CMakeLists.txt
then you will have new
package_source_backup
target which will create a dated source package file.
The macro use TGZ generator but you may change this easily from within
the UsePackageBackup.cmake
--
Erk
#
# - Define a toplevel package_source_backup target
# which build a dated tarball
#
# Those CMake macros are provided by the TSP Developer Team
# https://savannah.nongnu.org/projects/tsp
#
IF (UNIX)
FILE(WRITE ${CMAKE_BINARY_DIR}/PackageBackup.cmake
MESSAGE(STATUS \Package Backup running...\)
INCLUDE(CPackSourceConfig.cmake)
MESSAGE(STATUS \Package Backup gets username...\)
# get the date
EXECUTE_PROCESS(COMMAND whoami
TIMEOUT 5
RESULT_VARIABLE WHO_RES
OUTPUT_VARIABLE WHO_OUT
ERROR_VARIABLE WHO_ERR
OUTPUT_STRIP_TRAILING_WHITESPACE)
MESSAGE(STATUS \Package Backup got \${WHO_OUT}.\)
MESSAGE(STATUS \Package Backup gets date...\)
# get the date
EXECUTE_PROCESS(COMMAND date +%d%b%Y-%Hh%M
TIMEOUT 5
RESULT_VARIABLE DATE_RES
OUTPUT_VARIABLE DATE_OUT
ERROR_VARIABLE DATE_ERR
OUTPUT_STRIP_TRAILING_WHITESPACE)
MESSAGE(STATUS \Package Backup got \${DATE_OUT}.\)
# run cpack
MESSAGE(STATUS \Package Backup running cpack...\)
EXECUTE_PROCESS(COMMAND cpack -G TGZ --config CPackSourceConfig.cmake
TIMEOUT 3600
WORKING_DIRECTORY \${CMAKE_BINARY_DIR})
MESSAGE(STATUS \Copy \${CPACK_SOURCE_PACKAGE_FILE_NAME}.tar.gz -- \${CPACK_SOURCE_PACKAGE_FILE_NAME}-\${WHO_OUT}-\${DATE_OUT}.tar.gz\)
EXECUTE_PROCESS(COMMAND \${CMAKE_COMMAND} -E copy \${CPACK_SOURCE_PACKAGE_FILE_NAME}.tar.gz \${CPACK_SOURCE_PACKAGE_FILE_NAME}-\${WHO_OUT}-\${DATE_OUT}.tar.gz)
MESSAGE(STATUS \Package backup done in: \${CPACK_SOURCE_PACKAGE_FILE_NAME}-\${WHO_OUT}-\${DATE_OUT}.tar.gz\)
)
#
# Add custom target
#
ADD_CUSTOM_TARGET(package_source_backup
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/PackageBackup.cmake
)
ENDIF(UNIX)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Le Tue, 11 Nov 2008 09:13:04 +0100, Mathias Fröhlich [EMAIL PROTECTED] a écrit : [...] Perhaps the abi can be determined without a try-compile, but I am not sure that would work on all platforms. That would be indeed the way cmake handles these things. But this requires plenty of special case handling. [...] plenty of interesting things cutted. ... and yes, at some point in the future somebody will start beating cmake because of being so slow. This guy will then start a new project for a build system. And people need again tell this guy that the other systems in this area are slow for a good reason. :) I would say that most of the time I don't want to buy for something I don't need. So even if I think I fully understand the need for ironed cmake support for cross-compile and multi-ABI lib I would say that, most of the time I DON'T NEED it. So please do not make me pay something I don't want but make it optional, something like: cmake -DCMAKE_CHECK_ABI:BOOL=TRUE or a new polcicy or anything which makes it optional (or enable me to switch it off). Now the trouble may comes from the fact we have to find a way to write FindXXX.cmake in a way they could be execute fast or iron **without changing the syntax**. I would say that the same find_library may be executed by cmake with either a [too]-simple find file or with a full link. It may be possible to add an optional option to find_library like LINK_SYMBOL which will indicates the symbol to link with. This optional option would be REQUIRED when cmake -DCMAKE_CHECK_ABI:BOOL=TRUE so that CMake would fail if it is not there in each used find_library. and really optional if when cmake The names and method is the first guess but the main idea is DO NOT MAKE this cmake behavior the default. Most of the time I do build project which are neither cross-compiled nor using multi ABI libs. I don't want to pay for it. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Addressing an external MS project as target
Floca Ralf Omar wrote: Hello, there is the following situation: I use CMake as build control system (Windows platform, MS Visual Studio) for my own project (A). A depends on a second project (B). The project-files of B are pre generated and not covered by my CMake-Scripts. I use INCLUDE_EXTERNAL_MSPROJECT to integrate B into my solution. Until this point everything works fine. But is there any way to address included external projects (like B) as a target in a CMake script. I would need this to add dependencies between A and B (e.g. ADD_DEPENDENCIES(A B)), so that B would also be build when I want to build A. In the documentation and the mailing list I have found no information how to do this. And it seems that INCLUDE_EXTERNAL_MSPROJECT has no possibilities to introduce a Target identifier (like ADD_CUSTOM_TARGET). I am thankful for any clues or tips that could help me to represent the project dependency in my CMake scripts. Kind regards, Ralf Floca I have not tried this, but INCLUDE_EXTERNAL_MSPROJECT_projectname should be the name of the target. So, this might work: include_external_msproject(B /some/path) add_dependencies(A B) Also, in the command itself you can list the targets it depends on: include_external_msproject(projectname location dep1 dep2 ...) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Addressing an external MS project as target
Bill Hoffman wrote: So, this might work: include_external_msproject(B /some/path) add_dependencies(A B) I meant to say this: add_dependencies(A INCLUDE_EXTERNAL_MSPROJECT_B) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] how to set 2 additional compile flags on target (VS2005)
Hi,
I'm trying to use precompiled headers with VS2005. Therefore, I need to
set on the target two additional compile flags: /Yu with the header to
be precompiled, and /Fp with the path of the resulting PCH.
But whatever I try, cmake will only set one of them.
The following will only set the second compile flag. in this case /Fp.
If I reverse the lines, it will set /Yu.
set_target_properties(
${target}
PROPERTIES
COMPILE_FLAGS /Yu${hdrfile}
COMPILE_FLAGS /Fp${pchpath}
)
If I put both compile flags on one line as following, it is not accepted
by CMake as there's an incorrect number of arguments:
set_target_properties(
${target}
PROPERTIES
COMPILE_FLAGS /Yu${hdrfile} /Fp${pchpath}
)
Splitting it into two statements as following, has the same effect (only
setting the second one)
set_target_properties(
${target}
PROPERTIES
COMPILE_FLAGS /Yu${hdrfile}
)
set_target_properties(
${target}
PROPERTIES
COMPILE_FLAGS /Fp${pchpath}
)
Using set_property with APPEND, has the effect that it concatenates both
flags with a semicolon, something like /Yufoobar.h;/Fpfoobar.pch, so
that VS thinks the header to be precompiled is called
foobar.h;/Fpfoobar.pch. Err, wrong =)
set_property(
TARGET ${target}
APPEND PROPERTY
COMPILE_FLAGS /Yu${hdrfile} /Fp${pchpath})
It even has this same concatenation effect when I split it into two
statements:
set_property(
TARGET ${target}
APPEND PROPERTY
COMPILE_FLAGS /Fp${pchpath})
set_property(
TARGET ${target}
APPEND PROPERTY
COMPILE_FLAGS /Yu${hdrfile})
And when I leave out the APPEND, we're back to square one where it only
sets the second compiler flag:
set_property(
TARGET ${target}
PROPERTY
COMPILE_FLAGS /Fp${pchpath})
set_property(
TARGET ${target}
PROPERTY
COMPILE_FLAGS /Yu${hdrfile})
So, my question obviously is: what's the proper way to set TWO (or more)
additional compiler flags on na target.
Thanks in advance,
Bram
PS: Technically, it's not really necessary to set /Fp, as the default is
fine, but it still strikes me as cumbersome.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Andreas,
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
compiler/linker flags that were used to build the CGAL library.
These are all settings that affect any target added after the inclusion
of UseCGAL.cmake.
However, following the recommended practice (according to the
documentation of the deprecated link_libraries command), UseCGAL DOES
NOT call link_libraries. Instead, it realies on the user calling
target_link_libraries himself.
Well, I'm questioning this recommended practice because it's half baked:
It makes sense to allow users to control which targets are linked
against CGAL, but NOT if OTOH they cannot control which targets are
given the CGAL include directories, definitions and flags.
That is, IMO, target_link_libraries makes little sense in the absence of
target_include_directories, target_add_definitions and target_*_FLAGS.
What it's so special about linking that only that command can be made
target specific???
Or am I missing something?
There are projects that have headers that are usable without linking
against any library. There are also projects installing their headers into
a common place, that have multiple libraries. In that latter case you'd
have include_directories() point to the common place for the headers, but
obviously you can't know which of the libraries needs to be linked in.
Who is you in your sentence?
The UseXYZ modules which depends on the parameters to find_package(XYZ)
certainly knows it.
Boost is a good example (albeit it doesn't use cmake to build itself).
There are various libraries shipped with it, they all install their headers
into includedir/boost/libraryname/ and the libs are of course directly
in libdir. And its common practice to have only includedir/boost in the
include-directories.
And BOOST_LIBRARIES is defined as a list of all libraries indicated by
the user as boost components. So, if there where a UseBoost.cmake file
which would do
include_directories( ${BOOST_INCLUDE_DIR} )
add_definitions( ${BOOST_DEFINITIONS} )
then wouldn't it make sense for it to do
link_libraries( ${BOOST_LIBRARIES} )
as well?
My point is that if a UseXYZ file defines taget-wide settings such as
includes, definitions etc.. then it should just as well define the link
libraries... hence, link_libraries should not be deprecated and stock
files like UseQt4 and UseVTK should us it (they don't FYI).
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] RE
I'm using precompiled header and CMake (I just wrote an Macro). If someone is intressted, just write me an email... It's for MSVC (7-9) only right now! - SirAnn -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Bill Hoffman Gesendet: Dienstag, 11. November 2008 16:02 An: Yves Martelli Cc: cmake@cmake.org Betreff: Re: [CMake] Precompiled headers Yves Martelli wrote: Sorry to ask again, but speeding up my build would really help me and my colleagues in the context of a continuous build... Does CMake support precompiled headers when generating Makefiles? Not directly, but it can be done. It is very compiler/platform specific... I know some projects have gotten it to work with some tool chains. I do not have a an example right now. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
