Re: [CMake] Installing FindCGAL.cmake
Hendrik Sattler wrote: Am Friday 14 November 2008 04:18:59 schrieb Fernando Cacciola: In preparing the cmake build system for CGAL I'm having this issue: Users can define CGAL_DIR explicitely when configuring their own programs in order to allow find_package(CGAL) to locate CGALConfig.cmake. OTOH, if FindCGAL.cmake is in the cmake modules path, they don't need to define CGAL_DIR at all. However, I'm not sure how to go about installing FindCGAL.cmake. If I merely add an install rule to put it in the actual cmake directory, users are then *forced* to run the install target with access privileges and they may not want or be allowed to do that. Use DESTDIR: make DESTDIR=~/local install Nope... my users don't want to do that... (or rather I don't know which DESTDIR, if any, they'll use at all, so the solution cannot involve anything like it) They want to install CGAL in the correct place, whatever that is, but without FindCGAL.cmake unless explictely indicated. Of course I can use an option variable at configuration time, but I was thinking on something less intrusive. Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing FindCGAL.cmake
Hendrik Sattler wrote: Fernando Cacciola schrieb: Nope... my users don't want to do that... (or rather I don't know which DESTDIR, if any, they'll use at all, so the solution cannot involve anything like it) They want to install CGAL in the correct place, whatever that is, but without FindCGAL.cmake unless explictely indicated. Of course I can use an option variable at configuration time, but I was thinking on something less intrusive. Why don't you offer FindCGAL.cmake as additional download (so they can drop that whereever they want) Which is precisely what they are needing to do right now. But it's not as user friendly as a simple sort of sudo make root-install and install the CGALConfig.cmake, only. It doesn't make sense to install both at the same time. Not really... FindCGAL.cmake basically locates and loads CGALConfig.cmake, which is better placed in the install tree since the binary folder (where it is first created) can be anywhere. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing FindCGAL.cmake
Hendrik Sattler wrote: Fernando Cacciola schrieb: and install the CGALConfig.cmake, only. It doesn't make sense to install both at the same time. Not really... FindCGAL.cmake basically locates and loads CGALConfig.cmake, which is better placed in the install tree since the binary folder (where it is first created) can be anywhere. So why exactly do you need FindCGAL.cmake, then? As I said in the initial post, the idea is to make it possible for my users to avoid having to specify CGAL_DIR. Are you doing extra stuff, there, that you cannot do in CGALConfig.cmake? One particular stuff that can't possibly be done in CGALConfig.cmake: locating it (CGALConfig.cmake). find_package() would automagically locate and load FindCGAL if it finds it in the modules search path, but it would only load CGALConfig.cmake if it is in the directory indicated by CGAL_DIR. That is, cmake doesn't *search* for CGALConfig.cmake, it merely looks for it at CGAL_DIR BTW: naming it CGAL-config.cmake would make more sense in your case. Why? I understood both names where exactly the same. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Installing FindCGAL.cmake
Hi, In preparing the cmake build system for CGAL I'm having this issue: Users can define CGAL_DIR explicitely when configuring their own programs in order to allow find_package(CGAL) to locate CGALConfig.cmake. OTOH, if FindCGAL.cmake is in the cmake modules path, they don't need to define CGAL_DIR at all. However, I'm not sure how to go about installing FindCGAL.cmake. If I merely add an install rule to put it in the actual cmake directory, users are then *forced* to run the install target with access privileges and they may not want or be allowed to do that. So, is there a way to create a normal user install target and a separate super user install target?? Something that would allow my users to do something like: make install sudo make root-install TIA Fernando Cacciola ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Bill,
Fernando Cacciola wrote:
Ha I see... that is 2.6 specific right?
There are still too many 2.4 versions shiped with Linux et al, and we
don't want to ask our users to *manually* upgrade cmake when they
already have one installed, so I'm keeping all compatible with at
least 2.4.5
Well, not much we can do about that but wait... :)
\
Indeed :)
We are telling our users to do:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
target_link_libraries
( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )
But then I wondered: why am I bothering them with that last line while
everything else is hidden in UseCGAL? After all if they do not won't
to link with that, which would be really odd, they better don't use
UseCGAL at all and rather just use the outcome of FindCGAL manually.
So IMO UseCGAL should be all or nothing. Wouldn't you agree?
For an executable is it not as important since there is no transitive
linking. However, link_libraries is a bit of a blunt instrument as it
will link with all the executables and libraries after it is called into
sub directories. So, I still think linking just specific libraries is
better than not. Also, it will be one less thing you have to change
when 2.6 comes out. What if the project had program1 and program2, and
program2 used VTK and CGAL, but program1 only used CGAL? Then the
link_libraries approach would link too much. The extra includes should
not hurt because VTK and CGAL should not have conflicting headers. So,
there is a still a benefit to specifically linking libraries.
In our case this scenario is just not possible at all since UseCGAL
overrides flags, so everything following UseCGAL must actually use CGAL
in all its glory :)
We tell our users to arrange CMakeLists.txt appropiately taking the
global side effects of UseCGAL into account.
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hendrik Sattler wrote:
Bill Hoffman schrieb:
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
so it works now with 2.4, and eventually upgrade it to use target
properties instead.
That sounds like a good way to go, and is similar to what the boost
folks are doing.
But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Why??
Additionally, that would make ${CGAL_USE_FILE} obsolete as you can put
the macro into FindCGAL.cmake.
Which is far from being a problem, or is it?
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Hendrik,
But it is not backwards-compatible and will fail to link on the new
version while it worked fine on the old version.
Why??
Because if the ${FOO_USE_FILE} doesn't do what it always does (globally
adding this stuff), you _have_ to insert the new macro call to make it
compile again. OTOH, this macro call will fail on the old version
because it doesn't exist.
(Assumed that FindFoo.cmake and ${FOO_USE_FILE} are shipped with cmake)
So you where referring to some existing UseFOO then?
UseCGAL doesn't really exist yet (we haven't released it), so at this
point I can do the right thing :)
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Colin, On Tue, 11 Nov 2008 16:13:43 -0200 Fernando Cacciola [EMAIL PROTECTED] wrote: Hi Andreas, On 11 Nov 2008 18:12:33 +0100, Andreas Pakulat wrote: 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. I agree. There should be a target_include_directories. This has bothered me as well. However, I would argue that target_link_libraries vs. link_libraries is more important than the possible target_include_directories vs. include_directories, since the linked libraries will directly affect the generated output (linking to unnecessary libraries is wasteful). Agreed, though definitions and, most important of all by far, compiler and linker flags are much more critical. And UseVTK, for example, changes compiler flags FOR EVERYTHING THAT FOLLOWS, even totally unrelated PARENT directories (because of the ways of the cache). So if target_link_libraries makes sense (and it sure does), imagine TARGET_CMAKE_CXX_FLAGS (or even better target_add_compiler|linker_flags) In contrast, including unused include-file-directories in the search path for the compiler will not affect the output (assuming there are no duplicated header file names in different paths, which I would argue should not be allowed). Except of course that you can't disallow it in all cases since completely different libraries cannot possibly prevent clashing with each other, and that would happen if you have find_package(X) then find_package(Y). But granted, if you have those two lines in the same cmake scripts you are likely to need both X and Y in the same target, so this is an unlikely scenario. So, I think that target_link_libraries is more important than target_include_directories, but we still should have a target_include_directories for the sake of consistency, clarity (specifically show what include directories are used by what files), and robustness. And as I said far much more important: target_add_definitions and a way to target compilers and linker flags, which is something Use files also define globally now. Another aspect of this is that perhaps 'target_include_directories' is not the right concept, but rather, since include files are needed by source code (not compiled targets), the following: source_include_directories(source-files ... INCLUDES include-dirs ...) I wonder if this would be useful in practice? I'm not sure it makes sense to draw a disctinction between stuff needed by source files and compiled targets. While in a makefile these all go as command line parameters to the compiler source by source, in a project files these are global properties of a target within the project, so IMO the conceptual entity the encapsulates all these is the target, not the source files. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
Hi Bill,
So, I guess I will comment on this... :)
:)
Originally CMake was directory based. We are moving towards being
target based. For directories, targets, and projects, there should be
a way to set:
- defines
- includes
- link libraries
- compiler flags
Hard to argue with that :)
Currently you can set:
compiler flags:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_FLAGS
define symbols:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:DEFINE_SYMBOL
libraries with target_link_libraries.
config based compile defines:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFINITIONS_CONFIG
Ha I see... that is 2.6 specific right?
There are still too many 2.4 versions shiped with Linux et al, and we
don't want to ask our users to *manually* upgrade cmake when they
already have one installed, so I'm keeping all compatible with at least
2.4.5
include_directories can only be set on a per directory basis. At some
point a target will have all the links, includes, and flags required to
use it stored somewhere, and that will come with the target. This can
be done now with macros and functions, the new CMake build for boost
does some of this. If someone wants to a bug entry could be created
for target specific include files, that would be good.
As for the title of the thread target_link_libraries should be used in
most cases. However link_libraries could still be a useful short cut.
The *practical* problem I have with target_link_libraries and which
originated this thread is the following:
We are telling our users to do:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
target_link_libraries
( program ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )
But then I wondered: why am I bothering them with that last line while
everything else is hidden in UseCGAL? After all if they do not won't to
link with that, which would be really odd, they better don't use UseCGAL
at all and rather just use the outcome of FindCGAL manually.
So IMO UseCGAL should be all or nothing. Wouldn't you agree?
OTOH, it could make sense to do the following:
find_packge( CGAL REQUIRED components )
include( ${CGAL_USE_FILE} )
add_executable( program ... )
use_CGAL( program )
In this case, the use_CGAL macro would set includes, definitions,
libraries etc, but for the specified target as much as possible
(depending on the current cmake support).
IIUC I can easily write the use_CGAL macro as:
include_directories
( ${CGAL_3RD_PARTY_INCLUDE_DIRS} ${CGAL_INCLUDE_DIRS} )
add_definitions
( ${CGAL_3RD_PARTY_DEFINITIONS}${CGAL_DEFINITIONS} )
link_directories
( ${CGAL_3RD_PARTY_LIBRARIES_DIRS} ${CGAL_LIBRARIES_DIR} )
target_link_libraries
( ${TARGET} ${CGAL_3RD_PARTY_LIBRARIES} ${CGAL_LIBRARIES} )
so it works now with 2.4, and eventually upgrade it to use target
properties instead.
What do yo think?
Note, CMake does use the link libraries for a target transitively. If
you do not want that, you can use:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES
Ha, interesting.. didn't know that.
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
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] 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
[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] 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
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] BUG in SET in 2.6.2 (and probably 2.6.*)
Hi people,
Consider the following:
# Forcibly set the value of a cache variable
set( VAR Hello CACHE STRING bla bla FORCE )
# Show in-memory value
message( STATUS VAR=${VAR} )
# Load cached value just in case the above SET
# overwrote only the in-memory value
set( VAR )
# Now show the cached value
message( STATUS VAR=${VAR} )
Now look at it closely and figure what do you expect it do do if CMake
is invoked like this:
cmake -DVAR=Goodbye .
?
The very first line is supposed to *overwrite* the value given by the
user becasue it says FORCE at the end.. right?
If you have 2.4.* around you can verify that this is indeed the case.
But if you have 2.6.2 (and possibly any 2.6) you'll be surprised to see
it printing Goodby instead, and twice.
That is, under 2.6.2 the SET command has no effect at all in spite the
FORCE option.
I found by trial and error that if you specify the type of the variable
in the command line, then the overriding SET in the script does work:
CMAKE -DVAR:STRING=Goodbye
Prints Hello twice, as expected and as in 2.4.*
This behaviour is not documented (and it's not even backwards
compatible) so I think it is a bug.
I even guess it is related to the fact that in 2.6.2 variables given in
the command line are stored in the cache with the type UNINITIALIZED
(which is also undocumented), so I'm guessing the SET command is bailing
out due to the type mismatch.
IMO this is a serious bug since now I need to tell my users to specify
the type as well if they are passing variables in the command-line,
which they are finding quite annoying. (annoying that without the type
then the whole build just doesn't work).
FWIW, in the above simplified example the issue might seem unimportant,
so here's the real use case:
# This *adds* 'this_and_that' to whatever the user defined in VAR,
# if any.
#
set( VAR ${VAR} this_and_that CACHE STRING bla bla FORCE )
The bug reported has the effect that 'this_and_that' is silently
not added at all, but only if the user passed -DVAR=whatever.
It works fine if the user doesn't pass any VAR or specifies
the type correctly as in: -DVAR:STRING=whatever
Shall I add this to the bug tracker?
Is there any workaround which doesn't require users to specify the type?
TIA
Fernando Cacciola
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] link_libraries vs target_link_libraries
Hi people,
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?
TIA
Fernando Cacciola
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] BUG in TRY_COMPILE with multiple includes
Hi,
Consider the following sample project:
project( FOOL C CXX )
try_compile( X_COMPILE_RES
${CMAKE_BINARY_DIR}
${CMAKE_SOURCE_DIR}/X.cpp
CMAKE_FLAGS
-DINCLUDE_DIRECTORIES:STRING=${CMAKE_SOURCE_DIR}/includeA;${CMAKE_SOURCE_DIR}/includeB
OUTPUT_VARIABLE X_OUTPUT
)
message( STATUS ${X_OUTPUT} )
X.cpp includes foo.h from includeA and bar.h from includeB.
When trying compile this, I get an error that bar.h is not found.
Using --debug-trycompile I can see that the second include is indeed
missing, as the temporary cache shows this:
//No help, variable specified on the command line.
INCLUDE_DIRECTORIES:STRING=C:/Work/Active/Projects/includeA
AFAICT this is a bug.
I tested it in versions 2.4.5, 2.4.7, 2.6.0 and CMake 2.6.1
Has it been reported before? If not, I'll file a report.
Does anyone know of a workaround?
TIA
Fernando Cacciola
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BUG in TRY_COMPILE with multiple includes
Fernando Cacciola wrote:
try_compile( X_COMPILE_RES
${CMAKE_BINARY_DIR}
${CMAKE_SOURCE_DIR}/X.cpp
CMAKE_FLAGS
-DINCLUDE_DIRECTORIES:STRING=${CMAKE_SOURCE_DIR}/includeA;${CMAKE_SOURCE_DIR}/includeB
OK.
By looking at the source code I realize that each flag must be passed
as a single string:
Like this:
CMAKE_FLAGS
-DINCLUDE_DIRECTORIES:STRING=${CMAKE_SOURCE_DIR}/includeA;${CMAKE_SOURCE_DIR}/includeB
(Notice the quotes encompass the -DINCLUDE.. )
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Why is FindOpenGL in Mac looking for OpenGL/gl.h??
Hi there, While I am not a mac user myself, users reported to me that at least in Tiger and Leopard, gl.h is located in directory GL (as in any other *NIX), not directory OpenGL. Is this a bug in the module? Or are there OS X systems out there where gl.h is located under OpenGL? TIA Fernando Cacciola ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why is FindOpenGL in Mac looking for OpenGL/gl.h??
Mike Jackson wrote: The header is located in a framework called OpenGL.framework and the include style for frameworks is the name of the framework (minus the extension) and then the header file, so on OS X the proper include would be: #include OpenGL/gl.h But do you know for a fact that it is like so in the particular case of gl.h?? I'm porting the existing and fully working custom build system of a large project to cmake. This project headers are (and have been for a long time) including GL/gl.h *even* on the Mac, and the current build system is searching for gl.h under GL, even for the Mac as well. Sometimes having your own OpenGL.h header with the following can help to alleviate these problems: This is exactly what I suggested, but the users responded that gl.h IS NOT under OpenGL but under GL. In fact, they even asked me why on earth is cmake looking for it under OpenGL instead of GL? Keep in mind that this is a working project which builds and run correctly via the old shell-based build system.. it is my cmake port wich fails. Best Fernando Cacciola ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why is FindOpenGL in Mac looking for OpenGL/gl.h??
Fernando Cacciola wrote: Mike Jackson wrote: The header is located in a framework called OpenGL.framework and the include style for frameworks is the name of the framework (minus the extension) and then the header file, so on OS X the proper include would be: #include OpenGL/gl.h Hmmm, google says you are right.. there are tons of posts stating that it is OpenGL/gl.h and not GL/gl.h under OS X. Best Fernando Cacciola ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why is FindOpenGL in Mac looking for OpenGL/gl.h??
Mike Jackson wrote: /System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/gl.h That is the path on both Tiger and Leopard. Don't know what to tell you. It has been like this for at least 10.3 on up. I am not sure how they are getting away with GL/gl.h ... WAIT... Is this an X11 Application? I'm totally Mac agnostic, but I think it is. The project is a library and uses Qt for graphical output, so I guess that means it is an X11 library not only on UNIX/Linux but on Mac as well. In that case I think the include path would be: /usr/X11/include/GL/gl.h which explains this.. Is that correct for your situation? Apparently, yes. My user reported that locate gl.h shows up precisely that path. I'm not sure what does that mean though. Should FindOpenGL.cmake search for both cases and define a compile flag telling which path prefix to use? TIA Fernando Cacciola Mike Jackson - BlueQuartz Software Consulting www.bluequartz.net [EMAIL PROTECTED] On Aug 28, 2008, at 8:42 AM, Fernando Cacciola wrote: Mike Jackson wrote: The header is located in a framework called OpenGL.framework and the include style for frameworks is the name of the framework (minus the extension) and then the header file, so on OS X the proper include would be: #include OpenGL/gl.h But do you know for a fact that it is like so in the particular case of gl.h?? I'm porting the existing and fully working custom build system of a large project to cmake. This project headers are (and have been for a long time) including GL/gl.h *even* on the Mac, and the current build system is searching for gl.h under GL, even for the Mac as well. Sometimes having your own OpenGL.h header with the following can help to alleviate these problems: This is exactly what I suggested, but the users responded that gl.h IS NOT under OpenGL but under GL. In fact, they even asked me why on earth is cmake looking for it under OpenGL instead of GL? Keep in mind that this is a working project which builds and run correctly via the old shell-based build system.. it is my cmake port wich fails. Best Fernando Cacciola ___ 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
Re: [CMake] Why is FindOpenGL in Mac looking for OpenGL/gl.h??
Mike Jackson wrote: Which version of Qt are you using? Qt 4.x is only officially supported on the native window system (Quartz/Carbon) NOT X11. Qt 3.x _may_ run under X11 on OS X so I don't know. We still use Qt 3.x as a matter of fact. If some one new to OS X just did a locate on gl.h then they may have found the wrong gl.h, or they really are running your project as an X11 application (non native window environment on OS X). Our users will run whatever Qt is generating.. it could be an X11 app in the case of Qt 3.x, I don't know. Btw, my user reported that OpenGl/gl.h does in fact compile, so it seems we'll fix it at the header file side via an __APPLE__ guard. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Externally hooking a FindXYZ module
Yuri V. Timenkov wrote: [snip] Is there a better way?? First, you can move linking flags logic outside of FindGL.cmake file, therefore you don't need customization. Of course... is just that I precisely don't want to do that because this affects several unrelated projects and I don't want each and every programmer to add the workaround manually after each and every call to find_package(OpenGL). Technically, it is a bug in the find module, and I don't want the rest of the team to learn how to workaround it. Alternatively you can copy this file to your custom modules directory and do not call original one. And I also don't want to do that because my system is deployed on several users each having its own version of cmake, so I don't want to hard code a particular version of FindOpenGL.cmake by distributing it unless I really don't have any other choice. Best Fernando Cacciola ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] unset() command
Alan W. Irwin wrote:
On 2008-08-20 14:07-0400 Brad King wrote:
Alan W. Irwin wrote:
if(FOO)
still gives different results depending on whether there has ever been a
set command executed for the variable.
Really? Can you provide example code demonstrating this?
OOPS. Sorry for that noise.
However, I would like to point out there is still a documentation concern
here. Here is what is stated about DEFINED
if(DEFINED variable)
True if the given variable is defined. It does not matter if the
variable is true or false just if it has been set.
So if you interpret the command set(FOO) as setting the variable, then
the
documentation implies
if(DEFINED FOO)
will be true, but in fact my tests show it is false (both in 2.4.8 and
2.6.0) just like you stated. A small addition to this area of the
documentation concerning the special case of set(variable) (i.e., with no
value) is warranted. Also, the documentation for the SET command currently
(2.6.1) says the variable is removed from the parent scope when there is no
value. Shouldn't you either drop the parent adjective (or better yet
in my
view) simply say the variable is undefined (as if it had never been set),
instead?
IMO it should be documented even more precisely, because set(var) clears
the in memory value of the variable, but it doesn't clear it in the
cache, thus, if the variable happens to be in the cache, any operation
that needs its value will in fact fetch it back from the cache.
This undocumented feature is in fact the way to get variables out of
subdirs:
root/CMakeLists.txt
add_subdirectory(sub)
set(result)
message( STATUS result=${result} )
root/sub/CMakeLists.txt
set(result I'm a subdir result! cache internal force )
HTH
Fernando Cacciola
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] unset() command
Brad King wrote: Philip Lowman wrote: On Wed, Aug 20, 2008 at 10:54 AM, Brad King [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The set command already supports unsetting: set(FOO xyz) set(FOO) # unsets if(DEFINED FOO) message(This message does not appear.) endif(DEFINED FOO) I think it should just be fixed for CACHE and ENV variables. I knew that set() supported unsetting local variables but wasn't sure it would be safe to extend it to CACHE and ENV variables as a bugfix. Regardless of whether this is appropriate to do or not adding an unset() command also seemed to make the language simpler to understand because: set(FOO) as someone else pointed out, is somewhat confusing. Without referencing the documentation many programmers might think this defines a variable called FOO and sets it to empty but what it really is doing is *undefining* the variable FOO entirely if it exists. Okay, I agree. It will be easier and more readable to add the unset command than to extend the set command to unset things :) However, this: unset(MY_CACHE_VARIABLE) should not remove the cache entry. It should only unset the CMake variable. In order to remove the cache entry, we should require unset(MY_CACHE_VARIABLE CACHE) Otherwise there is no way to remove the variable without removing the cache entry. Makes sense. And while you are it.. I currently use: set(var) to read the value back from the cache (very usefull somtimes), but this is undocumented and extremely none-obvous, so, can we have a fetch(var) as well? Should I formally suggest that via a bug report? TIA Fernando Cacciola ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Externally hooking a FindXYZ module
Hi people,
It turns out that Mac's Leopard OS needs a fix for OpenGL. The fix
itself has been discussed in this list a while back:
http://www.mail-archive.com/cmake@cmake.org/msg09358.html
I need to incorporate that fix into production code, and I don't want to
distribute my own hacked up version FindOpenGL.cmake, not a real one at
least, so I wonder, is there a way to hook into the find_package behaviour?
The only hack I could come up was stubbing a Find module
in this way:
(1)
At the most top level CMakeLists.txt:
# Save aside the default modules path.
set(ORIGINAL_CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} )
# Prepend a project specific path so my modules take precedence
set(CMAKE_MODULE_PATH cmake_modules ${CMAKE_MODULE_PATH} )
(2)
Then at the local cmake_modules folder, add a FindOpenGL.cmake stub
with this:
# Avoid recursion
if ( NOT FIND_OPENGL_WRAPPER )
set ( FIND_OPENGL_WRAPPER 1 )
set(SAVED_CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} )
set(CMAKE_MODULE_PATH ${ORIGINAL_CMAKE_MODULE_PATH} )
# This calls the real module.
find_package(OpenGL)
# Here is the post-processing to fix OpenGL for leopard
if ( OPENGL_FOUND AND APPLE_LEOPARD )
set (CMAKE_SHARED_LINKER_FLAGS -Wl,-dylib_file,/System/
Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/
System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib)
endif()
# reset the modules path.
set(CMAKE_MODULE_PATH ${SAVED_CMAKE_MODULE_PATH} )
endif()
Is there a better way??
TIA
Fernando Cacciola
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE_CXX_COMPILER and the cache
Hi people,
I'm trying to understand a user report which says that load_cache ignores
CMAKE_CXX_COMPILER (and I need it to load it!!)
While playing around with this unfortunate fact, it became apparent that
this particular variable is not read from the cache at all (not even from
the current cache).
I can tell because I can read in the current CMakeCache.txt that in fact it
contains the value which should have been loaded from the saved cache, yet a
MESSAGE commands reveals that this cached value is not the same as the
in-memory value of the variable.
Is that so?? is this a memory-only variable whose cache value is never read
in (thus can end up being completely incoherent, as in my case) ?
I know a user can set the enviroment variable CXX in order to specify the
compiler, but, are there other magical variables like this I should know
about, that is, which not being internal nor static nor excluded are
nevertheless not read in via load_cache?
And a related question: can a user pass a sort of uninitialized value via
the -D command line switch?
I am using cmake in an automated context where the call cmake is done by a
script.
If I use someting like this:
cmake -DCMAKE_CXX_COMPILER=${USER_CXX_COMPILER}
it won't work when the intention is NOT to specify that (the usual case),
unless a value of NOTFOUND or is interpreted as such.
TIA
Fernando Cacciola
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindBoost.cmake from 2.6
Hi Doug, Hi Fernando, [snip] (4) The two loops over _boost_TEST_VERSIONS are nearly indentical, and it's a bit complicated, so I would put that in a macro to make it more readable, discriminating the search path just around the call to find_path (where it matters) With CMake 2.6.1, the HINTS feature of find_path allows us to collapse these two loops into a single loop. OK, then. So, on what platforms does this additional version search stuff work? I certainly doesn't on my windows machine (yes, I tested it). It's meant for *nix platforms, where Boost.Build installs headers into versioned directories. Ha OK. (8) The check minimum version stuff is not working for me because the Boost_VERSION_* variables are undefined by the time they are compared to the Boost_FIND_VERSION_* requirement. Does it work for you there? This has been working for me for a while... OK, I found the problem today. The version is parsed (from version.hpp) into a variable named Booist_MAJOR_VERSION (et al) But the comparison code incorrectly uses Boost_VERSION_MAJOR. (Haven't tryed the latest patch though, just the official 2.6) (9) It is documented that this requires CMake 2.5 (which is 2.6 for us end users). And later overdocumented that this ships with CMake 2.6 so the version is always right. Well, strictly speaking one can use *this* module with earlier cmake versions, such as 2.4.7 which is still largely used in many linuxes, by emulating the additional find_package feautres. That is, instead of calling it like: find_package(Boost 1.37.1 COMPONENTS thread ) call it like this: set( Boost_FIND_VERSION 1.37.1 ) set( Boost_FIND_VERSION_MAJOR 1 ) set( Boost_FIND_VERSION_MINOR 37 ) set( Boost_FIND_VERSION_PATCH 1 ) set( Boost_FIND_COMPONENTS thread ) find_package(Boost) which works just the same with the old find_package (this is in fact what I'm doing in CGAL to avoid requiring users to install CMake 2.6 which is usually not just a simple apt-get/rmp call in many linuxes) I'm not quite sure what to do about this... with the FindBoost we ship in CMake 2.6.1, we should take advantage of CMake's features (e.g., the new HINTS feature, which eliminates a bunch of redundant code). Should we maintain a separate version of FindBoost for older versions of CMake? I don't know, but I'm concerned about the maintenance burden there, particularly for a complicated module like this one. Anyway, I'm working on a bunch of issues with FindBoost, and will ping the list when I think I have it right. No, sorry, I was clear enough because my example code was wrong though. I meant that this: I tried *this* version of FindBoost with 2.4.7 and 2.4.8 and it just works :) with one exception: the version number in the find_package command is ignored prior to 2.6. But, that exception doesn't matter in practice becasue you can redundantly store the minimum required version manually in vairables of the form Boost_FIND_VERSION etc, like this: set( Boost_FIND_VERSION 1.33.1 ) set( Boost_FIND_VERSION_MAJOR 1 ) set( Boost_FIND_VERSION_MINOR 33 ) set( Boost_FIND_VERSION_PATCH 1 ) find_package(Boost 1.33.1 REQUIRED thread whatever ) that code works in 2.4.7, 2.4.8 and 2.6 as far as I tested it. And in all cases with the same FindBoost.cmake (the one we are discussing) Best -- Fernando Cacciola SciSoft http://scisoft-consulting.com http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindBoost.cmake from 2.6
Hi Andreas,
On 03.07.08 12:23:11, Doug Gregor wrote:
On Tue, Jul 1, 2008 at 1:24 PM, Fernando Cacciola
[EMAIL PROTECTED] wrote:
(7)
I couldn't understand the dicotomy between the cached and non-cached
versions of the include dirs:
Boost_INCLUDE_DIRS vs Boost_INCLUDE_DIR
What's the choice for? What doesn't the library dir, or for that matter,
the
libraries list offer the same choice?
I actually don't know why this is the why it is, sorry.
I'll try to read the rest later and answer everything, but for now just
this: The module needs to be fully backwards compatible to the CMake 2.4
version (thats why it was included in 2.6.0), and in cmake 2.4 you had
only 2 variables, one for include dirs one for library dirs and did
something like
link_directories( ${Boost_LIBRARY_DIRS} )
target_link_libraries( foo boost-thread )
Hmm, this explains why there is a cached Boost_INCLUDE_DIRS and a
memory-onlu Boost_INCLUDE_DIR?
If so I don't get it.. can you elaborate?
Andreas
(9)
It is documented that this requires CMake 2.5 (which is 2.6 for us end
users). And later overdocumented that this ships with CMake 2.6 so the
version is always right.
Well, strictly speaking one can use *this* module with earlier cmake
versions, such as 2.4.7 which is still largely used in many linuxes, by
emulating the additional find_package feautres.
That is, instead of calling it like:
find_package(Boost 1.37.1 COMPONENTS thread )
call it like this:
set( Boost_FIND_VERSION 1.37.1 )
set( Boost_FIND_VERSION_MAJOR 1 )
set( Boost_FIND_VERSION_MINOR 37 )
set( Boost_FIND_VERSION_PATCH 1 )
set( Boost_FIND_COMPONENTS thread )
find_package(Boost)
which works just the same with the old find_package (this is in fact
what
I'm doing in CGAL to avoid requiring users to install CMake 2.6 which is
usually not just a simple apt-get/rmp call in many linuxes)
I'm not quite sure what to do about this... with the FindBoost we ship
in CMake 2.6.1, we should take advantage of CMake's features (e.g.,
the new HINTS feature, which eliminates a bunch of redundant code).
The reason its so backwards compatible is that I wanted to be
kdevplatform's (kde module) copy to be as similar as possible (and that
one needs to work with cmake 2.4) so that later when KDE depends on
CMake 2.6 I'll have to do as little porting of our find-boost-code as
possible.
In fact, I've tested it with 2.4.7, 2.4.8 and 2.6 amd it just worked (with
the versioning detail I explained in my response to Doug)
Best
Fernando
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindBoost.cmake from 2.6
Doug Gregor wrote: On Thu, Jul 3, 2008 at 12:23 PM, Doug Gregor [EMAIL PROTECTED] wrote: Anyway, I'm working on a bunch of issues with FindBoost, and will ping the list when I think I have it right. There's a much-improved FindBoost module now in CMake CVS. Hopefully it will get merge in to the next RC for 2.6.1. Cool! I mean to ship *this* version FindBoost with the next CGAL release (out build system already uses a bunch of custom cmake modules so this is transparenbt for the user). Is that OK? I can't require CGAL users to upgrade to cmake 2.6 but I can give them the latest FindBoost. Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindBoost.cmake from 2.6
Hi Andreas Pakulat,
I'm in charge of the CMake build installation for CGAL (www.cgal.org) and I
so far had been using my own FindBoost module hoping to get rid of it as
soon as the official module got improved.
While the latest FindBoost is a significant improvement over the previous
version, there are still a few issues with it:
(1)
It should use $ENV{ProgramFiles} instead of C:\Program Files
(2)
If you google for both BOOSTROOT and BOOST_ROOT you'll find that both
enviroment variables are equally used among the large boost users community,
thus I would suggest to use both in the module. In particular, CGAL had long
been using BOOSTROOT, and I'd hate to tell our users to rename that.
(3)
The following logic:
IF( WIN32 )
SET(_boost_INCLUDE_SEARCH_DIRS ${BOOST_ROOT}
${_boost_INCLUDE_SEARCH_DIRS})
ELSE( WIN32 )
SET(_boost_INCLUDE_SEARCH_DIRS ${BOOST_ROOT}/include
${_boost_INCLUDE_SEARCH_DIRS})
ENDIF( WIN32 )
is indeed correct and needed since on windows the root folder is itself the
include folder.
However, this logic is used for the case of the CMake variable BOOST_ROOT,
but not for the enviroment variable BOOST_ROOT
(this in fact causes the search to fail in my machine when I arrange it to
depend solely on the enviroment variable BOOST_ROOT)
I suggest to unify the code by doing:
if ( NOT BOOST_ROOT AND NOT $ENV{BOOST_ROOT} STREQUAL )
set( BOOST_ROOT $ENV{BOOST_ROOT) )
endif()
if ( NOT BOOST_ROOT AND NOT $ENV{BOOSTROOT} STREQUAL )
set( BOOST_ROOT $ENV{BOOSTROOT) )
endif()
file(TO_CMAKE_PATH ${BOOST_ROOT} BOOST_ROOT)
and then just proceed to use BOOST_ROOT as it does now
The same goes for BOOST_INCLUDE_DIR and BOOST_LIBRARY_DIRS
BTW, why is the above path conversion gone in the 2.6 version??
(4)
The two loops over _boost_TEST_VERSIONS are nearly indentical, and it's a
bit complicated, so I would put that in a macro to make it more readable,
discriminating the search path just around the call to find_path (where it
matters)
And not just that:
Under windows, boost is installed on a folder of the form boost_x_y_z, not
boost-x_y_z, yet the suffix is constructed as:
SET(_boost_PATH_SUFFIX
boost-${_boost_VER}
)
Notice the boost- instead of boost_
So, on what platforms does this additional version search stuff work? I
certainly doesn't on my windows machine (yes, I tested it).
(5)
One can use cygwin to run other compilers besides gcc. In fact, that's what
we do in CGAL, so this:
IF (CYGWIN)
SET (_boost_COMPILER -gcc)
ENDIF (CYGWIN)
just breaks any previous MSVC detection.
Since -gcc is already the fallback value I would just remove those lines.
(6)
Also, in at least 2.4.7, MSCV80 is incorrectly set for VC90 (besides
MSCV90), so the MSVC version discrimination should be reversed and nested:
if ( MSVC90 )
...
elseif ( MSVC80 )
...
elseif ( MSVC71 )
...
endif()
(7)
I couldn't understand the dicotomy between the cached and non-cached
versions of the include dirs:
Boost_INCLUDE_DIRS vs Boost_INCLUDE_DIR
What's the choice for? What doesn't the library dir, or for that matter, the
libraries list offer the same choice?
(8)
The check minimum version stuff is not working for me because the
Boost_VERSION_* variables are undefined by the time they are compared to the
Boost_FIND_VERSION_* requirement.
Does it work for you there?
(9)
It is documented that this requires CMake 2.5 (which is 2.6 for us end
users). And later overdocumented that this ships with CMake 2.6 so the
version is always right.
Well, strictly speaking one can use *this* module with earlier cmake
versions, such as 2.4.7 which is still largely used in many linuxes, by
emulating the additional find_package feautres.
That is, instead of calling it like:
find_package(Boost 1.37.1 COMPONENTS thread )
call it like this:
set( Boost_FIND_VERSION 1.37.1 )
set( Boost_FIND_VERSION_MAJOR 1 )
set( Boost_FIND_VERSION_MINOR 37 )
set( Boost_FIND_VERSION_PATCH 1 )
set( Boost_FIND_COMPONENTS thread )
find_package(Boost)
which works just the same with the old find_package (this is in fact what
I'm doing in CGAL to avoid requiring users to install CMake 2.6 which is
usually not just a simple apt-get/rmp call in many linuxes)
Best regards
--
Fernando Cacciola
SciSoft
http://scisoft-consulting.com
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] PGI's pgCC compiler?
Hi, It seems that pgCC is not supported even in 2.6. In that case it is just a matter of adding a pgcc.cmake file with the appropiate settings right? or would the CMake binary itself need some patch? And btw, has anybody out there such a pgcc.cmake? :) TIA -- Fernando Cacciola SciSoft http://scisoft-consulting.com http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Status of Buf #3980 in CMake 2.6?
Hi, I just got a report from a user saying that cmake doe not recognize his Sun Studio CC compiler. I found on the list archives that this has been reported mid 2006. Is the problem fixed in CMake 2.6? He is using 2.4-8 TIA -- Fernando Cacciola SciSoft http://scisoft-consulting.com http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Hiding a variable from the GUI
Hi,
One of my users reported that the filenames of several header files appeared
in the advanced section when using CMakeSetup/ccmake. Eventually I tracked
down the problem to some macro using find_file.
It turns out that the variable where find_file (and family) reports the
result is automatically cached whether I like or not. My code was using
mark_as_advanced but that was not enough as my users just didn't want the
variable in the GUI at all.
Eventually I came up with the following trivial macro mark_as_internal
which I used to hide away these unwanted variables:
macro ( mark_as_internal _var )
set ( ${_var} ${${_var}} CACHE INTERNAL hide this! FORCE )
endmacro( mark_as_internal _var )
but I wonder:
Is there a better way?
Shouldn't ALL the commands that create/define variables (like find_*) accept
a NO_CACHE option? or at the very least an INTERNAL option?
TIA
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Windows CMake under cygwin
Hi People,
Due to some project specific constrains, I need to use cmake within cygwin
but to compile using Visual C++ via nmake.
Since the cygwin cmake doesn't support nmake I must use the windows cmake
binary, but naturally knowing that I am running under cygwin.
I couldn't find any preset variable that could tell me this, so I'm using
the follow code to that effect:
if ( WIN32 )
find_program(CMAKE_UNAME uname /bin /usr/bin /usr/local/bin )
if(CMAKE_UNAME)
exec_program(uname ARGS -s OUTPUT_VARIABLE CMAKE_SYSTEM_NAME2)
if ( CMAKE_SYSTEM_NAME2 MATCHES CYGWIN )
message( STATUS This is the Windows CMake running within the cygwin
platform. )
set( WIN32_CMAKE_ON_CYGWIN TRUE CACHE INTERNAL This is the cygwin
platform. )
endif()
endif()
endif()
Any crictisim is more than welcome at this point :)
I needed this new WIN32_CMAKE_ON_CYGWIN variable to correctly handle
installation within the cygwin hierarchy.
The follwing code:
if ( WIN32_CMAKE_ON_CYGWIN )
exec_program(cygpath ARGS -w ${CMAKE_INSTALL_PREFIX} OUTPUT_VARIABLE
CMAKE_INSTALL_PREFIX2 )
file ( TO_CMAKE_PATH ${CMAKE_INSTALL_PREFIX2} CMAKE_INSTALL_PREFIX )
endif()
Allows my users to set the install prefix either
as -DCMAKE_INSTALL_PREFIX=/usr/local
or -DCMAKE_INSTALL_PREFIX=C:\MyLibraries\ProjectXYZ.
(NOTE: In Vista the default %PROGRAMFILES% prefix doesn't really work
because of access restrictions which I couldn't get cygwin it to have.)
FYI, that transformation turns /usr/local into C:/cygwin/usr/local,
which I found to be needed by the windows cmake binary as it uses low-level
FILE( INSTALL ) commands to do the actual installation when nmake install
is executed.
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Windows CMake under cygwin
Hi Bill, Fernando Cacciola wrote: Hi People, Due to some project specific constrains, I need to use cmake within cygwin but to compile using Visual C++ via nmake. Since the cygwin cmake doesn't support nmake I must use the windows cmake binary, but naturally knowing that I am running under cygwin. Can you explain better what you are trying to do? If you are going to use visual C++, then you can run cmake from a cygwin shell and create nmake files no problem. I do this all the time. What is it that you want to do with cygwin from visual stuido C++? We have a testing system that I haven't yet ported to CTest, etc... which is heavily based on shell scripts. To test against Visual C++ I run the testing script under cygwin, but then I need to use the windows cmake binary since the cygwin version of cmake doesn't generate NMakefiles (just ordinary makefiles) It all works out of the box provided the enviroment is properly set for the command line Visual C++, but I stumble upon a problem yesterday: one of my users wanted to do nmake install and get the results under /usr/local within cygwin (as the previous non-cmake build system was doing). It turned out that /usr/local is not a valid path for the windows cmake binary (which runs outside cygwin) so I needed to add some code to fix that path, but of course, only in that specific condition: windows cmake under cygwin (so I added the posted code that defines WIN32_CMAKE_ON_CYGWIN). As I said in a couple of occasions I am porting an existing build system so I have lots of requirements that are perhaps unnatural for CMake, but which I need to satisfy nonetheless. Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Lua in a nutshell
Hi Brandon, On Mon, Mar 3, 2008 at 5:11 PM, Fernando Cacciola [EMAIL PROTECTED] wrote: Brandon wrote: I am starting to wonder if the whole Lua thing is indeed a red herring, and what CMake really needs is the best possible website to document, tutorialize, and market CMake. In other words, what we've got is fine; go sell it. I have the feelling that I'd like to get into *this* discussion (not that SCon's related one), but I'm a newcomer much too late to the party, so: what's the whole Lua thing in a nutshell? Nutshell: is it strategically a good idea to implement Lua support for CMake? OK, time to see what Lua is... In my opinion: Pros: - higher quality 3rd party documentation that the CMake community needn't maintain. - CMake gets a popularity boost from Lua, as it's a mainstream accepted language. - Lua's corner cases are more ironed out than CMake script. 3rd party continues to iron them out. - proof of concept has already been demonstrated and was relatively easy to implement These are pros of adopting any other scripting language, not just Lua (which I don't know just yet). I would think CMake's businness should be build systems (low or high level), not programming languages, so there is an appeal in getting rid of this responsability. OTOH, if CMake does provide one of its own, it should be IMHO of a much higher quality because as it is now, it shadows the rest of CMake (which is so great and that's a pity). Cons: - although doable, it's extra work to support 2 languages - without a comprehensive migration strategy, it would split the CMake community - CMake script must be maintained indefinitely for a small percentage of users no matter what the migration strategy I suppose automated translation has been considered right? - too much programmability may cause people to treat CMake as more of a library or build component, rather than a standard end user tool People always find the way to shoot themselves in the foot. I say don't worry about that and trust the programmer. Undecided: - Do advanced programming constructs really matter? OO? A fool's game / fad / waste of time? Or is it a killer feature that will make or break products in the future? My problem with the CMake scripting language is not that is less advanced than others. I could live with that. My problems with it are these: 1.It's not case sensitive. 2.Closing statements need and empty () [at least they don't need to duplicate the expressions any more]. 3.There is just a string type which can actually be a list pseudo-type. At the very least it should have a real list type, a bool type and an integer type. 4.Because of 3 there are no boolean expressions, instead, a long fixed list of values evaluating to false. 5.There are no nullable types. 6.Becasue of 5 there is the need for the hacky string value *NOTFOUND 7.It has no functions (implemented in the script itself I meant) [macros are not the same] 8.There are cached and non-cached variables but their distinction is not sufficiently clear nor properly formalized. 9.SET (assignment) works differently for cache and non-cached variables. 10.internal function do not return values, cluterring the interface with return parameters which are not even modified as in other languages (via out, var, etc). 11.It has no data-structure support (except for the ugly pseudo-list hack, and I'm not even talking about OO here) 12.It has no scope. 13.Some conditionals don't take expressions but variables, while others do take expressions based on operators (EXISTS, EQUAL, etc) 14.There is no distinction between multiple arguments and a single argument being a list. This is a real problem for the many functions that accept a mix of both. 15.Because of 14 there are is the need for named parameters (which are great in themselves), but these are implemented poorly, as mere additional arguments/list items, so a typo in a parameter name breaks the naming and mismatches the argument list. 16.Least but not least: the language is extensible but not in the user side. That is, I cannot *plugin* (entirely at the user side) my own internal functions even though the underlying system is quite extensible. If it has something to do with the CMake scripting language, well, I for one would love to drop it and use something else, like (don't get me started on the wrong tail) The archives contain abundant ink on this subject. Well, bytes, whatever. I'm reading Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: VMWare on SCons' future
Hi Brandon, I am starting to wonder if the whole Lua thing is indeed a red herring, and what CMake really needs is the best possible website to document, tutorialize, and market CMake. In other words, what we've got is fine; go sell it. I have the feelling that I'd like to get into *this* discussion (not that SCon's related one), but I'm a newcomer much too late to the party, so: what's the whole Lua thing in a nutshell? If it has something to do with the CMake scripting language, well, I for one would love to drop it and use something else, like (don't get me started on the wrong tail) Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE_INSTALL_PREFIX and DESTDIR
Hi people,
In 2.4.5
make install DESTDIR=/path/to/dir
puts files in /path/to/dir/usr/local
that's because the actual destination is
$ENV{DESTDIR}/${CMAKE_INSTALL_PREFIX}
Is this the expected behaviour? or is it a bug in 2.4.5?
If this is expected, what is the best way to allow users to have DESTDIR
*override* CMAKE_INSTALL_PREFIX? (which IMO is the right thing to do)
Here's what I'm doing now, which seems to work, but is too hacky for my
taste:
(the string length business is there just because if ( $ENV(DESTDIR) )
doesn't work as I expected)
string( LENGTH $ENV{DESTDIR} DESTDIRLEN )
if ( ${DESTDIRLEN} GREATER 0 )
message( STATUS DESTDIR specified ($ENV{DESTDIR}). Overriding
CMAKE_INSTALL_PREFIX (${CMAKE_INSTALL_PREFIX}) )
set( CMAKE_INSTALL_PREFIX CACHE PATH Use DESTDIR *instead* of
CMAKE_INSTALL_PREFIX FORCE )
endif()
TIA
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] IF( ${VAR} ) behaviour
Hi people,
Consider the following (tested in 2.4.7):
set ( VAR whatever )
message( STATUS VAR=${VAR} )
if ( ${VAR} )
message( STATUS VAR evaluates to true )
else ( ${VAR} )
message( STATUS VAR evaluates to false )
endif( ${VAR} )
it prints VAR evaluates to false.
Is that expected?? The documentation of IF() doesn't match this behaviour
AFAICS.
TIA
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Re: IF( ${VAR} ) behaviour
Sylvain Benner wrote:
Now, why didn't
if ( $ENV{SOME_ENV_VAR} )
work?
Because $ENV{SOME_ENV_VAR} has the same behavior as ${SOME_ENV_VAR}, it
evaluates a variable. The only difference is that ${} is a CMake
variable and $ENV{} is an operating system environment variable.
OK, now I think about it, this expected.
I assume that IF statement only scan for CMake variables so you must do
like you did: turn the environment variable into a CMake variable to
make the conditional statement work.
I just realized that I haven't really understood IF until now: it doesn't
take a value as argument (like the IF of any other language I ever came
across), but a variable.
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMAKE_INSTALL_PREFIX and DESTDIR
Fernando Cacciola wrote:
string( LENGTH $ENV{DESTDIR} DESTDIRLEN )
if ( ${DESTDIRLEN} GREATER 0 )
message( STATUS DESTDIR specified ($ENV{DESTDIR}). Overriding
CMAKE_INSTALL_PREFIX (${CMAKE_INSTALL_PREFIX}) )
set( CMAKE_INSTALL_PREFIX CACHE PATH Use DESTDIR *instead* of
CMAKE_INSTALL_PREFIX FORCE )
endif()
In fact, that only works if the script needs to be processed again, which is
seldom the case of make install.
So in practice this doesn't work.
Any ideas?
Is there a way to tell whether CMAKE_INSTALL_PREFIX has its default magic
value or has it been defined by the user?
If so I could reset the deault to nothing, which makes more sense IMO.
I would like not to have my users remember to manually
add -DCMAKE_INSTALL_PREFIX= at configuration time to use DESTDIR later on.
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: IF( ${VAR} ) behaviour
Sylvain Benner wrote:
Hi,
You should use IF(VAR) instead.
!! Of course !!
I got confused because what I really tried at first, but didn't work, was
this:
if ( $ENV{SOME_ENV_VAR} )
so I figured I needed to load the enviroment variable into a cmake
variable first, for which I added:
set ( SOME_ENV_VAR $ENV{SOME_ENV_VAR} )
but then I changed the IF() and forgot the strip out the ${} and got totally
mindblocked...
Now, why didn't
if ( $ENV{SOME_ENV_VAR} )
work?
Yes, the variable is defined as I can see when I (correctly) test it's cmake
counterpart.
TIA
Fernando
In your example you made the test : IF(whatever)
whatever variable does not exist so the evaluation is false.
--Sylvain
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMAKE_INSTALL_PREFIX and DESTDIR
Hi Mike, I don't understand. If the user wants to have a destination other than the default provided by CMake, why don't they just run ccmake/ cmakesetup and set the CMAKE_INSTALL_PREFIX to what they want? CMake generated project files/makefiles can only be used on the system they were generated on so I am confused about your use case. Could you please explain in some more detail your use case for this and I bet we can find a solution for you. Never mind... I expected DESTDIR to be used to *completely define* the folder where the libray is intalled, overriding the system-dependent default location decided at configuration time, but I just realise that this not the way DESTDIR works (with or without cmake). So I just need to document that if a user want to use DESTDIR in that way (for example to install the library in multiple places), he must reset CMAKE_INSTALL_PREFIX accordingly. I also just realized now that one can reset that variable in the cache and type make install right away without reconfiguring by hand since make [install] processes the cmake script, it's not just a static makefile. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: FindXXX, XXXConfig and UseXXX
Brandon Van Every wrote:
On Feb 18, 2008 3:34 PM, Fernando Cacciola
[EMAIL PROTECTED] wrote:
XXXConfig.cmake should ...
FindXXX.cmake shoud ...
UseXXX.cmake should set include directories, libraries, compiler and
linker
flags, etc, based on the settings defined in a XXXConfig.cmake that must
has
been processed already.
I've yet to use any of the current UseXXX modules. I looked at the
source for one of them. All they're doing aside from the usual
FindXXX stuff is defining some macros, which you can choose to call or
not call. I don't see a point in breaking all this functionality up
into 3 different include files. 1 is fine; you choose to call
whatever macros you want to call.
Ha, but the UseXXX I was thinking about does the:
include_directories( ${XXX_INCLUDE_DIRS} ${XXX_THIRD_PARTY_INCLUDE_DIRS} )
add_definitions( ${XXX_DEFINITIONS} ${XXX_THIRD_PARTY_DEFINITIONS} )
etc...
XXX users would load XXX in their own programs via:
find_package(XXX)
if ( XXX_FOUND )
include( ${XXX_USE_FILE} )
endif()
What's wrong with:
include(findXXX)
That a users needs to point to findXXX (and there could be various versions
of XXX installed on the system)
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] XXX_DIR
Hi people, According to my experiments in 2.4.7, XXX_DIR seems rather special. Consider a CMakeLists.txt containing just find_package(XYZ) Run cmake . You'll see the error: CMake Error: XYZ_DIR is not set. It must be set to the directory containing XYZConfig.cmake in order to use XYZ. Define the enviroment variable to the folder containing the CMakeLists.txt file, for intance: export XYZ_DIR=. Run cmake . again. You'll see the same error. You could think that this is because XYZ_DIR is defined as a enviroment variable instead of a cmake variable. Let's see. Add an empty file named XYZConfig.cmake in the folder pointed to by XYZ_DIR. Run cmake. again Now you'll see that it works! Which means that cmake used the enviroment variable XYZ_DIR. Change XYZ_DIR to point somwehre else. Delete CMakeCache.txt Run cmake . again. Now you'll see the same XYZ_DIR is not set error as before, which suggests that the enviroment variable is recognized only if it points to XYZConfig.cmake Delete CMakeCache.txt again Run cmake -DZYZ_DIR=wrong_folder . You'll see the error: CMake Error: XYZ_DIR is set to wrong_folder, which is not a directory containing XYZConfig.cmake Which shows that if XYZ_DIR is passed as a cmake is it consistently used (unlike the case of an enviroment variable which seems to be used only if it points to the right folder) Furthermore, if you look at the cache at each step above, you'll see that when XYZ_DIR is passed as a cmake variable is not stored in the cache, while when it is passed as an enviroment variable it is (either with a XYZ_DIR-NOITFOUND value or the correct folder value) Can you clarify the details of this variable? Is it true that it can be a enviroment variable but it must point to the right folder? Is it true that if it is a an enviroment variable it is stored in the cache, but not if set in the command line? Can it be stored in the cache if passed in the command line? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: XXX_DIR
Hi Alexander, On Tuesday 19 February 2008, Fernando Cacciola wrote: Hi people, According to my experiments in 2.4.7, XXX_DIR seems rather special. Consider a CMakeLists.txt containing just find_package(XYZ) Run cmake . You'll see the error: CMake Error: XYZ_DIR is not set. It must be set to the directory containing XYZConfig.cmake in order to use XYZ. Usually you shouldn't need to set it. Usually maybe.. in the case of my users, they will have to set it to point to the XXXConfig.cmake of my library in order to use it. What do you want to do Understand the way XXX_DIR works. My post shows just that by experimentation, but I wanted to confirm the results. what doesn't work ? The documentation. It should better explain the details of this magic variable (magic in the sense that cmake itself uses it). Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindXXX, XXXConfig and UseXXX
Hi,
Consider a library XXX that uses cmake as it's build system. Here's what I
think those three files should do:
XXXConfig.cmake should be generated by the cmake script that configures the
library and it should contain the settings specific to that configuration
(such as source and binary folders, detected third party dependencies,
needed flags, etc)
FindXXX.cmake should search a user's system for an instance of
XXXConfig.cmake (using XXX_DIR and defaults paths). If it finds it, it
should load that XXXConfig.cmake.
UseXXX.cmake should set include directories, libraries, compiler and linker
flags, etc, based on the settings defined in a XXXConfig.cmake that must has
been processed already.
XXXConfig.cmake should define a XXX_USE_FILE with the full path to the
UseXXX.cmake file.
XXX users would load XXX in their own programs via:
find_package(XXX)
if ( XXX_FOUND )
include( ${XXX_USE_FILE} )
endif()
If FindXXX.cmake is found in the paths specified by CMAKE_MODULE_PATH, it is
loaded by find_package(XXX).
If not, but the user sets XXX_DIR to some binary folder for some
installation of XXX, the above code works still by loading XXXConfig.cmake
directly (witout going through FindXXX..cmake)
Is all that correct?
Is so, how should FindXXX and UseXXX distributed?
Ideally they should go to the standard modules folder of cmake since this
way users don't have to point CMAKE_MODULE_PATH correctly, but do I do that?
Having the configuration script copy them doesn't work in Vista because of
the access restrictions to ProgramFiles.
Putting them in the binary folder works, but doesn't seem right (only
XXXConfig.cmake should go there).
Any other ideas?
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Custom cache
Hi people, As you know (or should know) it is sometimes needed to delete the cache, specially if the system changes and libraries are added, deleted or upgraded. However, some settings are too valuable and its annoying to loose them just because the cache had to be deleted, so I wonder, are there any tools to a handle a second custom cache? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Re: FindQt4 in 2.4.8 bug
Hi Bill,
Can you add a :
Better let me start over, I think I know what's going on now.
Maybe is the intended behaviour. If it is, I think is quite odd.
Consider the following simple script:
set ( var whatever CACHE PATH )
message ( STATUS ${var} )
I would expect to see whatever as the value of var since it is being
explicitely set, but that's not neccesarily what happens: if the cache
*already* contains a value for var, say xyz, then that value sticks and
var is just never set to whatever unless FORCE is added (as I found out
and reported eariler in this thread)
Is this the expected behaviour?
If it is, then it leads to a problem when SET is used for example like this:
set ( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH )
because if at some earlier run qt4 was actually not found, QT_INCLUDE_DIR
gets set to NOTFOUND and once there it is never reset to the include path
even if qt4 is properly found later. The only way out this tirany is to
delete the cache and star over.
IMO the rule that says do not override exisitng cache values unless FORCE
is specified should be relaxed to have null values be always overwritten.
Or at the very least there should be a FORCE_IF_NULL option, because it
makes no sense at all to keep a NOTFOUND value for an INCLUDE_DIR when the
right path is available.
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Re: Re: FindQt4 in 2.4.8 bug
Hi Bill, behaviour. Don't break that as you can always use if (NOT DEFINED VAR) set (VAR foo CACHE .. FORCE) But: find_library(FOO_VAR foo) This will set FOO_VAR (in the cache) if it is not set or if the value has -NOTFOUND in it. I just tried it and find_path (didn't try find_library but find_path) will not set it if the cache has -NOTFOUND in it. Please try yourself because I think this one is unexpected, and undocumented. But let's say I did the test wrong (hopefully) and it is as you said. Even then this is much more important IMO: set(FOO_VAR somevalue) and set(FOO_VAR somevalue CACHE TYPE ) are inconsistent. That's much harder to understand. Also, the SET documention only mentions the critically important fact that cached values are not overwritten by default when the FORCE option is explained. IMO this is the wrong way to document such an odd behaviour for a command named SET (I don't think I ever seen a language with such a behaviour, and I've been in this business for a long long time). At the very least that fact should be stated up front. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Re: Re: FindQt4 in 2.4.8 bug
Hi Hendrik, So you want to give NOTFOUND an even more special status than all the other negative variable values? Don't get me started on the existence of all these negative values, or on the fact that there is just a string type, or the fact that not even that is actually true as there is a list pseudo-type coerced in a string, or... OK, I'll stop here. NOTFOUND could very well have an even more special status, or meaning to be precise, than all the other negative values, because it says exactly what it means, so it makes perfect sense not to keep this value if another one is available. It's not at all like overwritting FALSE with TRUE, OFF with ON, etc. , This is not even close to being backwards-compatible. Letting bugs pertuate is not keeping backwards-compatibility. Why do you want the existing behavoir? When *exactly* do you want to keep the NOTFOUND and *why* Keep in mind that as I said is not like reseting FALSE, OFF, etc Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Re: Re: Re: FindQt4 in 2.4.8 bug
Bill Hoffman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola wrote: *you* as in *me* in any *new* script? Sure I can, but I found this problem in FindQt4, a standard cmake module. The -NOTFOUND value can never end up in that variable with the current FindQt4.cmake. Or if I don't had QT4 installed when I run cmake. Here is quite possible scenario: User downloads my library and starts configuring it (runs cmake). He then realises that it needs Qt4 becasue of the Qt4 not found message, so he goes on to install it. Then he runs cmake again on my library. But what happens is that Qt4 not found keeps appearing, so he spend half the rest of his life figuring out why, as it is installed and correctly and all. Eventually he reads the part of my library's INSTALL that says that he should delete CMakeCache.txt if installed libraries are not found when they should. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindQt4 in 2.4.8 bug
Hi,
I've been using 2.4.7 until this morning when I saw the 2.4.8 announcement
and jumped right away to install it (silly me).
I have some script that finds Qt4 but stopped working on 2.4.8.
Tracing the problem in FindQt4.cmake I found this...
There is one (at least one) SET command like this:
SET( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH )
which fails to actually set the value of QT_INCLUDE_DIR
It works fine if DOCSTRING is prepended in front of :
SET( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH DOCSTRING )
Is this a bug in FindQt4.cmake? ( was this differently in 2.4.7? )
A bug in 2.4.8 ( DOCSTRING should not be needed? )
A feature in 2.4.8 ? (is needed just now? )
TIA
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: FindQt4 in 2.4.8 bug
[EMAIL PROTECTED] wrote:
On Friday 25 January 2008 10:58:19 am Fernando Cacciola wrote:
Hi,
I've been using 2.4.7 until this morning when I saw the 2.4.8
announcement
and jumped right away to install it (silly me).
I have some script that finds Qt4 but stopped working on 2.4.8.
Tracing the problem in FindQt4.cmake I found this...
There is one (at least one) SET command like this:
SET( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH )
which fails to actually set the value of QT_INCLUDE_DIR
It works fine if DOCSTRING is prepended in front of :
SET( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH DOCSTRING )
Is this a bug in FindQt4.cmake? ( was this differently in 2.4.7? )
A bug in 2.4.8 ( DOCSTRING should not be needed? )
A feature in 2.4.8 ? (is needed just now? )
Or perhaps ${qt4_include_dir} is empty
No, is not.
It contains the correctm path.
As I said, if I append the DOCSTRING, QT_INCLUDE_DIR is also set to the
correct values.
I know because I printed the values of all the involved variables (from the
file beginning actually, otherwise I would have never located the problem
exactly there)
I ommitted the details on how I concuded this because I wasted enough time
finding the problem, now I can't waste even more time showing that I did not
make any silly mistake like that.
, so it messes up the rest of the
arguments.
This is on a Mac, right?
No, is Vista.
And is Qt configured with -no-framework?
Did it set QT_QTCORE_INCLUDE_DIR
Yes
and QT_LIBRARY_DIR correctly?
Don't know and I don't care since this is defined after that.
Fernandi
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: FindQt4 in 2.4.8 bug
Fernando Cacciola wrote:
Hi,
I've been using 2.4.7 until this morning when I saw the 2.4.8 announcement
and jumped right away to install it (silly me).
I have some script that finds Qt4 but stopped working on 2.4.8.
Tracing the problem in FindQt4.cmake I found this...
There is one (at least one) SET command like this:
SET( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH )
which fails to actually set the value of QT_INCLUDE_DIR
It works fine if DOCSTRING is prepended in front of :
SET( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH DOCSTRING )
I just realized that the trailing in the original is the DOCSTRING
already.
My version works because the presence of my own trailing causes the set
command not to parse CACHE correctly, so it just adds CACHE, PATH and
DOCSTRING to the variable (whith the value of qt4_include_dir as the first
element on the list)
Since that showned that this behaviour is related to caching the just
assigned value in the cache, I tried simply adding FORCE at the end, and it
worked.
Removing the cache still doesn't help unless I add FORCE, so is not an issue
caused by a previous value.
Running the script a second time (so the cache contains
QT_INCLUDE_DIR-NOT_FOUND) still doesn't change anything.
Any ideas?
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problem with find_path
Here is a extract of FindQt4 from 2.4.7 (NOT 2.4.8, which is different
somewhat)
message( STATUS QT_INCLUDE_DIR=${QT_INCLUDE_DIR} )
message( STATUS QT_LIBRARY_DIR=${QT_LIBRARY_DIR} )
FIND_PATH(QT_QTOPENGL_INCLUDE_DIR QtOpenGL
PATHS
${QT_INCLUDE_DIR}/QtOpenGL
${QT_LIBRARY_DIR}/QtOpenGL.framework/Headers
NO_DEFAULT_PATH
)
message( STATUS QT_QTOPENGL_INCLUDE_DIR=${QT_QTOPENGL_INCLUDE_DIR} )
In my Vista machine, it prints:
-- QT_INCLUDE_DIR=C:/Work/General/qt-win-opensource-src-4.3.3/include
-- QT_LIBRARY_DIR=C:/Work/General/qt-win-opensource-src-4.3.3/lib
--
QT_QTOPENGL_INCLUDE_DIR=C:/Work/General/qt-win-opensource-src-4.3.3/include
But that wrong.
QtOpenGL is a folder which happens to contain a file named also QtOpenGL.
The find_path command is actually searching for the file, not the folder (so
it appends the folder in the search path).
Yet as you can see, it is the folder what is found, not the file, and as a
consequence the resulting path is one level wrong.
Is this a bug in find_path (in 2.4.7)?
TIA
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: MSVC turn off RelWithDebInfo and MinSizeRel
David Cole wrote: How about this in the CMakeLists.txt file instead? (Force it into the cache rather than using a simple set.) SET(CMAKE_CONFIGURATION_TYPES Debug;Release CACHE STRING limited configs FORCE) The generator rejects it. -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Getting configuration information
Hi, I need to assemble the name of the output library based on certain parameters mostly dependent on the build type (configuration): * has debug information * has diagnostics (trace, etc) * optimize for size/speed * is multihreading supported * the RTL to use is statis or dynamic .. and possibly others What the best way to extract that for the current generator (other than hard coding it)? P.S: Yes, this is directly related to boost-style autolinking in case you wonder (but for a different project which just borrows that from boost) TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Re: MSVC turn off RelWithDebInfo and MinSizeRel
David Cole wrote: What do you mean? Do you get an error message? If so, send along the text of the error... OK I didn't post the error becasue I could reproduce it... I just remember seeing it. But now I got what happens, let me explain: Say you have: SET(CMAKE_CONFIGURATION_TYPES WrongOne CACHE INTERNAL bla bla FORCE) when you run it you get: CMake Error: Invalid configuration type in CMAKE_CONFIGURATION_TYPES: WrongOne (Valid types are Debug,Release,MinSizeRel,RelWithDebInfo) so you change it to: SET(CMAKE_CONFIGURATION_TYPES WrongOne CACHE INTERNAL bla bla FORCE) when you run it again, you get the same error (the generator still gets the old cached value instead of the new one) you need to run it again to get it right. -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] single source cross-compilation
Is it possible to support different compilers and options from the same source tree? If so, how? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: single source cross-compilation
Alexander Neundorf wrote: On Wednesday 19 December 2007, Alberto Luaces wrote: El Wednesday 19 December 2007 15:36:49 Fernando Cacciola escribió: Is it possible to support different compilers and options from the same source tree? If so, how? This behaviour is present by default, I think: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees Yes, you can build one source tree multiple times out-of-source, but in each build tree you can only use one toolchain (or you hack around it, which brings problems). Right, what I meant to ask was precisely that.. if there was some additional support beyond out of source builds. Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Controling OutputDirectory in the vcprojs
Hi Again, FWIW here's how I managed to have mangled names in the output *and* in the right folder instead of $(OutDir). project(FOO) add_library(FOO foo.cpp) set_target_properties( FOO PROPERTIES DEBUG_OUTPUT_NAME foo-debug RELEASE_OUTPUT_NAME foo-release) add_custom_command(TARGET FOO POST_BUILD COMMAND copy $(TargetPath) $(ProjectDir) ) Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Controling OutputDirectory in the vcprojs
Hi, I'm porting (or trying to) a custom build system to CMake. Following Boost we generate .libs whose names reflect configurarion properties. To keep it simple, say we generate foo_release.lib and foo_debug-lib. I was able to get those names right by setting the CONFIG-OUTPUT-NAME target properties, but I still have a problem: I don't want them in Release and Debug folders (there is no need for that since the configuration is in the name). Looking at cmLocalVisualStudio7Generator.cxx it seems I'm plain out of luck since OutputDirectory is forcibly defined as the configuration name, so 1) Can the VisualStudio generator be fixed to define that as LIBRARY_OUTPUT_DIRECTORY if defined? 2) What can I do now? Can I plug in a post build event to copy the generated .lib to the right folder? Or do I need to handle it as an install rule? (and force my users to do make install in the end even for in-source builds) TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Mangled library names
What's the best way to produce mangled library names (encoding in the target name some configuration properties)? Examples of mangled library names are here, in Boost: http://www.boost.org/more/getting_started/windows.html#library-naming TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Multiple configurations in a single target?
Hi A single VS .vcproj file can have both debug and release configurations. How can I produce that sort of project file with CMake? Would calling CMake twice, setting CMAKE_BUILD_TYPE differently each time, do the magic? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Multiple configurations in a single target?
Sylvain Benner wrote: Hi A single VS .vcproj file can have both debug and release configurations. How can I produce that sort of project file with CMake? Would calling CMake twice, setting CMAKE_BUILD_TYPE differently each time, do the magic? Hi, I don't understand your question, by default CMake generates .vcproj files with the following configurations: Debug;Release;MinSizeRel;RelWithDebInfo So you don't have to do anything to get them into your Visual Studio project. Ha OK, I missed that because I read here that CMAKE_BUILD_TYPE had to be set by the user, so I just assumed it would produce only one configuration depending on that. Well, the real question now then: to have each configuration has its own properties, like target name, definitions and dependecies, I just need to switch on CMAKE_BUILD_TYPE? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Re: Re: Re: Hyperlinked indexed reference?
Bill Hoffman wrote: Ken just checked in his changes, so if you create a patch, use CVS CMake. Cool. Is there a dev-list (here?) or at least someone I can forward the diff to look at before I commit? I don't think you can commit. Just create a patch and send it to me. OK. Best Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Re: Re: Re: Hyperlinked indexed reference?
Hi Bill,
Just create a patch and send it to me.
OK.
Here's a patch for cmDocumentationFormatterHTML.cxx
It adds, at the beginning of each section, a list with hyperlinks to each
entry in it.
Unfortunately, adding a similar list to the whole document is more difficult
given the current documentation arquitecture, so it will take me some more
(free) time to di it, but this is a good start.
At least within each section you can easily see all entries
(options,commands,properties,modules) at once, and jump directly to the one
you are interested in.
--- cmDocumentationFormatterHTML - Copy.cxx 2007-10-22
13:48:39.0 -0300
+++ cmDocumentationFormatterHTML.cxx 2007-10-22 19:33:45.79400 -0300
@@ -97,6 +97,20 @@
const std::vectorcmDocumentationEntry entries =
section.GetEntries();
+
+ os ul\n;
+ for(std::vectorcmDocumentationEntry::const_iterator op =
entries.begin();
+ op != entries.end(); ++ op )
+{
+if(op-Name.size())
+ {
+ os lia href=\#command_ op-Name.c_str()
\bcode;
+ this-PrintHTMLEscapes(os, op-Name.c_str());
+ os /code/b/a/li;
+ }
+}
+ os /ul\n ;
+
for(std::vectorcmDocumentationEntry::const_iterator op =
entries.begin();
op != entries.end();)
{
@@ -108,9 +122,9 @@
osli\n;
if(op-Name.size())
{
- os bcode;
+ os a name=\command_ op-Name.c_str()
\bcode;
this-PrintHTMLEscapes(os, op-Name.c_str());
- os /code/b: ;
+ os /code/b/a: ;
}
this-PrintHTMLEscapes(os, op-Brief.c_str());
if(op-Full.size())
I compiled and tested it locally and it works AFAICT.
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Hyperlinked indexed reference?
Is there any hyperlinked (and preferably indexed) command reference? TIA Fernando Cacciola ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
