Re: [CMake] How to disable cmake_clean_target.cmake script from executing.
Le Mon, 10 Nov 2008 16:22:48 +0900,
이명현 [EMAIL PROTECTED] a écrit :
Hi,
I am working in a system where a static library(archive) is build with
source files that are distributed among several directories.
CMakeLists.txt
src /
CMakeLists.txt
*.cpp files
src1/
CMakeLists.txt
*.cpp files
src2/
CMakeLists.txt
*.cpp files
In this setting, I wish to build a static library by recursively
building through the source directories.
I think you should recurse in order to find files
but not for building lib.
However, by doing so, each time a library is built for a directory,
it will destroy the previous build of the library( built from another
directory) and add the objects from the current directory to the
static library. I have found that this is being done by calling
You may try to create your static lib from the top-level CMakeLists.txt
FILE(GLOB_RECURSE SOURCE_FILE_LIST *.cpp)
FILE(GLOB_RECURSE HEADER_FILE_LIST *.h)
ADD_LIBRARY(whatever STATIC ${SOURCE_FILE_LIST} ${HEADER_FILE_LIST})
cmake -P cmake_clean_target.cmake
If someway I could be able to block that script from executing I will
have a static library with all the sources merged into one file.
I won't do that, that way.
--
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] my FindDevIL.cmake module
Miguel A. Figueroa-Villanueva wrote: Thanks for the valuable input. I've slimmed down my file a bit and used the find_package_handle_standard_arg macro. It's attached to this message. Again feel free to include it in cmake or give more input on it. (or not, it's working for me now anyway) If you don't want this to get lost you should make an entry in the Mantis bug tracker and attach the file there. No please do not do that If you want it to become part of CMake see here: http://www.vtk.org/Wiki/CMake:Module_Maintainers If you create a bug entry I will close it. Find someone to maintain it, or maintain it yourself, but do not create a bug entry for it. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Jed Brown wrote: My point about CC and friends is that there are often standard environment variables for setting this stuff. I think it should be possible to select the version of packages with one variable. For Qt4, this is the qmake executable, for PETSc, it is (by convention) PETSC_DIR and PETSC_ARCH. With most packages, if the wrong version is found by default, the user is required to edit all the advanced cache entries or to delete the cache manually and try again with the correct variable set. ... So, each find module should have a consistently named variable that can control the prefix for finding the module. For example, FindFoo.cmake, would have FOO_DIR. If that environment variable is set and CMake can not find it, it is an error and nothing else is searched. This is how CC,CXX, and FC work. Once it is found the environment variable is no longer looked at. However, if the cmake cache variable of the same name is ever changed then all variables for the module are reset. There is some code inside CMake that does library path searching. It might make sense to have a command that parses link lines and finds the libraries. I am thinking a new command might be a good idea. I agree, it's really painful to do this in a robust way in CMake. The command needs significant semantics (like understanding nested shell quoting) to handle pathological inputs (which mine doesn't). For instance, if the library makefile system sets FOO_CFLAGS = -I/path/to/foo/include -DBAD='Some -Ipathological string' it would be nice to parse this correctly. I know this looks like over-engineering, but logic to parse this correctly must exist somewhere in CMake already. We can try, but shell escaping is going to hard. I am not sure it comes up that much. When pkg-config is run or a makefile fragment is run it should already expand the shell quoting. I don't think CMake has any business being a shell. ... So, what does BuildSystem do to handle this? Is there anything that can be learned? It's not elegant. It always assumes that the entire dependency graph needs to be linked (as with static libraries). The analogue of Find* modules recognize this and behave accordingly. Component Foo can always be selected using --with-foo-dir=/path/to/foo ... This is basically covered by having a FOO_DIR variable for each FindFoo.cmake module. rely on a stale cache entry. I sometimes find myself repeatedly running this $ rm -r * cmake .. -DFOO_VAR=blah to guarantee that the cache is not stale and all necessary tests are actually run. I don't think we will be getting rid of the cache. However, having dependent variables that when changed cause re-running of tests and find_* stuff is a good idea. be found there (maybe I should have spelled it -DFOO_DIR=/path/to/foo-1.2) then the module should not silently fall back on /usr/lib/libfoo.so. Any ideas on how to make these semantics accessible to module writers without a lot of custom effort? I would think that some standard functions in something like FindPackageHandleStandardArgs.cmake should help. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] my FindDevIL.cmake module
2008/11/10 Miguel A. Figueroa-Villanueva [EMAIL PROTECTED]: Thanks for the valuable input. I've slimmed down my file a bit and used the find_package_handle_standard_arg macro. It's attached to this message. Again feel free to include it in cmake or give more input on it. (or not, it's working for me now anyway) If you don't want this to get lost you should make an entry in the Mantis bug tracker and attach the file there. Nope as far as I understand it well, new CMake module submission should be done ON THE Mailing list with - [New Module] Find.cmake in the subject line - the FindXXX.cmake attached to the mail - a clear message telling who is wanting to maintain the module The volunteer maintainer will be contacted if its module seems to pleased the community and follows CMake modules writing rules. Bug Tracker items for new module submission seems to be systematically closed. This is described here: http://www.vtk.org/Wiki/CMake:Module_Maintainers but it is not explicitely stated that Bug Tracker submission should be avoided. May be Bill may confirm this? I'll update the Wiki page if Bug Tracker submission for new Module should be banned. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
On Mon 2008-11-10 08:23, Bill Hoffman wrote: So, each find module should have a consistently named variable that can control the prefix for finding the module. For example, FindFoo.cmake, would have FOO_DIR. If that environment variable is set and CMake can not find it, it is an error and nothing else is searched. This is how CC,CXX, and FC work. Once it is found the environment variable is no longer looked at. However, if the cmake cache variable of the same name is ever changed then all variables for the module are reset. I think that is ideal behavior for Find* modules. ... I don't think we will be getting rid of the cache. However, having dependent variables that when changed cause re-running of tests and find_* stuff is a good idea. I certainly think the cache is a good thing, it's just unpredictable without dependent variables. Thanks Bill. I'm very encouraged by the response this thread has generated and optimistic that the Find* modules will become more robust without undue effort by module writers. Jed pgpSCuchIo3eU.pgp Description: PGP signature ___ 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
Re: [CMake] What does `cross-platform' mean?
Thanks Michael, it's good to hear I'm not alone :-)
On Sun 2008-11-09 20:16, Michael Jackson wrote:
So basically if you don't have the HDF5_INSTALL env variable set then my
module probably will not find it, which is good in that instead of
getting a wrong version of HDF5 you just don't get any at all.
I also use NO_DEFAULT_PATH in my modules to help prevent an inconsistent
configuration. I think the optimal semantic is usually that if
HDF5_INSTALL is not set, it tries default paths, but if HDF5_INSTALL is
set, even if incorrectly, it will never fall back on default paths.
Something like this, all guarded by clearing all advanced HDF5_* entries
if HDF5_INSTALL is changed so the user can change versions without
manually deleting the cache.
IF(HDF5_INSTALL)
# Look for the library only under the specified directory
FIND_LIBRARY(HDF5_LIBRARY_DEBUG
NAMES ${HDF5_SEARCH_DEBUG_NAMES}
HINTS ${HDF5_INSTALL}
PATH_SUFFIXES lib64 lib
NO_DEFAULT_PATH
)
ELSE(HDF5_INSTALL)
# Look for the library in default paths
FIND_LIBRARY(HDF5_LIBRARY_DEBUG
NAMES ${HDF5_SEARCH_DEBUG_NAMES}
)
ENDIF(HDF5_INSTALL)
Maybe it could look something like
FIND_LIBRARY(HDF5_LIBRARY_DEBUG
NAMES ${HDF5_SEARCH_DEBUG_NAMES}
HINTS ${HDF5_INSTALL}
PATH_SUFFIXES lib64 lib
EXCLUSIVE_HINTS)
where the semantic (if EXCLUSIVE_HINTS is given) is that if the
arguments of HINTS is set (i.e. HDF5_INSTALL was set, either as an
environment variable or in the cache), then only directories under
HINTS/PATH_SUFFIXES are searched, otherwise (i.e. HDF5_INSTALL was not
set) the normal semantics of FIND_LIBRARY are used.
Jed
pgpljBr24oPBL.pgp
Description: PGP signature
___
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] file-glob question
Hi all, I'm trying to do the following: file(GLOB PLUGINS plugins/*) This returns all the absolute paths to the plugins. Which is fine. But, when I try: file(GLOB PLUGINS RELATIVE plugins/*) It gives me an error about file GLOB requires a glob expression after the directory Is this a bug in CMake? Or is it something I am interpreting wrong? Thanks, Steven ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Jed Brown wrote: Thanks Bill. I'm very encouraged by the response this thread has generated and optimistic that the Find* modules will become more robust without undue effort by module writers. Well, it is not going to happen over night, but I think we are closer to a plan. I am going to update the wiki with the main three ideas of this thread so it does not get lost. - Standard FOO_DIR for find modules, but environment and cache. Environment works like CC and CXX do. - Add ability to parse compile lines like the ones produced from pkg-config and turn them into full paths to libraries. - Add an easy way to create dependent cache variables, that when changed unset a number of other variables. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] my FindDevIL.cmake module
On Mon, Nov 10, 2008 at 8:51 AM, Bill Hoffman wrote: Miguel A. Figueroa-Villanueva wrote: Thanks for the valuable input. I've slimmed down my file a bit and used the find_package_handle_standard_arg macro. It's attached to this message. Again feel free to include it in cmake or give more input on it. (or not, it's working for me now anyway) If you don't want this to get lost you should make an entry in the Mantis bug tracker and attach the file there. No please do not do that If you want it to become part of CMake see here: http://www.vtk.org/Wiki/CMake:Module_Maintainers If you create a bug entry I will close it. Find someone to maintain it, or maintain it yourself, but do not create a bug entry for it. Noted. Sorry for the confusion; I wasn't aware of this policy. --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries vs target_link_libraries
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.
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.
For the case of a single library with a few headers, for which a UseXXX
file is provided the requirement really doesn't make much sense (IMHO) -
unless you can use some of the headers without linking.
Andreas
--
Don't read any sky-writing for the next two weeks.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
On Mon, Nov 10, 2008 at 10:09 AM, Bill Hoffman wrote: Jed Brown wrote: Thanks Bill. I'm very encouraged by the response this thread has generated and optimistic that the Find* modules will become more robust without undue effort by module writers. Well, it is not going to happen over night, but I think we are closer to a plan. I am going to update the wiki with the main three ideas of this thread so it does not get lost. - Standard FOO_DIR for find modules, but environment and cache. Environment works like CC and CXX do. - Add ability to parse compile lines like the ones produced from pkg-config and turn them into full paths to libraries. - Add an easy way to create dependent cache variables, that when changed unset a number of other variables. A while back I had opened a feature request on the third item: http://public.kitware.com/Bug/view.php?id=7286 I think it is a fairly simple thing to implement if no speed issues are considered, which I don't think these would be a problem. That is, save the cache before the configure iteration and check if the entries listed in the dependencies list have changed. If so, reset the cache entry. --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Understanding try_compile
Hello, From what I understand try_compile creates a mini CMake project and compiles a source file. What variables of the current set of cmake variables are forward to the temporary project? What environment is used to execute the temporary project? Is it possible to set environment variables for the temporary project? regards Andreas Pokorny ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Jed, Just to tell you, that you are not alone with that kind of problem. I miss a solution to that abi problems too. I have also brought up this question every now and then, but without any usable solution yet. Sadly, I do not have the time to provide such a solution... ... well, and yes I contribute for some opensource projects during my day work ... For me this happens with about every multi abi unix I know of. HP-UX with its various 32 and 64 bit abis, the SGI's with three different abis installed, solaris with its 32 and 64 bit abi .. It all works as long as you compile for the default abi. Since the default abi's files usually reside in */lib CMake tests for the files you intent to use. But for any non default abi, cmake looks for libs in */lib but needs the ones in /*lib/pa20_64 which may be installed or not independent of the default abi variant in */lib. The basic problem is that almost all cmake macros tend to test sideeffects that in some special cases are related to what you need to test. But only for special cases. So testing for the existence of a .so in /usr/lib does in no way tell anything if you can link with that one... So, the good old autotools, if you like it or not, tend to test what is required for exactly that reason. And guess - this works way better than what cmake does. I need to cope with that for OpenSceneGraph in my example, May solution to that is use 'make -i' to just ignore those build failures originating from invalid cmake configure decisions. Not nice, but this is what I could do taking into account that a day has only 24 hours plus the night :) It would be a *huge* improovement to cmake and would in fact push it to the 'top one' cross platform build systems on this blue marble... anyway , thanks for developing and providing cmake ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Mathias Fröhlich wrote: The basic problem is that almost all cmake macros tend to test sideeffects that in some special cases are related to what you need to test. But only for special cases. So testing for the existence of a .so in /usr/lib does in no way tell anything if you can link with that one... So, the good old autotools, if you like it or not, tend to test what is required for exactly that reason. And guess - this works way better than what cmake does. Can you describe exactly what you think autotools does here? I guess most autotools tests use a try-compile to find a library. Is that what you are referring to? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] my FindDevIL.cmake module
On Fri, Nov 7, 2008 at 2:12 PM, Christopher Harvey wrote: Alexander Neundorf wrote: On Friday 07 November 2008, Christopher Harvey wrote: Hi list, I wrote this library finding module. If it's good enough for cmake please include it. If not let me know what's wrong with it so I can fix it up. It has only had limited testing under linux. Before it's added it would be nice to get some feedback about what has worked or what hasn't. Just some notes: You don't need to list all these search directories explicitely, most of them are searched by default. Have a look at Modules/Platform/UnixPaths.cmake. Also instead of having a version with and one without IL you can use the PATH_SUFFIXES option for FIND_PATH() In the end you can (should) use the find_package_handle_standard_args() macro which comes with cmake = 2.6.0 to have the standard argument handling. Alex Thanks for the valuable input. I've slimmed down my file a bit and used the find_package_handle_standard_arg macro. It's attached to this message. Again feel free to include it in cmake or give more input on it. (or not, it's working for me now anyway) If you don't want this to get lost you should make an entry in the Mantis bug tracker and attach the file there. Just my two cents, --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Hi, On Monday 10 November 2008 16:29, Bill Hoffman wrote: Can you describe exactly what you think autotools does here? I guess most autotools tests use a try-compile to find a library. Is that what you are referring to? Yep. If you want to link with a library you need to test if you can link with that library. If you test something different, you might then later be surprised, that linking does not work ... ... and yes this takes more time than just testing for existence. But it is way more correct ... Greetings and thanks Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making Nightly builds easier to setup
Eric Noulard wrote:
2008/11/9 Alexander Neundorf [EMAIL PROTECTED]:
[...]
commands can be executed.
IMO this can make setting up Nightly builds much easier.
Looks interesting, I didn't ever thought ctest scripting was done for that.
I did shell scripts for that and was wondering how to do it on Windows :-)
Now I know.
What do you think ?
One thing which is still missing is a way how to get variables predefined
into
the cmake-configure run during ctest_configure().
Does this have to be done by writing an initial CMakeCache.txt ?
This seems possible using CTEST_INITIAL_CACHE
as shown here:
http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
# this is the initial cache to use for the binary tree, be careful to escape
# any quotes inside of this string if you use it
SET (CTEST_INITIAL_CACHE
MAKECOMMAND:STRING=nmake -i
CMAKE_MAKE_PROGRAM:FILEPATH=nmake
CMAKE_GENERATOR:INTERNAL=NMake Makefiles
BUILDNAME:STRING=Win32-nmake71
SITE:STRING=VOGON.kitware
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
)
I recently played around with nightly builds as well. I used to have a
setup for experimental builds, but never could get the svn checkout to
run. With the approach described above, I was finally able
to run checkout from svn from within ctest. Unfortunately it seems that
some variables are not used anymore with this approach of generating builds.
I found that CTEST_INITIAL_CACHE as well as CTEST_ENVIRONMENT seem to be
ignored, when using CTEST_BUILD etc. For the environment variables I
could get it to work by setting
the environment variables explicitly, e.g. 'SET (ENV{CC} gcc-4.2)'.
That means that the approach proposed above does not work, at least not
for me.
After all I'm somewhat confused about this new approach ignoring some of
the variables. Maybe someone with a deeper knowledge of ctest could
explain, what's going on here.
Regards,
Martin
Virus checked by G DATA AntiVirus
Version: AVF 19.138 from 09.11.2008
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Addressing an external MS project as target
Hello, there is the following situation: I use CMake as build control system (Windows platform, MS Visual Studio) for my own project (A). A depends on a second project (B). The project-files of B are pre generated and not covered by my CMake-Scripts. I use INCLUDE_EXTERNAL_MSPROJECT to integrate B into my solution. Until this point everything works fine. But is there any way to address included external projects (like B) as a target in a CMake script. I would need this to add dependencies between A and B (e.g. ADD_DEPENDENCIES(A B)), so that B would also be build when I want to build A. In the documentation and the mailing list I have found no information how to do this. And it seems that INCLUDE_EXTERNAL_MSPROJECT has no possibilities to introduce a Target identifier (like ADD_CUSTOM_TARGET). I am thankful for any clues or tips that could help me to represent the project dependency in my CMake scripts. Kind regards, Ralf Floca -- Ralf Floca DKFZ German Cancer Research Center (Deutsches Krebsforschungszentrum) Member of the Helmholtz Association E071 Research Group Software Development for Integrated Diagnostics and Therapy (SIDT) Im Neuenheimer Feld 280 D-69120 Heidelberg Telefon: +49 (6221) 42 3021 E-Mail: [EMAIL PROTECTED] Web: www.dkfz.de -- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Miguel A. Figueroa-Villanueva wrote:
es.
- Add an easy way to create dependent cache variables, that when changed
unset a number of other variables.
A while back I had opened a feature request on the third item:
http://public.kitware.com/Bug/view.php?id=7286
I think it is a fairly simple thing to implement if no speed issues
are considered, which I don't think these would be a problem. That is,
save the cache before the configure iteration and check if the entries
listed in the dependencies list have changed. If so, reset the cache
entry.
I am not sure I understand how your DEPEND keyword would work?
BTW, this type of thing can be done by using two cache variables right
now. For example from FindQt4.cmake:
IF(QT_QMAKE_EXECUTABLE_LAST AND NOT QT_QMAKE_EXECUTABLE_LAST MATCHES
^${QT_QMAKE_EXECUTABLE}$)
SET(QT_QMAKE_CHANGED 1)
ENDIF(QT_QMAKE_EXECUTABLE_LAST AND NOT QT_QMAKE_EXECUTABLE_LAST
MATCHES ^${QT_QMAKE_EXECUTABLE}$)
SET(QT_QMAKE_EXECUTABLE_LAST ${QT_QMAKE_EXECUTABLE} CACHE INTERNAL
FORCE)
I think what is needed is a more general way to add dependent cache
variables.
check_cache_depend(VAR1 DVAR1 DVAR2 DVAR3 DVAR4)
If VAR1 changes in the cache from a previous value, then DVAR1, DVAR2,
DVAR3, and DVAR4 are all removed from the cache. You would put
something like that at the top of a FindFoo.cmake module. For Qt it
would be:
check_cache_depend(QT_QMAKE_EXECUTABLE QT_QTDESIGNERCOMPONENTS_INCLUDE_DIR
QT_QTDESIGNERCOMPONENTS_LIBRARY_RELEASE
...)
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Miguel A. Figueroa-Villanueva wrote: On Mon, Nov 10, 2008 at 10:09 AM, Bill Hoffman wrote: Jed Brown wrote: Thanks Bill. I'm very encouraged by the response this thread has generated and optimistic that the Find* modules will become more robust without undue effort by module writers. Well, it is not going to happen over night, but I think we are closer to a plan. I am going to update the wiki with the main three ideas of this thread so it does not get lost. - Standard FOO_DIR for find modules, but environment and cache. Environment works like CC and CXX do. - Add ability to parse compile lines like the ones produced from pkg-config and turn them into full paths to libraries. - Add an easy way to create dependent cache variables, that when changed unset a number of other variables. A while back I had opened a feature request on the third item: http://public.kitware.com/Bug/view.php?id=7286 I think it is a fairly simple thing to implement if no speed issues are considered, which I don't think these would be a problem. That is, save the cache before the configure iteration and check if the entries listed in the dependencies list have changed. If so, reset the cache entry. I'd like that behavior available outside of a find_xxx command as well. FindQt4.cmake has some manually set cache variables that need to be considered, some of which interact with other calls to find_xxx. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Mathias Fröhlich wrote: Hi, On Monday 10 November 2008 16:29, Bill Hoffman wrote: Can you describe exactly what you think autotools does here? I guess most autotools tests use a try-compile to find a library. Is that what you are referring to? Yep. If you want to link with a library you need to test if you can link with that library. If you test something different, you might then later be surprised, that linking does not work ... ... and yes this takes more time than just testing for existence. But it is way more correct ... OK, so perhaps the FindFoo.cmake modules should always use a try-compile to test the library that is found works with the current ABI. This will likely slow things down quite a bit... This would require some extra thought Perhaps the abi can be determined without a try-compile, but I am not sure that would work on all platforms. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] file-glob question
Le Mon, 10 Nov 2008 12:36:04 +0100, Steven Van Ingelgem [EMAIL PROTECTED] a écrit : Hi all, I'm trying to do the following: file(GLOB PLUGINS plugins/*) This returns all the absolute paths to the plugins. Which is fine. But, when I try: file(GLOB PLUGINS RELATIVE plugins/*) Woud you try: file(GLOB PLUGINS RELATIVE plugins plugins/*) see documentation file(GLOB variable [RELATIVE path] [globbing expressions]...) It gives me an error about file GLOB requires a glob expression after the directory [...] Or is it something I am interpreting wrong? more careful doc reading :=) -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making Nightly builds easier to setup
The variable CTEST_INITIAL_CACHE is ignored in new-style (CTEST_BUILD()
command based) ctest scripts.
Instead, you should use:
FILE(WRITE ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt
MAKECOMMAND:STRING=nmake -i
CMAKE_MAKE_PROGRAM:FILEPATH=nmake
CMAKE_GENERATOR:INTERNAL=NMake Makefiles
BUILDNAME:STRING=Win32-nmake71
SITE:STRING=VOGON.kitware
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
)
(But only on a clean build, after calling
CTEST_EMPTY_BINARY_DIRECTORY(${CTEST_BINARY_DIRECTORY}), or perhaps only
if the CMakeCache.txt does not exist in the first place...)
HTH,
David
On Mon, Nov 10, 2008 at 5:33 AM, Martin Apel [EMAIL PROTECTED] wrote:
Eric Noulard wrote:
2008/11/9 Alexander Neundorf [EMAIL PROTECTED]:
[...]
commands can be executed.
IMO this can make setting up Nightly builds much easier.
Looks interesting, I didn't ever thought ctest scripting was done for
that.
I did shell scripts for that and was wondering how to do it on Windows
:-)
Now I know.
What do you think ?
One thing which is still missing is a way how to get variables
predefined into
the cmake-configure run during ctest_configure().
Does this have to be done by writing an initial CMakeCache.txt ?
This seems possible using CTEST_INITIAL_CACHE
as shown here:
http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
# this is the initial cache to use for the binary tree, be careful to
escape
# any quotes inside of this string if you use it
SET (CTEST_INITIAL_CACHE
MAKECOMMAND:STRING=nmake -i
CMAKE_MAKE_PROGRAM:FILEPATH=nmake
CMAKE_GENERATOR:INTERNAL=NMake Makefiles
BUILDNAME:STRING=Win32-nmake71
SITE:STRING=VOGON.kitware
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
)
I recently played around with nightly builds as well. I used to have a
setup for experimental builds, but never could get the svn checkout to
run. With the approach described above, I was finally able
to run checkout from svn from within ctest. Unfortunately it seems that
some variables are not used anymore with this approach of generating
builds.
I found that CTEST_INITIAL_CACHE as well as CTEST_ENVIRONMENT seem to be
ignored, when using CTEST_BUILD etc. For the environment variables I
could get it to work by setting
the environment variables explicitly, e.g. 'SET (ENV{CC} gcc-4.2)'.
That means that the approach proposed above does not work, at least not
for me.
After all I'm somewhat confused about this new approach ignoring some of
the variables. Maybe someone with a deeper knowledge of ctest could
explain, what's going on here.
Regards,
Martin
Virus checked by G DATA AntiVirus
Version: AVF 19.138 from 09.11.2008
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making Nightly builds easier to setup
If you don't want to overwrite the CMakeCache.txt file, you can do the
following instead of a FILE(WRITE...). This also works if you don't have an
initial CMakeCache.txt file.
SET(FORCED_CACHE_VALUES
\-DCMAKE_OSX_ARCHITECTURES:STRING=i386;ppc\
\-DCMAKE_BUILD_TYPE:STRING=Release\
)
STRING(REGEX REPLACE \; \ FORCED_CACHE_VALUES ${FORCED_CACHE_VALUES})
SET(CTEST_CONFIGURE_COMMAND \${CTEST_CMAKE_COMMAND}\ ${FORCED_CACHE_VALUES}
\${CTEST_SOURCE_DIRECTORY}\)
CTEST_CONFIGURE(BUILD ${CTEST_BINARY_DIRECTORY} RETURN_VALUE config_result)
Clint
On Monday 10 November 2008 9:44:43 am David Cole wrote:
The variable CTEST_INITIAL_CACHE is ignored in new-style (CTEST_BUILD()
command based) ctest scripts.
Instead, you should use:
FILE(WRITE ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt
MAKECOMMAND:STRING=nmake -i
CMAKE_MAKE_PROGRAM:FILEPATH=nmake
CMAKE_GENERATOR:INTERNAL=NMake Makefiles
BUILDNAME:STRING=Win32-nmake71
SITE:STRING=VOGON.kitware
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
)
(But only on a clean build, after calling
CTEST_EMPTY_BINARY_DIRECTORY(${CTEST_BINARY_DIRECTORY}), or perhaps only
if the CMakeCache.txt does not exist in the first place...)
HTH,
David
On Mon, Nov 10, 2008 at 5:33 AM, Martin Apel [EMAIL PROTECTED] wrote:
Eric Noulard wrote:
2008/11/9 Alexander Neundorf [EMAIL PROTECTED]:
[...]
commands can be executed.
IMO this can make setting up Nightly builds much easier.
Looks interesting, I didn't ever thought ctest scripting was done for
that.
I did shell scripts for that and was wondering how to do it on Windows
:-)
:
Now I know.
What do you think ?
One thing which is still missing is a way how to get variables
predefined into
the cmake-configure run during ctest_configure().
Does this have to be done by writing an initial CMakeCache.txt ?
This seems possible using CTEST_INITIAL_CACHE
as shown here:
http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
# this is the initial cache to use for the binary tree, be careful to
escape
# any quotes inside of this string if you use it
SET (CTEST_INITIAL_CACHE
MAKECOMMAND:STRING=nmake -i
CMAKE_MAKE_PROGRAM:FILEPATH=nmake
CMAKE_GENERATOR:INTERNAL=NMake Makefiles
BUILDNAME:STRING=Win32-nmake71
SITE:STRING=VOGON.kitware
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
)
I recently played around with nightly builds as well. I used to have a
setup for experimental builds, but never could get the svn checkout to
run. With the approach described above, I was finally able
to run checkout from svn from within ctest. Unfortunately it seems that
some variables are not used anymore with this approach of generating
builds.
I found that CTEST_INITIAL_CACHE as well as CTEST_ENVIRONMENT seem to be
ignored, when using CTEST_BUILD etc. For the environment variables I
could get it to work by setting
the environment variables explicitly, e.g. 'SET (ENV{CC} gcc-4.2)'.
That means that the approach proposed above does not work, at least not
for me.
After all I'm somewhat confused about this new approach ignoring some of
the variables. Maybe someone with a deeper knowledge of ctest could
explain, what's going on here.
Regards,
Martin
Virus checked by G DATA AntiVirus
Version: AVF 19.138 from 09.11.2008
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] [New Module] FindDevIL.cmake
Hi list,
This is a pretty simple module. I'd like to give back to cmake, even in
a small way. I'll maintain this module myself if it's put into the cmake
core.
Chris.
# This module locates the developer's image library.
# http://openil.sourceforge.net/
#
# This module sets:
# IL_LIBRARY the name of the IL library.
# ILU_LIBRARY the name of the ILU library.
# ILUT_LIBRARY the name of the ILUT library.
# IL_INCLUDE_DIR where to find the il.h, ilu.h and ilut.h files.
# IL_FOUND this is set to TRUE if all the above variables were set.
# Original file by: Christopher Harvey
CMAKE_MINIMUM_REQUIRED(VERSION 2.6 FATAL_ERROR)
INCLUDE(${CMAKE_ROOT}/Modules/FindPackageHandleStandardArgs.cmake)
FIND_PATH(IL_INCLUDE_DIR il.h
PATH_SUFFIXES include IL
DOC The path the the directory that contains il.h
)
#MESSAGE(IL_INCLUDE_DIR is ${IL_INCLUDE_DIR})
FIND_LIBRARY(IL_LIBRARY
NAMES IL
PATH_SUFFIXES lib64 lib lib32
DOC The file that corresponds to the base il library.
)
#MESSAGE(IL_LIBRARY is ${IL_LIBRARY})
FIND_LIBRARY(ILUT_LIBRARY
NAMES ILUT
PATH_SUFFIXES lib64 lib lib32
DOC The file that corresponds to the il (system?) utility library.
)
#MESSAGE(ILUT_LIBRARY is ${ILUT_LIBRARY})
FIND_LIBRARY(ILU_LIBRARY
NAMES ILU
PATH_SUFFIXES lib64 lib lib32
DOC The file that corresponds to the il utility library.
)
#MESSAGE(ILU_LIBRARY is ${ILU_LIBRARY})
FIND_PACKAGE_HANDLE_STANDARD_ARGS(IL DEFAULT_MSG
IL_LIBRARY ILU_LIBRARY
ILUT_LIBRARY IL_INCLUDE_DIR)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
I have created a new wiki entry here: http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Proposed_solutions_to_Find.2A_issues I merge the information in these entries into the above entry: http://www.cmake.org/Wiki/CMake:Static_libraries http://www.cmake.org/Wiki/CMake:Multiple_versions Then remove the Static_libraries and Multiple_versions entries. Some of the information is duplicated and some of it can be put in the current workaround section I created. Jed can you take a pass at that? Thanks. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] package_source target?
2008/11/7 Alin M Elena [EMAIL PROTECTED]: Hi, Sorry for the quoting thing. the cvs one. It seems that neither CVS HEAD nor CVS CMake-2-6 generates the package_source target any more... whereas CMake-2-6-2 do generates the package_source... I'll wait the next RC before filing a bug :-) -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
Bill Hoffman wrote: I have created a new wiki entry here: http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Proposed_solutions_to_Find.2A_issues I merge the information in these entries into the above entry: http://www.cmake.org/Wiki/CMake:Static_libraries http://www.cmake.org/Wiki/CMake:Multiple_versions Then remove the Static_libraries and Multiple_versions entries. Some of the information is duplicated and some of it can be put in the current workaround section I created. Jed can you take a pass at that? Oops, I meant to say: I would like to merge the information in these entries into the above entry: http://www.cmake.org/Wiki/CMake:Static_libraries http://www.cmake.org/Wiki/CMake:Multiple_versions -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
On Sun 2008-11-09 17:55, Bill Hoffman wrote:
OK, so you have version of libraries that are not in default locations,
how is any build system supposed to find stuff like this?
Of course not automatically, but with minimal hinting. Ideally the user
runs CMake and sees one visible cache entry indicating the root at which
packages were found. If the user notices that FOO_DIR is not the
intended version, they would change that cache variable and reconfigure.
In the current scheme, the module writer needs to do significant work to
get this behavior. I think Eric's suggestion is much nicer than my
FIND_PACKAGE_MULTIPASS macro, but it needs language support.
My point about CC and friends is that there are often standard
environment variables for setting this stuff. I think it should be
possible to select the version of packages with one variable. For Qt4,
this is the qmake executable, for PETSc, it is (by convention) PETSC_DIR
and PETSC_ARCH. With most packages, if the wrong version is found by
default, the user is required to edit all the advanced cache entries or
to delete the cache manually and try again with the correct variable
set.
...
There is some code inside CMake that does library path searching. It
might make sense to have a command that parses link lines and finds the
libraries. I am thinking a new command might be a good idea.
I agree, it's really painful to do this in a robust way in CMake. The
command needs significant semantics (like understanding nested shell
quoting) to handle pathological inputs (which mine doesn't). For
instance, if the library makefile system sets
FOO_CFLAGS = -I/path/to/foo/include -DBAD='Some -Ipathological string'
it would be nice to parse this correctly. I know this looks like
over-engineering, but logic to parse this correctly must exist somewhere
in CMake already.
...
So, what does BuildSystem do to handle this? Is there anything that
can be learned?
It's not elegant. It always assumes that the entire dependency graph
needs to be linked (as with static libraries). The analogue of Find*
modules recognize this and behave accordingly. Component Foo can always
be selected using
--with-foo-dir=/path/to/foo
or, if your layout is sufficiently pathological (i.e. not something the
module checks), by using
--with-foo-include=/path/to/include/foo-1.2 \
--with-foo-dir=-L/path/to/lib64/foo-1.2 -lfoo -lfoocore
There is no cached state, so every time you run configure, everything is
found again. If anything doesn't work, the configure step fails with an
error message and a log file. This means there can never be stale cache
entries, but it also makes the reconfigure step slow. If you're trying
to determine how to use a library which is not checked early in the
configuration process, it may take unacceptably long to report that the
options you gave don't work. Upon successful configure, a summary of
which versions of all libraries are being used is printed on stdout and
a python script is written at
${PETSC_DIR}/${PETSC_ARCH}/conf/reconfigure-${PETSC_ARCH}.py
which contains all the needed options. Running this script is similar
to running CMake after the CMakeLists.txt has been changed.
I think the semantics of BuildSystem (always recognizes --with-foo-dir,
never has stale cache) are good. It is immediately clear to the user
which version is being used. When a cache is present (which I think we
all agree is a good thing) deciding when tests need to be rerun is
tricky. If the user sets variables that change how anything is
resolved, the test needs to be rerun. See my hack
MULTIPASS_C_SOURCE_RUNS which forces everything to be rerun each time it
is called. Encapsulating the environment of a test is a hard problem,
but a false positive is much better than a false negative. That is,
it's better to rerun a test that didn't really need to be rerun than to
rely on a stale cache entry. I sometimes find myself repeatedly running
this
$ rm -r * cmake .. -DFOO_VAR=blah
to guarantee that the cache is not stale and all necessary tests are
actually run.
...
1. CMake needs a command to parse compiler link lines that may come from
pkg-config, makefile fragments or some other config file. The parsing
should act like a linker, and give the results in full paths to the
libraries. This can be done ad-hoc and is done by some folks now using
custom macros. We should be able to use some of the internal CMake
library path resolution code to do this.
Great.
2. CMake needs a way to easily chain variables together so that you can
clear stuff out if a dependent variable is changed by the user. So, if
you have MY_PATH_TO_TOOL=/path/to/tool, and it changes to
/new/path/to/tool, then all the libraries that where found using
MY_PATH_TO_TOOL should be reset and rediscovered. Currently, this is
done ad-hoc in CMake, for example Clinton just added something to the
FindQt4 that will reset all
Re: [CMake] package_source target?
Eric Noulard wrote: 2008/11/7 Alin M Elena [EMAIL PROTECTED]: Hi, Sorry for the quoting thing. the cvs one. It seems that neither CVS HEAD nor CVS CMake-2-6 generates the package_source target any more... whereas CMake-2-6-2 do generates the package_source... I'll wait the next RC before filing a bug :-) Should be fixed in CVS HEAD: $ cvs commit -m BUG: fix package_source target cmGlobalGenerator.cxx Committer: Bill Hoffman [EMAIL PROTECTED] /cvsroot/CMake/CMake/Source/cmGlobalGenerator.cxx,v -- cmGlobalGenerator.cxx new revision: 1.246; previous revision: 1.245 Will be in the next RC as well. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making Nightly builds easier to setup
On Monday 10 November 2008, Martin Apel wrote:
...
I recently played around with nightly builds as well. I used to have a
setup for experimental builds, but never could get the svn checkout to
run. With the approach described above, I was finally able
to run checkout from svn from within ctest. Unfortunately it seems that
some variables are not used anymore with this approach of generating
builds. I found that CTEST_INITIAL_CACHE as well as CTEST_ENVIRONMENT seem
to be ignored, when using CTEST_BUILD etc. For the environment variables I
could get it to work by setting
the environment variables explicitly, e.g. 'SET (ENV{CC} gcc-4.2)'.
That means that the approach proposed above does not work, at least not
for me.
I wouldn't say it doesn't work, but instead it's a first try and not
finished yet.
Thanks for pointing the problems out.
Where do you set these variables ?
In this script or e.g. CTestCustom.cmake ?
After all I'm somewhat confused about this new approach ignoring some of
the variables. Maybe someone with a deeper knowledge of ctest could
explain, what's going on here.
I'm not really the one with deeper ctest knowledge, but I can say that
scripting using the new style commands works different from the old style.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Avoid nested cmake invocation taking parent's info.
On Monday 10 November 2008, Óscar Fuentes wrote: Eric NOULARD [EMAIL PROTECTED] writes: The problem is in execute_process. The cmake process created by it is taking variable values from the enclosing cmake, so it uses the same compiler, configure variables, etc. What do you mean by variables? CMake one or Environment one? When cmake is invoked with -DCMAKE_TOOLCHAIN_FILE=foo, the nested cmake runs as invoked with this definition as well. It takes config-assigned variables from the parent cmake, too. I don't see how this should happen. Do you cross-compile in-source ? The the second cmake would see the CMakeCache.txt from the cross compile. In that case: don't build in-source. If this is not the reason, please post a small example project so I can see what's going on. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to associate a command with a auto-generated target?
On Monday 10 November 2008, Óscar Fuentes wrote:
I wish to execute a command when the `clean' target is invoked. That is,
my command shall execute on addition of the normal target action.
Doesn't work, you have to do it the other way round: create a custom target
my-special-clean, do what you need, and also execute something like
${CMAKE_MAKE_COMMAND} directories etc clean
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to disable cmake_clean_target.cmake script from executing.
On Monday 10 November 2008, Eric NOULARD wrote:
Le Mon, 10 Nov 2008 16:22:48 +0900,
...
You may try to create your static lib from the top-level CMakeLists.txt
FILE(GLOB_RECURSE SOURCE_FILE_LIST *.cpp)
FILE(GLOB_RECURSE HEADER_FILE_LIST *.h)
ADD_LIBRARY(whatever STATIC ${SOURCE_FILE_LIST} ${HEADER_FILE_LIST})
cmake -P cmake_clean_target.cmake
If someway I could be able to block that script from executing I will
have a static library with all the sources merged into one file.
I won't do that, that way.
I agree with Eric, don't try to do that.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does `cross-platform' mean?
On Monday 10 November 2008, Bill Hoffman wrote:
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Well, it is not going to happen over night, but I think we are closer to
a plan. I am going to update the wiki with the main three ideas of this
thread so it does not get lost.
- Standard FOO_DIR for find modules, but environment and cache.
Environment works like CC and CXX do.
CMake already uses this when searching for FOOConfig.cmake files.
How should it behave ?
It could be done manually, i.e. every module has to have some code like that:
find_path(FOO_INCLUDE_DIR foo.h HINTS ${FOO_DIR}/include )
Same for find_library().
This wouldn't require a lot (any ?) work in cmake. But it would be a bit ugly
for searching libs (sometimes in lib, lib32 or lib64).
Or should the find_library() etc. calls check automatically whether they are
called from some FindFoo.cmake module and check for the respective variable
automatically ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to associate a command with a auto-generated target?
Hello, Alex.
Alexander Neundorf [EMAIL PROTECTED]
writes:
I wish to execute a command when the `clean' target is invoked. That is,
my command shall execute on addition of the normal target action.
Doesn't work, you have to do it the other way round: create a custom target
my-special-clean, do what you need, and also execute something like
${CMAKE_MAKE_COMMAND} directories etc clean
Sadly, this is not acceptable. People complain about having to learn
cmake and I want to avoid giving them a reason for complaining about
having to learn project-specific ways of doing standard things.
BTW, CMAKE_MAKE_COMMAND is not listed on --help-variables. You mean
CMAKE_BUILD_TOOL, don't you?
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to associate a command with a auto-generated target?
On Monday 10 November 2008, Óscar Fuentes wrote:
Hello, Alex.
Alexander Neundorf [EMAIL PROTECTED]
writes:
I wish to execute a command when the `clean' target is invoked. That is,
my command shall execute on addition of the normal target action.
Doesn't work, you have to do it the other way round: create a custom
target my-special-clean, do what you need, and also execute something
like ${CMAKE_MAKE_COMMAND} directories etc clean
Sadly, this is not acceptable.
Setting the ADDITIONAL_CLEAN_FILES directory property is not powerful enough
for you ?
Hmm. Then name it something like veryclean, distclean (oops) or somewhere
I have also seen mrproper. I hope they will accept it.
What exactly do you have to clean ? Maybe an additional dependency on
something would make the cleaning unnecessary ?
People complain about having to learn
cmake and I want to avoid giving them a reason for complaining about
having to learn project-specific ways of doing standard things.
BTW, CMAKE_MAKE_COMMAND is not listed on --help-variables. You mean
CMAKE_BUILD_TOOL, don't you?
Both exist, I guess CMAKE_BUILD_TOOL is the recommended one.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake uses wrong value of ProgramFiles variable on Windows platforms
Consider the following:
C:\Users\myself\Testtype CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project (Test)
message (STATUS ENV{ProgramFiles}=$ENV{ProgramFiles})
C:\Users\myself\Testset ProgramFiles
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
C:\Users\myself\Testcmake -G NMake Makefiles
-- ENV{ProgramFiles}=C:\Program Files (x86)
-- Configuring done
-- Generating done
-- Build files have been written to:
C:/Users/elemings/Developer/Test/CMake/test05
A.) Why is CMake intentionally using the wrong value for ProgramFiles,
and B.) should this be corrected?
Thanks,
Eric.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to associate a command with a auto-generated target?
Alexander Neundorf [EMAIL PROTECTED]
writes:
Doesn't work, you have to do it the other way round: create a custom
target my-special-clean, do what you need, and also execute something
like ${CMAKE_MAKE_COMMAND} directories etc clean
Sadly, this is not acceptable.
Setting the ADDITIONAL_CLEAN_FILES directory property is not powerful enough
for you ?
I guess you mean ADDITIONAL_MAKE_CLEAN_FILES. That was not what you
proposed on your previous message :-)
For this case, where a directory must be deleted together with all its
contents, it works.
Thank you, Alex.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake uses wrong value of ProgramFiles variable on Windows platforms
You have discovered the magic of Windows. Again.
CMake is a 32-bit process. When Windows launches a 32-bit process on a Win64
machine, it gives the 32-bit process C:\ProgramFiles (x86) as the value of
the env var ProgramFiles. But you are testing it from a 64-bit program,
the default cmd.exe on Win64.
You can also test if from the 32-bit cmd.exe, which is available at
C:\WINDOWS\SysWow64\cmd.exe:
(default 64-bit cmd.exe results)
C:\set ProgramFiles
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
(explicit 32-bit cmd.exe results -- same as what cmake gets as a 32-bit app)
C:\C:\WINDOWS\SysWow64\cmd.exe
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\set ProgramFiles
ProgramFiles=C:\Program Files (x86)
ProgramFiles(x86)=C:\Program Files (x86)
C:\exit
C:\
So. cmake is not wrong. Windows is not wrong. It just is what it is.
ProgramFiles is a special env var. Adapt accordingly, I guess, is the best
advice I have for you... :-)
HTH,
David
On Mon, Nov 10, 2008 at 5:04 PM, Eric (Brad) Lemings [EMAIL PROTECTED] wrote:
Consider the following:
C:\Users\myself\Testtype CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project (Test)
message (STATUS ENV{ProgramFiles}=$ENV{ProgramFiles})
C:\Users\myself\Testset ProgramFiles
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
C:\Users\myself\Testcmake -G NMake Makefiles
-- ENV{ProgramFiles}=C:\Program Files (x86)
-- Configuring done
-- Generating done
-- Build files have been written to:
C:/Users/elemings/Developer/Test/CMake/test05
A.) Why is CMake intentionally using the wrong value for ProgramFiles,
and B.) should this be corrected?
Thanks,
Eric.
___
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] link_libraries vs target_link_libraries
Hi, my 2c...
2008/11/10 Andreas Pakulat [EMAIL PROTECTED]
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} )
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.
Boost is a good example (albeit it doesn't use cmake to build itself).
they have just added cmake support, i think it was just added to the trunk
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.
i would disagree, its common practice to have only includedir in the
include-directories, and then you
#include boost/shared_ptr.hpp
For the case of a single library with a few headers, for which a UseXXX
file is provided the requirement really doesn't make much sense (IMHO) -
unless you can use some of the headers without linking.
(snipped from above)
On 10.11.08 12:01:13, Fernando Cacciola wrote:
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???
I can specify which headers I want to include by writing #includes in my
.cpp file.
But the ONLY place I can specify which libraries I want to include is within
CMake config files. Thus, you only need target_link_libraries and not
target_add_directories.
As for target_add_definitions, you don't add definitions to a target, you
add them to cpp files you are compiling. I think you can define them for
certain files if you have the add_definition in a subdirectory
CMakeLists.txt, but I'm not sure how else you can limit its 'scope'.
Paul
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
