Re: [cmake-developers] Package Config files with COMPONENTS
On 03/13/2012 09:55 PM, Brad King wrote:
On Tue, Mar 13, 2012 at 4:43 PM, Alexander Neundorf neund...@kde.org wrote:
We could also not set pkg_FIND_REQUIRED_component, or set it to 0
(which
would mean it is not required).
Even better. One can loop over the_FIND_COMPONENTS list and then test
the variable to see if it is really required or not.
Are there any compatibility issue to take into account ?
Until now, there never was a OPTIONAL_COMPONENT, so every call to
find_package(COMPONENTS ...) will work as before.
I don't think there is a compatibility concern. A loop like the above
would just consider every component required when the package is
loaded by an older project that does not use the new keyword.
If somebody adds a OPTIONAL_COMPONENTS, this will add component entries to
the
FIND_COMPONENTS variable which have now _FIND_REQUIRED_ set to 0.
The Find-module or Config-file may not be prepared to handle this.
I do not think that is a problem. The calling project should only use
this option if the package to be found documents that it supports
optional components. This is the same as passing only components
documented by the package as known.
What is actually the purpose of the _FIND_REQUIRED_ variable ?
It currently doesn't add any information compared to the list
_FIND_COMPONENTS. Are you aware of any uses of this variable ?
_FIND_REQUIRED_ came first. The entire feature was first added here:
http://www.cmake.org/Bug/view.php?id=2771
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f625bea
The _FIND_COMPONENTS list was added later because it is more convenient.
The argument parsing in cmFindPackage still has to decide what to do if a
component appears multiple times.
Error out ?
REQUIRED always has priority over OPTIONAL ?
Last one wins ?
I think error is best. It's better to be explicit so authors do not
assume ether way.
IMO, using solely pkg_FIND_REQUIRED_component to indicate if
a requested component is mandatory or optional is not sufficient.
Consider the following use case:
FIND_PACKAGE(Foo COMPONENTS X OPTIONAL_COMPONENTS Y)
Suppose both X and Y do require a component A. AFAICS, this is a
completely regular case and provides for a component that should
conceptually be considered mandatory *and* optional.
In {FindFoo,FooConfig}.cmake, it has proven to be very convenient
to add such prerequisite components to Foo_FIND_COMPONENTS at the
beginning in order to process all components in a unique manner
later on. Which value should one set Foo_FIND_REQUIRED_A to?
Instead, I'd suggest not to touch the value of Foo_FIND_REQUIRED_*
but to add a further variable like Foo_FIND_OPTIONAL_*, as it is
already done in 1a157e7. Then, just accept it if both variables
are TRUE and leave it to {FindFoo,FooConfig}.cmake how to handle
this case, i.e. bail out, prefer REQUIRED to OPTIONAL or whatever.
IMO, this does neither imply inherent contradictions to be handled
by FIND_PACKAGE() nor constrain {FindFoo,FooConfig}.cmake's freedom
to process components in any suitable way. Finally, one could simply
allow arbitrary duplicates after COMPONENTS and OPTIONAL_COMPONENTS.
Note that this does not affect the question whether there should be
a sole comprehensive Foo_FIND_COMPONENTS variable or an additional
Foo_FIND_OPTIONAL_COMPONENTS one.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Using cmake to build link to autotools based project
On 03/13/2012 10:10 AM, Kurien Mathew wrote: Hello, I have a solution (collection of projects) that is built using cmake. In this solution some projects depend on 3rd party projects that use gnu autotools. I would like to build and link to these autotools based projects from the cmake build. Where can I find additional information on this topic? Thanks Kurien http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject http://www.kitware.com/products/html/BuildingExternalProjectsWithCMake2.8.html Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
On 03/10/2012 02:25 PM, Alexander Neundorf wrote: On Friday 09 March 2012, Michael Hertling wrote: On 03/05/2012 02:04 AM, Stephen Kelly wrote: ... I don't actually see the problem with checking Qt5_XYZ_FOUND. Unset variables are well defined as false in the if() command. Maybe I misunderstand you? Maybe. ;-) What ensures the variables had already been unset before FIND_PACKAGE() was invoked? If they had evaluated as TRUE - for what- ever reason - and FIND_PACKAGE() fails to load Qt5Config.cmake, they will still be TRUE afterwards although Qt5 has not been found at all. IMO, if FIND_PACKAGE() fails to locate a package, one shouldn't rely on the assumption that any variable except *_FOUND has a reasonable value. Thus, in order to play safe, one should access the variables only after checking the package's successful detection, Yes, exactly :-) It's very good there's a consensus in this respect. ;-) (...which would be the case with the set _FOUND only TRUE if all components have been found). Only in the successful case; in the failing case, *_FOUND would not provide any information about the package's presence. Anyway, your proposal stated below is capable to address this issue, AFAICS. e.g. like: IF(Qt5_FOUND AND Qt5_Xml_FOUND) See the other thread With a potential OPTIONAL_COMPONENTS parameters you could do: find_package(Qt5 COMPONENTS QtXml) and checking Qt5_FOUND would be enough. If you do find_package(Qt5 COMPONENTS QtXml OPTIONAL_COMPONENTS QtFoo) you would have to check both Qt5_FOUND and Qt5_QtFoo_FOUND. This sounds quite attractive; I'll answer to it on the other thread. This consideration is one of my major objections against the proposal w.r.t. permitting config files to set *_FOUND by themselves. Here I object. This is necessary. Let's say one Config file depends on another one and does find_package(TheOtherPackage NO_MODULE) If TheOtherPackage is not found, it must be possible for the calling Config file to indicate that, although the Config file has been found, the package is not usable. because its dependencies have not been found. This is a very good point. Until now, I presumed that a config file contains the necessary information about its package's prerequisites in a hard-coded manner, so it does not need to invoke FIND_PACKAGE(). Usually, that's possible since the information is available already at configuration time. Allowing config files to call FIND_PACKAGE() would surely add a certain flexibility, but it also bears a risk: A successfully configured/built/installed package might fail at deploy time because of an unavailable prerequisite that has been available once before. If one is generally aware of this risk and willing to accept it, I'm fine with it, too. One or two thoughts and another cup of coffee later, I think that allowing a config file to set *_FOUND by itself can actually be a benefit, so my concerns about that are pretty much dispelled. :-) Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Operator Precedence
On 03/12/2012 07:32 PM, Robert Dailey wrote: What is the precedence for logical operators (specifically in IF conditions)? Consider: STREQUAL, AND, OR (plus any others) Documentation of IF(): ...there is a traditional order of precedence. Parenthetical expressions are evaluated first followed by unary operators such as EXISTS, COMMAND, and DEFINED. Then any EQUAL, LESS, GREATER, STRLESS, STRGREATER, STREQUAL, MATCHES will be evaluated. Then NOT operators and finally AND, OR operators will be evaluated. Documentation of WHILE(): The condition is evaluated using the same logic as the if command. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Linking Error
On 03/08/2012 05:40 PM, buzz clay wrote:
Hi,
I have not been able to find the answer to my current problem so I thought
I'd try a new post. Before diving into the details, please be aware that
the code I am writing compiles/runs perfectly with a personal Makefile I
wrote.
My code is written in C++ and has many different class definitions. To run
different simulations some classes may or may not have actual objects
created. However, there are other portions of the code that specifically
reference functions from nearly all classes (although this code might not
actually be used because the object was never created). The linking errors
that I am facing arise when I do not make an object of a given class. Other
parts of the code need to be aware that the class exists, even if an object
was never made. Although this seems like it would be a result of not
including the appropriate header files, I assure you they are correct! For
some reason, if I do not make an object of a given class cmake ignores
the class and when it comes time to link everything together I get the
following error:
Linking CXX executable collision
Output/libOutput.a(Output.cpp.o): In function
`Output::Output(std::vectorBall*, std::allocatorBall* *,
std::vectorCollisionObject*, std::allocatorCollisionObject* *)':
Output.cpp:(.text+0x379): undefined reference to `SWall::getY2()'
Output.cpp:(.text+0x391): undefined reference to `SWall::getX2()'
Output.cpp:(.text+0x3a9): undefined reference to `SWall::getY1()'
Output.cpp:(.text+0x3c1): undefined reference to `SWall::getX1()'
collect2: ld returned 1 exit status
make[2]: *** [collision] Error 1
make[1]: *** [CMakeFiles/collision.dir/all] Error 2
make: *** [all] Error 2
PLEASE NOTE: If in my main.cpp file I simply create an SWall object and
never use it, the errors go away and everything works perfectly. I simply
do not understand why cmake would care whether or not I actually make an
object of a given class!
The following is my CMakeLists.txt file in the highest level directory:
cmake_minimum_required(VERSION 2.8)
project(collision CXX)
add_subdirectory(Extraneous)
add_subdirectory(Output)
add_subdirectory(Simulation)
add_subdirectory(CollisionObject)
add_definitions(-ansi -Wall -O2)
add_executable(collision test.cpp)
target_link_libraries(collision Simulation)
target_link_libraries(collision PriorityQueue)
target_link_libraries(collision Event)
target_link_libraries(collision Ball)
target_link_libraries(collision SWall)
target_link_libraries(collision Circle)
target_link_libraries(collision Output)
target_link_libraries(collision SimpleMath)
INSTALL(PROGRAMS ${CMAKE_BINARY_DIR}/collision DESTINATION
${CMAKE_SOURCE_DIR})
All of the lower level directories simply had add_library(libname
libname.cpp) in the CMakeLists.txt file. [...]
I.e., they don't have TARGET_LINK_LIBRARIES() commands? If so, CMake
can't know that Output must be linked against SWall, and in your
final link command line, the former appears behind the latter -- un-
defined references. Express all your targets' immediate dependencies
via TARGET_LINK_LIBRARIES(), and drop the mediate ones if there are
any; CMake figures them out by itself.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] top level make
On 03/11/2012 10:27 PM, Totte Karlsson wrote: Hi, My project depends on several third party libraries, e.g. vtk. I wonder, if it is possible to setup using CMake so that when building my project, necessary third party libs are built as well. Or is it advisable to keep it separate? My src folder structure is top\ -\mySource -\ThirdParty\vtk -\ThirdParty\SomeOther libs Cheers, Totte See the ExternalProject module [1]. Regards, Michael [1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
On 03/05/2012 02:04 AM, Stephen Kelly wrote:
Michael Hertling wrote:
* Currently there is no Qt5Config.cmake.
Such a thing could probably exist and use the FIND_COMPONENTS to find
what was requested. [...]
Hi there,
Thank you for your insights on this issue. Do you have any other insights
into other issues I raised in the original post?
No, I just picked out the Qt5Config.cmake ones. Perhaps later...
Absolutely, I would greatly appreciate a well-designed and component-
aware Qt5Config.cmake.
Yes. This thread confirms though that it is not a simple issue as I wrote
before :)
Indeed, component-aware find modules / config files are significantly
more complicated than component-unaware ones. Typical questions are:
- Accumulation of result variables
- Handling of unknown components
- Searching unrequested components
- Interpretation of *_FOUND variable
- Untouched *_*_FOUND variables
- Impact of REQUIRED/QUIET
In general, there might be reasons why a multi-
component package's components that are to be used together should not
be requested in separate FIND_PACKAGE() invocations, see [1] and look
for package X with components A and B. However, I don't know if Qt5
will be the first example of that kind.
Your exact example is not covered by the Qt5 situation as far as I can tell.
However, similar issues already crop up (with Qt4 based systems). Can you
confirm whether you are aware of the issues around code like this regarding
the use of -DQT_GUI_LIB with the foo target so I know if I need to explain
it and whether we are on the same page? :
find_package(Qt4 REQUIRED Gui Test)
include(${QT_USE_FILE})
add_executable(bar ${QT_QTCORE_LIBRARIES} ${QT_QTGUI_LIBRARIES})
add_executable(foo ${QT_QTCORE_LIBRARIES} ${QT_QTTEST_LIBRARIES})
Do you mean the appearance of -DQT_GUI_LIB during foo's compilation
although the latter doesn't need it? If so, this is a, say, inverse
version of what I had in mind: An unnecessary -D, possibly enabling
undesired code in headers during the compilation. If not, could you
explain it once more in another way? ;-)
Actually, my general consideration in this regard is: There might be
quite subtle relations among a package's components, beyond the usual
B-needs-A one. Find modules and config files suit perfectly to handle
such relations, but in order to do this, they must be supplied with
sufficient information. So, all components going to be used together
should be requested together, and if one wants to use a different set
of components, one should request them with a separate FIND_PACKAGE()
call. In this way, a find module / config file is equipped to provide
optimal results, i.e. the exact settings to enable the requested set
of components - no more, no less. In fact, settings like QT_GUI_LIB
made me reason about this issue for the first time, though I still
do not know a real-life example for a -D which is related solely
to a combination of components, or anything else of that kind.
Referring to Qt5_XYZ_FOUND alone is not reliable because this variable
wouldn't have received a definite value if Qt5Config.cmake hasn't been
found by FIND_PACKAGE().
I don't actually see the problem with checking Qt5_XYZ_FOUND. Unset
variables are well defined as false in the if() command. Maybe I
misunderstand you?
Maybe. ;-) What ensures the variables had already been unset before
FIND_PACKAGE() was invoked? If they had evaluated as TRUE - for what-
ever reason - and FIND_PACKAGE() fails to load Qt5Config.cmake, they
will still be TRUE afterwards although Qt5 has not been found at all.
IMO, if FIND_PACKAGE() fails to locate a package, one shouldn't rely
on the assumption that any variable except *_FOUND has a reasonable
value. Thus, in order to play safe, one should access the variables
only after checking the package's successful detection, e.g. like:
IF(Qt5_FOUND AND Qt5_Xml_FOUND)
This consideration is one of my major objections against the proposal
w.r.t. permitting config files to set *_FOUND by themselves. As it is
suggested, it would result in *_FOUND set to FALSE if just a component
is missing, so one can not use *_FOUND anymore to detect the package's
presence. Instead, one would need to apply other means, e.g. the *_DIR
variable set by FIND_PACKAGE() in config mode, but that doesn't work in
module mode, AFAIK. Anyway, I am afraid this will complicate the usage
of FIND_PACKAGE() and promote the inconsistencies among find modules
and config files.
I.e., the user would refer to this variable's
value before the FIND_PACKAGE() call; probably, that's not expected.
Why would the user refer to Qt5_Xml_FOUND before
find_package(Qt5 REQUIRED Xml)
?
(S)he wouldn't - bad wording of mine. A better one is: The user would
see the value the variable already had when FIND_PACKAGE() was called.
[...] At least, I think
something like qt5_use_package is a better idea anyway.
First of all, I definitely agree to your criticism
Re: [cmake-developers] How to handle package Config.cmake files with dependencies ?
On 02/27/2012 10:05 PM, Brad King wrote: On 2/27/2012 3:37 PM, Michael Wild wrote: On 02/27/2012 09:15 PM, Alexander Neundorf wrote: When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE: // Set a variable marking whether the package was found. std::string foundVar = this-Name; foundVar += _FOUND; This means it is true in all cases that the Config.cmake file has been found (and the version was compatible). The find_package command is acting as a primitive like find_library from the point of view of setting Foo_DIR, and that can be tested directly to see if the config file was found. That leaves room to change the way we set Foo_FOUND. We could add a policy that in NEW behavior unsets Foo_FOUND completely before loading FooConfig. After FooConfig has been loaded it detects whether Foo_FOUND is now defined. If set, use that value. If not set, set it to true as it is now. That will give the FooConfig file a chance to set the result. Some FooConfig.cmake authors might use FPHSA(Foo ... ...) because of its messaging capabilities respecting REQUIRED/QUIET, and rely on FIND_PACKAGE() returning with Foo_FOUND==TRUE even if FPHSA() has set this variable to FALSE. Note that there is still no convention which could deprecate this kind of FPHSA()'s usage in config files. Since the proposed approach will break things in such a case, a policy would actually be necessary, IMO. Regarding Foo_DIR: This suits to determine if FooConfig.cmake has been found, but in module mode, AFAIK, it's set to Foo_DIR-NOTFOUND even if a find module has succeeded. Similarly, Foo_CONFIG is empty in module mode or if FooConfig.cmake hasn't been found. Therefore, my question is still: How can I figure out in a reliable manner that FIND_PACKAGE(Foo ...) has found neither FindFoo.cmake nor FooConfig.cmake? Anyway, I have difficulties to realize the advantages of the proposed approach. What does work better with it? Where is Foo_FOUND = Foo_X_FOUND Foo_Y_FOUND ... superior to the status quo? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] How to handle package Config.cmake files with dependencies ?
On 02/27/2012 09:15 PM, Alexander Neundorf wrote:
Hi,
I think find_package in Config mode might still need some more work.
When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE:
// Set a variable marking whether the package was found.
std::string foundVar = this-Name;
foundVar += _FOUND;
This means it is true in all cases that the Config.cmake file has been found
(and the version was compatible).
Now I have to questions:
* how to handle COMPONENTS ?
If a package is requested with COMPONENTS, these should be considered for
setting Foo_FOUND:
find_package(Foo REQUIRED COMPONENTS A B C)
should only succeed if A, B and C are found.
This is how I would expect COMPONENTS to be handled in a FindFoo.cmake:
(a) all components are searched by the Find-module, and each per-component
X_Y_FOUND is set accordingly
(b) there is a package-specific default subset of these components which have
to be found to make the package found, i.e. FOO_FOUND=TRUE
(c) by adding COMPONENTS to the find_package() call, these components are
added to the set of components which have to be found to make FOO_FOUND=TRUE
(d) if REQUIRED is used and FOO_FOUND is false, it errors out
Sorry for chiming in so late, but I haven't got an answer on the
users' mailing list, so I retry here. Some objections and remarks:
(1) Foo might have a non-(de)selectable unnamed core component and
an ordinary selectable component X. FIND_PACKAGE(Foo COMPONENTS X)
returning Foo_FOUND==FALSE and Foo_X_FOUND!=TRUE does not allow to
determine if the core component is available. Potential candidates
for packages like that are Qt, GTK and - most notably - SDL.
(2) FIND_PACKAGE(Foo COMPONENTS ...) returns Foo_FOUND==FALSE if a
config file has not been found - crystal. Who sets the components'
FOUND variables in this case? FIND_PACKAGE() on its own behalf? If
so, note [1] and think of the same uncertainty w.r.t. components:
FIND_PACKAGE() on its own might return with Foo_bar_FOUND whereas
the config file sets Foo_Bar_FOUND. Leaving the components' FOUND
variables untouched? Note [2]. IMO, Brad is absolutely right *not*
to assume that Foo_FOUND was undefined before FIND_PACKAGE() ran.
So, concerning Foo_Bar_FOUND, one should also not rely on that
assumption, but your approach can't guarantee this, AFAICS.
(3) Suppose a component Y is added to Foo in a later release. Run
against such a release, FIND_PACKAGE(Foo COMPONENTS Y) is perfect,
but would face an older FooConfig.cmake with an unknown component
Y. Thus, all components are searched should read all requested
components are searched, the known ones are enabled, and for the
unknown ones, just the respective FOUND variable is set to FALSE.
Personally, my favored approach for {FindFoo,FooConfig}.cmake is:
- Set a FOUND variable for each requested component, known or not.
- Foo_FOUND==FALSE: Foo totally unavailable, don't use it in any
manner. In particular, do not use any further Foo_* variables.
- Foo_FOUND==TRUE: Foo basically available, but no information
about components. Check their availability by the respective
FOUND variable, e.g. IF(Foo_FOUND AND Foo_Bar_FOUND).
For the user, this means:
- Request all components that will be used.
- Use only components that have been requested.
IMO, this approach is robust, versatile and anything but difficult
to implement, and it does not require any change in FIND_PACKAGE().
Regards,
Michael
[1] http://www.mail-archive.com/cmake-developers@cmake.org/msg03036.html
[2] http://www.mail-archive.com/cmake-developers@cmake.org/msg03085.html
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] transitive linking with separate projects
On 03/07/2012 11:29 AM, Alexander Dahl wrote: Hello Michael, Am 2012-03-06 16:46, schrieb Michael Hertling: or possibly better: # libbar/bar-config.cmake.in: FIND_PACKAGE(FOO PATHS @FOO_DIR@ NO_DEFAULT_PATH) I used FIND_PACKAGE(FOO 0.1.0 REQUIRED) in the package config file now, which works, too. Actually, FIND_PACKAGE(FOO PATHS @FOO_DIR@ NO_DEFAULT_PATH) is meant to ensure that bar-config.cmake loads the *same* foo-config.cmake as bar's CMakeLists.txt has before. Possibly, it's even the best to use exactly the same parameters - apart from PATHS and NO_DEFAULT_PATH - i.e., version, components, external variables etc., in order to guarantee that really the same foo-targets.cmake is included. BTW, find modules / config files should provide a *_LIBRARIES variable even if they use imported targets, e.g.: SET(FOO_LIBRARIES foo-shared) I added this. Let me guess, this is for convenience with find rules using the same variables? Yes, in this way, it works with imported targets as well as full paths. PS: The baz project on GitHub only contains a README. I forgot to push this one. Thanks very much, I guess this solves this kind of problem with my packages. :-) See also [1]. Regards, Michael [1] http://public.kitware.com/Bug/view.php?id=12588 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forcibly run 'moc' on Qt files that are NOT part of the build
On 03/07/2012 04:10 PM, Michael Jackson wrote:
In an effort to speed up the build of a project that uses Qt (and moc) I
tried an alternate approach with the moc files. Normally I use the basic idea
of gathering the headers that need to be moc'ed and feed those to moc with
this type of CMake Code:
QT4_WRAP_CPP( FilterWidgets_Generated_MOC_SRCS ${QFilterWidget_HDRS}
${FilterWidget_GEN_HDRS})
The in the Add_Executable(...) call include the
${FilterWidgets_Generated_MOC_SRCS} variable to the list of sources. In my
project I have at least 30 auto-generated files which all get moc'ed. That
gives me an additional 60 compiled files. So I tried the idea of #include
moc_[some_file.cxx] in each of the auto-generated .cpp files for each
Widget. This would cut the number of files compiled in half. The issue is
that since they are being #include'ed in the .cpp files then they do NOT need
to be compiled themselves so I took the ${FilterWidgets_Generated_MOC_SRCS}
out of the list of sources in the add_executable() call. What happened is
that CMake did NOT run moc on those headers because there were now NOT
included in the build.
So for that version of the cmake code I have something like this:
QT4_WRAP_CPP( FilterWidgets_Generated_MOC_SRCS ${FilterWidget_GEN_HDRS})
QT4_WRAP_CPP( FilterWidgets_MOC_SRCS ${QFilterWidget_HDRS} )
Is there a way to forcibly run the moc step even if the resulting source
files are NOT directly included in the add_executable? Custom_Command?
Add_Depends?
AFAIK, the QT4_WRAP_CPP() macro is essentially a wrapper around ADD_
CUSTOM_COMMAND() which accumulates the latter's OUTPUT files in the
former's first parameter. Thus, you might try
QT4_WRAP_CPP(not2compile ...)
ADD_CUSTOM_TARGET(mocem DEPENDS ${not2compile})
ADD_DEPENDENCIES(... mocem)
but I haven't tested this.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] POST_BUILD ALL_BUILD
On 03/06/2012 02:34 AM, Christopher Piekarski wrote: Hello All, I am trying to attach a custom POST_BUILD command to the ALL_BUILD target. I've tried adding the following at the bottom of my root CMakeLists.txt file but the Post Event never shows up in Visual Studio. I have been able to get it to work for sub projects, just not ALL_BUILD. Has anyone gotten this to work? add_custom_command(TARGET ALL_BUILD POST_BUILD COMMAND python27.exe brand.py COMMENT Branding VS debug build ) AFAIK, that's not possible ATM, see also [1]. Instead, you could use a custom target ADD_CUSTOM_TARGET(brand ALL COMMAND python27.exe brand.py COMMENT Branding VS debug build ) ADD_DEPENDENCIES(brand target1 ... targetn) and list your project's targets as prerequisites in order to ensure that brand is built last. For convenience, you might consider to provide wrappers for ADD_LIBRARY() and ADD_EXECUTABLE() which add the respective target to a global property, and use the latter's value for the above-noted ADD_DEPENDENCIES() at the end of your top-level CMakeLists.txt. Regards, Michael [1] http://public.kitware.com/Bug/view.php?id=8438 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] failing target
On 03/06/2012 12:21 PM, Andrea Crotti wrote: On 03/06/2012 07:23 AM, Michael Hertling wrote: On 03/05/2012 05:59 PM, Andrea Crotti wrote: I'm having the following behaviour, and I can't quite understand the error message: .. Built target psi.utility_install .. make[3]: *** No rule to make target `psi.utility_install', needed by `CMakeFiles/install_all_eggs'. Stop. make[2]: *** [CMakeFiles/install_all_eggs.dir/all] Error 2 make[1]: *** [CMakeFiles/unzip_all_eggs.dir/rule] Error 2 make: *** [unzip_all_eggs] Error 2 So first it builds successfully psi.utility_install and then it complains that there are no rules to make it. Who is right then and what could cause such a problem? This is happening on a strange Linux machine, on Windows with MinGW it's working (strangely).. Could you boil down your project to a minimal and self-sufficient example which exhibits this behavior for further investigations? Regards, Michael -- That's quite tricky unfortunately, I hoped that someone saw something similar already and could give me a hint.. Anyway that machine is not a priority at the moment I'll just see later when it's more stable. Could you post the lines which define those targets psi.utility_install and install_all_eggs, or is this quite tricky, too? Do these lines stem from the same CMakeLists.txt? IIRC, the no rule to make... needed by error occurs when there's something wrong with the DEPENDS clause of ADD_CUSTOM_COMMAND/TARGET(). Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] failing target
On 03/06/2012 02:47 PM, Andrea Crotti wrote:
On 03/06/2012 01:45 PM, Michael Hertling wrote:
Could you post the lines which define those targets psi.utility_install
and install_all_eggs, or is this quite tricky, too? Do these lines stem
from the same CMakeLists.txt? IIRC, the no rule to make... needed by
error occurs when there's something wrong with the DEPENDS clause of
ADD_CUSTOM_COMMAND/TARGET().
Regards,
Michael
Well I think it's something related to the platform, because both on my
Linux
box and windows it works perfectly.
This is the interesting part anyway:
foreach(egg ${egg_list})
#TODO: now I need to replace the name with only the last part of the path
get_filename_component(egg_name ${egg} NAME)
set(egg_install ${egg_name}_install)
# generate the list of targets to create more easily dependencies
list(APPEND egg_install_list ${egg_install})
add_custom_target(${egg_install}
COMMAND ${PYTHON_EXECUTABLE} setup.py -q bdist_egg -d
${EGG_BUILD_DIRECTORY}
WORKING_DIRECTORY ${egg}
)
endforeach()
add_custom_target(install_all_eggs
DEPENDS ${egg_install_list}
)
#TODO: add this target to the dependencies of run and packing if it works
add_custom_target(unzip_all_eggs
# unzip the eggs and clean up the zips
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${EGG_BUILD_DIRECTORY}
${EGG_UNZIPPED_DIRECTORY}
# copy the two run files in the final destination
COMMAND ${CMAKE_COMMAND} -E copy ${EGG_BUILD_DIRECTORY}/${RUNNER}
${EGG_UNZIPPED_DIRECTORY}/${RUNNER}
COMMAND ${CMAKE_COMMAND} -E copy ${EGG_BUILD_DIRECTORY}/${C_RUNNER}
${EGG_UNZIPPED_DIRECTORY}/${C_RUNNER}
DEPENDS install_all_eggs
)
sdo the targets are generated at cmake-time reading from a file and then
there are few more targets that depend on
all of them.
Is there anything wrong in this part?
Yes, the DEPENDS clause of ADD_CUSTOM_TARGET() is only for *file*
dependencies, but you use it for *target* dependencies. According
to the documentation of ADD_CUSTOM_TARGET():
Dependencies listed with the DEPENDS argument may reference files
and outputs of custom commands created with add_custom_command()
in the same directory (CMakeLists.txt file).
Use ADD_DEPENDENCIES to add dependencies to or from other targets.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] transitive linking with separate projects
On 03/06/2012 02:47 PM, Alexander Dahl wrote:
Hei hei,
we faced a build problem with transitive linking of separate projects
where I can't find the right solution on my own. I hope someone can give
me a hint. I prepared a test case with two libraries libfoo and libbar
and an application baz. libfoo is on his own, libbar calls a function
from libfoo and baz calls the function from libbar calling libfoo. So
the dependencies are like this:
baz - libbar - libfoo
baz doesn't need to know of libfoo because it just calls libbar, so I
thought.
Now the projects are separated and both libraries come with cmake
package configuration files. For linking libfoo in libbar I do the
following:
find_package(FOO)
target_link_libraries(BAR_SRC foo-shared)
foo-shared is the target libfoo exports via cmake package
configuration. This works and ldd shows libbar is correctly linked
against libfoo.
Now when compiling baz I more or less do the same:
find_package(BAR)
target_link_libraries(BAZ_SRC bar-shared)
However building baz fails with the following error:
% make
[100%] Building C object src/CMakeFiles/baz.dir/baz.c.o
Linking C executable baz
/usr/bin/ld: cannot find -lfoo-shared
collect2: ld returned 1 exit status
make[2]: *** [src/baz] Fehler 1
make[1]: *** [src/CMakeFiles/baz.dir/all] Fehler 2
make: *** [all] Fehler 2
It seems like cmake tries to link against libfoo here but does not know
anything about it. If I add find_package(FOO) to baz obviously the
target is imported from libfoo cmake package files. The question is, if
I know nothing about the requirements of libbar and want to avoid adding
find_package statements for those requirements to baz, how would I do
this?
I put all the code on GitHub, so if someone maybe could have a look?
https://github.com/LeSpocky/libfoo
https://github.com/LeSpocky/libbar
https://github.com/LeSpocky/baz
Greets
Alex
If you run grep foo -r libbar-install-dir/lib/cmake/bar, you will
see only one line which informs the user of bar-config.cmake that the
bar-shared target has a prerequisite name foo-shared, but there is no
more information. For this reason, it's passed as -lfoo-shared to the
linker. You need to include foo-targets.cmake in bar-config.cmake in
order to make the necessary information available, e.g. by
# libbar/bar-config.cmake.in:
INCLUDE(@FOO_CONFIG@)
get_filename_component(_dir ${CMAKE_CURRENT_LIST_FILE} PATH)
get_filename_component(_prefix ${_dir}/../../.. ABSOLUTE)
include(${_dir}/@PROJECT_NAME@-targets.cmake)
set(BAR_INCLUDE_DIRS ${_prefix}/include/@PROJECT_NAME@)
or possibly better:
# libbar/bar-config.cmake.in:
FIND_PACKAGE(FOO PATHS @FOO_DIR@ NO_DEFAULT_PATH)
get_filename_component(_dir ${CMAKE_CURRENT_LIST_FILE} PATH)
get_filename_component(_prefix ${_dir}/../../.. ABSOLUTE)
include(${_dir}/@PROJECT_NAME@-targets.cmake)
set(BAR_INCLUDE_DIRS ${_prefix}/include/@PROJECT_NAME@)
This will make the user of bar-config.cmake include the same foo-
config.cmake and, thus, foo-targets.cmake that bar's CMakeLists.txt
has included, too. See also FIND_PACKAGE()'s NAMES / CONFIGS clauses.
BTW, find modules / config files should provide a *_LIBRARIES variable
even if they use imported targets, e.g.: SET(FOO_LIBRARIES foo-shared)
Regards,
Michael
PS: The baz project on GitHub only contains a README.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question regarding source tree structure and how to find libraries easily within that structure
On 03/04/2012 11:01 AM, Andreas Guther wrote:
Hello,
thanks for the responses. The problem I have is, that we have more than one
application in the directory. So if I put an CMakeLists.txt in the Src
directory I do not have the choice (only by options). I would prefer a
solution where I change into the application directory I want to build and
create workspace etc. from there. The created workspace should then also
build all necessary libraries for the application.
Any ideas on this?
In Application_1/CMakeLists.txt, e.g., do:
SET(Library_1_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../Library_1
CACHE PATH Library_1 source directory)
...
ADD_SUBDIRECTORY(${Library_1_SOURCE_DIR} Library_1)
Do the same for Library_2 and every other prerequisite project which
- has a source tree external to Application_1
- you want to be built along with the latter
and finally: TARGET_LINK_LIBRARIES(Application_1 Library_1 ...)
If the fallback value of Library_1_SOURCE_DIR once doesn't suit, you
can set it on the command line or in the GUI before (re)configuring.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Functions inherit parent variables?
On 03/05/2012 10:43 AM, Johannes Zarl wrote:
On Saturday 03 March 2012, 02:29:05, Robert Dailey wrote:
Well you're really comparing apples to oranges. C++ nested scoping rules
really have nothing to do with two separate functions sharing scoped
variables. It doesn't even really serve as a good analogy, so I can't be
100% certain what you were trying to tell me ;-)
However I appreciate your response. I really just wanted to make sure this
isn't a bug, because the way the called function inherits the calling
function's local variables is an unusual behavior for a language, at least
in my experience. So I had to think twice about it ;)
As Michael said: This behaviour is not at all unusual for scripting
languages,
but there is not really a One True Way: In Tcl you have to import variables
explicitly, in bourne shell you overwrite values in the parent scope, ...
It's just a property of the language that you have to know about.
So in the CMake language you should be aware that the parent scope is visible
inside a function, but the function does not affect the parent scope unless
explicitly stated:
function( test1 )
set( var_a var_a inner1 )
message( test1(): var_a: ${var_a} )
endfunction()
function( test2 )
set( var_a var_a inner2 PARENT_SCOPE )
message( test2(): var_a: ${var_a} )
endfunction()
set( var_a var_a outer )
test1()
message( var_a: ${var_a} )
test2()
message( var_a: ${var_a} )
--- Output:
test1(): var_a: var_a inner1
var_a: var_a outer
test2(): var_a: var_a outer
var_a: var_a inner2
Disclaimer: Actually, this was surprising to me. I was thinking that
PARENT_SCOPE sets the value in the current scope plus the parent scope, not
in
the parent scope only. I guess this could be stated in the documentation more
clearly...
IMO, the documentation of the PARENT_SCOPE flag is sufficiently clear:
If PARENT_SCOPE is present, the variable will be set in the scope
*above* the current scope. Each new directory or function creates
a new scope. This command will set the value of a variable into
the *parent* directory or *calling* function (whichever is
applicable to the case at hand).
Not a word about setting anything in the current scope, and as for
me, the explanation of CACHE/INTERNAL/FORCE, e.g., is rather vague.
Anyway, an additional remark on this thread's topic: CMake's functions
know neither return values nor pointers or references to variables, so
this kind of access from the callee to the caller's scope is the only
mechanism to transfer data from the the former to the latter, except
for properties and global variables which are often less convenient.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] failing target
On 03/05/2012 05:59 PM, Andrea Crotti wrote: I'm having the following behaviour, and I can't quite understand the error message: .. Built target psi.utility_install .. make[3]: *** No rule to make target `psi.utility_install', needed by `CMakeFiles/install_all_eggs'. Stop. make[2]: *** [CMakeFiles/install_all_eggs.dir/all] Error 2 make[1]: *** [CMakeFiles/unzip_all_eggs.dir/rule] Error 2 make: *** [unzip_all_eggs] Error 2 So first it builds successfully psi.utility_install and then it complains that there are no rules to make it. Who is right then and what could cause such a problem? This is happening on a strange Linux machine, on Windows with MinGW it's working (strangely).. Could you boil down your project to a minimal and self-sufficient example which exhibits this behavior for further investigations? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] avoid rebuilding targets depending on generated source files
On 03/04/2012 01:06 AM, Ajay Panyala wrote:
Please provide a minimal but complete example for this issue.
Please find it in the following link
http://pastie.org/private/pd13u33s9xpfihf2dbzc1q
The following project is a boiled-down version of yours but doesn't
need any programs except for CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(GrammarSource ${PROJECT_BINARY_DIR}/src)
FILE(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/src)
ADD_CUSTOM_TARGET(GrammarBuild ALL
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${PROJECT_BINARY_DIR}/test.tokens
)
ADD_CUSTOM_COMMAND(TARGET GrammarBuild POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.h
${PROJECT_BINARY_DIR}/parser/testLexer.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.c
${PROJECT_BINARY_DIR}/parser/testLexer.c
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testParser.h
${PROJECT_BINARY_DIR}/parser/testParser.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testParser.c
${PROJECT_BINARY_DIR}/parser/testParser.c
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${PROJECT_BINARY_DIR}/test.tokens
${PROJECT_BINARY_DIR}/parser/test.tokens
)
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your example
handles five files - is not copied *although* the source file and the
destination file are different, i.e. similar but not equal?
You wrote further:
[...] The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Does this mean that source files are copied *although* they are equal
to their respective destination file? How do you determine that they
have been copied? Do you check the timestamps? With --full-time?
Regards,
Michael
PS: Does org.antlr.Tool write to the source tree? If so: Don't do that.
On Sat, Mar 3, 2012 at 3:54 PM, Michael Hertling mhertl...@online.dewrote:
On 03/04/2012 12:14 AM, Ajay Panyala wrote:
No, it wouldn't; check it out:
% touch a
% rm -f b
% ls b
ls: cannot access b: No such file or directory
% cmake -E copy_if_different a b
% ls b
b
% cksum a b
4294967295 0 a
4294967295 0 b
It works with one file, but I have 4 files that are generated.
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Any idea what might be happening here ?
Please provide a minimal but complete example for this issue.
Regards,
Michael
On Sat, Mar 3, 2012 at 2:47 PM, Michael Hertling mhertl...@online.de
wrote:
On 03/03/2012 10:36 PM, Ajay Panyala wrote:
Try cmake -E copy_if_different ...
cmake -E copy_if_different build/test1.c build/tests/test1.c
That would work when make is run atleast once.
When running make for the 1st time test1.c was never
copied to build/tests before. So I would be comparing a file with
another non-existant file and that would result in an error halting
the make process.
No, it wouldn't; check it out:
% touch a
% rm -f b
% ls b
ls: cannot access b: No such file or directory
% cmake -E copy_if_different a b
% ls b
b
% cksum a b
4294967295 0 a
4294967295 0 b
Regards,
Michael
On Sat, Mar 3, 2012 at 1:20 PM, Hendrik Sattler
p...@hendrik-sattler.de
wrote:
Am Samstag, 3. März 2012, 21:41:49 schrieb Ajay Panyala:
I have a custom target which runs a command to generate
a C source file say test1.c
ADD_CUSTOM_TARGET(TestGen ALL
COMMAND genExec ${PROJECT_SOURCE_DIR}/Main.java
DEPENDS ${PROJECT_SOURCE_DIR}/Main.java
)
And I have a custom command that moves the generated *test1.c *
to a new directory inside the build directory.
ADD_CUSTOM_COMMAND(
TARGET TestGen
POST_BUILD
COMMAND mv
ARGS ${PROJECT_BINARY_DIR}/test1.c ${PROJECT_BINARY_DIR}/tests/
)
Each time I run make, the custom
Re: [CMake] avoid rebuilding targets depending on generated source files
On 03/04/2012 08:02 PM, Ajay Panyala wrote:
The following project is a boiled-down version of yours but doesn't
need any programs except for CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
I am sorry. I was mainly trying to cleanup the big CMakeLists file
I had and removed about 10 different targets - all of which were
rebuilt because the 5 files (test*.*) were overwritten.
If you want to try running the test project on your system
test.g is at http://pastie.org/private/agzor3ibzoa5pom6q31qq
org.antlr.Tool is at www.antlr.org/download/antlr-3.4-complete.jar
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
It does not work. The files are still overwritten.
Could you run the following shell script in a build tree configured
with the CMakeLists.txt from my previous reply and post the output?
# check.sh:
make X=0 21 /dev/null
echo After make X=0 (1):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=0 21 /dev/null
echo After make X=0 (2):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=1 21 /dev/null
echo After make X=1:
echo ---
echo
ls --full-time test.tokens src parser
# End of check.sh
BTW, which CMake version do you use?
Regards,
Michael
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your example
handles five files - is not copied *although* the source file and the
destination file are different, i.e. similar but not equal?
Yes the file test.tokens is not copied overwritten since they are
exactly (diff) similar files. This is the case with the other 4 files as
well,
but they are still copied over and rewritten.
You wrote further:
[...] The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Does this mean that source files are copied *although* they are equal
to their respective destination file? How do you determine that they
have been copied? Do you check the timestamps? With --full-time?
Yes, I do check with ls -l --full-time. Except test.tokens, all the other
files
are copied over (rewritten) even though they are exactly the same (diff
same I mean).
This is what is confusing me about the behavior of copy_if_different.
that is why it works only with test.tokens and not others.
PS: Does org.antlr.Tool write to the source tree? If so: Don't do that.
Yes, it generates the files in the source dir itself (where test.g is
present)
I now modified CMakeLists to copy test.g to the project build folder and
run it there. The new CMakeLists is at
http://pastie.org/private/p1yi0l8so9cqimqlywfmhw
Thank You
Ajay
On Sun, Mar 4, 2012 at 12:52 AM, Michael Hertling mhertl...@online.dewrote:
On 03/04/2012 01:06 AM, Ajay Panyala wrote:
Please provide a minimal but complete example for this issue.
Please find it in the following link
http://pastie.org/private/pd13u33s9xpfihf2dbzc1q
The following project is a boiled-down version of yours but doesn't
need any programs except for CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(GrammarSource ${PROJECT_BINARY_DIR}/src)
FILE(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/src)
ADD_CUSTOM_TARGET(GrammarBuild ALL
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testLexer.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.h
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${GrammarSource}/testParser.c
COMMAND ${CMAKE_COMMAND} -E echo \${X}
${PROJECT_BINARY_DIR}/test.tokens
)
ADD_CUSTOM_COMMAND(TARGET GrammarBuild POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.h
${PROJECT_BINARY_DIR}/parser/testLexer.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testLexer.c
${PROJECT_BINARY_DIR}/parser/testLexer.c
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${GrammarSource}/testParser.h
Re: [CMake] avoid rebuilding targets depending on generated source files
On 03/05/2012 01:59 AM, Ajay Panyala wrote:
I use cmake version 2.8.3.
If I use CMakeLists from your previous reply, it avoids overwriting files
when X=0.
I have attached the output of your script.
Actually, this is exactly what I was talking about: The second make
X=0 invocation rewrites the source files - i.e., they receive a new
timestamp - but their contents do not change. Thus, the destination
files in the parser directory are *not* touched by the second make
X=0, and this can be seen clearly by reference to the timestamps.
It's the subsequent make X=1 which provides for a new content of
the source files and makes cmake -E copy_if_different copy the
sources to the destinations. That's why I said everything works
as expected, but you wrote:
It does not work. The files are still overwritten.
So, my question again: What exactly does not work?
I.e., does cmake -E copy_if_different
- copy a file although the destination exists
and has the same content as the source, or
- not copy a file although the destination does not
exist or does not have the same content as the source?
It works for my CMakeLists as well now. What I did now is
if(${GrammarSource}/test.g IS_NEWER_THAN ${PROJECT_BINARY_DIR}/test.g)
ADD_CUSTOM_TARGET(...)
ADD_CUSTOM_COMMAND(...)
i.e I am totally avoiding the process of rebuilding the test.g file and
copying the generated files to build/parser
*IF* test.g has not been modified.
...and if test.g is once modified, you won't have a custom target which
regenerates the source files and copies them to the parser directory -
I'm pretty sure this is not what you intend. Recall the difference
between configuration time and build time in CMakified projects.
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
Sorry. I did not realize that. I use gmail and when I checked my sent
emails,
quoted text appears to be clearly marked. Is the quoted text in this email
marked properly.
Yes, it is.
Regards,
Michael
On Sun, Mar 4, 2012 at 4:05 PM, Michael Hertling mhertl...@online.dewrote:
On 03/04/2012 08:02 PM, Ajay Panyala wrote:
The following project is a boiled-down version of yours but doesn't
need any programs except for CMake - that's what I actually meant
with minimal but complete as I don't have the org.antlr.Tool
Java program:
I am sorry. I was mainly trying to cleanup the big CMakeLists file
I had and removed about 10 different targets - all of which were
rebuilt because the 5 files (test*.*) were overwritten.
If you want to try running the test project on your system
test.g is at http://pastie.org/private/agzor3ibzoa5pom6q31qq
org.antlr.Tool is at www.antlr.org/download/antlr-3.4-complete.jar
After configuration, you can run the target by make X=0 and check the
timestamps by ls -l --full-time test.tokens parser src. Issuing make
X=0 again reveals that the copied files aren't rewritten as it happens
after make X=1. Thus, AFAICS, everything works as expected. Could you
check if the above-noted example also works on your system?
It does not work. The files are still overwritten.
Could you run the following shell script in a build tree configured
with the CMakeLists.txt from my previous reply and post the output?
# check.sh:
make X=0 21 /dev/null
echo After make X=0 (1):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=0 21 /dev/null
echo After make X=0 (2):
echo ---
echo
ls --full-time test.tokens src parser
echo -ne \n\n
sleep 3
make X=1 21 /dev/null
echo After make X=1:
echo ---
echo
ls --full-time test.tokens src parser
# End of check.sh
BTW, which CMake version do you use?
Regards,
Michael
PS: Could you set up your e-mail client so that it marks quoted
text in some way? Currently, one can't distinguish between
the lines you are writing and the lines written by others.
What exactly does not work with your example? You wrote:
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). [...]
Does this mean that the last file out of four - in fact, your example
handles five files - is not copied *although* the source file and the
destination file are different, i.e. similar but not equal?
Yes the file test.tokens is not copied overwritten since they are
exactly (diff) similar files. This is the case with the other 4 files as
well,
but they are still copied over and rewritten.
You wrote further:
[...] The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Does this mean that source files are copied *although* they are equal
to their respective destination file? How do you determine that they
have been copied? Do you check the timestamps? With --full-time
Re: [CMake] avoid rebuilding targets depending on generated source files
On 03/03/2012 10:36 PM, Ajay Panyala wrote:
Try cmake -E copy_if_different ...
cmake -E copy_if_different build/test1.c build/tests/test1.c
That would work when make is run atleast once.
When running make for the 1st time test1.c was never
copied to build/tests before. So I would be comparing a file with
another non-existant file and that would result in an error halting
the make process.
No, it wouldn't; check it out:
% touch a
% rm -f b
% ls b
ls: cannot access b: No such file or directory
% cmake -E copy_if_different a b
% ls b
b
% cksum a b
4294967295 0 a
4294967295 0 b
Regards,
Michael
On Sat, Mar 3, 2012 at 1:20 PM, Hendrik Sattler
p...@hendrik-sattler.dewrote:
Am Samstag, 3. März 2012, 21:41:49 schrieb Ajay Panyala:
I have a custom target which runs a command to generate
a C source file say test1.c
ADD_CUSTOM_TARGET(TestGen ALL
COMMAND genExec ${PROJECT_SOURCE_DIR}/Main.java
DEPENDS ${PROJECT_SOURCE_DIR}/Main.java
)
And I have a custom command that moves the generated *test1.c *
to a new directory inside the build directory.
ADD_CUSTOM_COMMAND(
TARGET TestGen
POST_BUILD
COMMAND mv
ARGS ${PROJECT_BINARY_DIR}/test1.c ${PROJECT_BINARY_DIR}/tests/
)
Each time I run make, the custom target is run (since custom targets are
always
out-of-date). But I want to avoid moving the new test1.c generated each
time if build/test1.c is the same as build/tests/test1.c since there are
other targets
like add_executable and add_library later in the CMakelists file that are
re-built
each time since they depend on test1.c
Try cmake -E copy_if_different ...
HS
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problems with CMake and static Qt plugins
On 03/02/2012 02:48 PM, NoRulez wrote:
Hello,
I use Qt 4.8.0 from the QtSDK and Iwant to generate a static qt plugin.
In my main.cpp I have the following:
#includeQApplication
#includeQtPlugin
Q_IMPORT_PLUGIN(Local)
intmain(intargc,char*argv[]){
QApplicationapp(argc,argv);
.
.
.
return app.exec();
}
The corresponding CMakeLists.txt for the LocalPlugin looks like the following:
SET(LOCALPLUGIN_HEADERS
LocalPlugin.h
)
SET(LOCALPLUGIN_SOURCES
LocalPlugin.cpp
)
SET(QT_USE_QTGUITRUE)
SET(QT_USE_QTPLUGINTRUE)
QT4_AUTOMOC(${LOCALPLUGIN_SOURCES})
QT4_WRAP_CPP(LOCALPLUGIN_MOC${LOCALPLUGIN_HEADERS})
ADD_LIBRARY(Local STATIC ${LOCALPLUGIN_HEADERS} ${LOCALPLUGIN_SOURCES}
${LOCALPLUGIN_MOC})
TARGET_LINK_LIBRARIES(Local ${QT_LIBRARIES})
The corresponding CMakeLists.txt for the main app looks like the following:
SET(QT_USE_QTMAINTRUE)
SET(QT_USE_QTGUI TRUE)
ADD_EXECUTABLE(MyApp WIN32 ${APP_SOURCES} ${APP_RCC} MyApp.rc)
TARGET_LINK_LIBRARIES(MyAppLocal ${QT_LIBRARIES})
When I compile it I get the following error:
In function `StaticLocalPluginInstance': undefined reference to
`qt_plugin_instance_Local()'
Please, could anybody help me to get it working?
Did you INCLUDE(${QT_USE_FILE}) in the correct place, i.e. after
setting the QT_USE_QT* variables? QT_LIBRARIES is populated in
that file.
Moreover, the lines
SET(QT_USE_QTGUITRUE)
SET(QT_USE_QTMAINTRUE)
SET(QT_USE_QTPLUGINTRUE)
QT4_WRAP_CPP(LOCALPLUGIN_MOC${LOCALPLUGIN_HEADERS})
are obviously missing blanks - just typos in your report?
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] avoid rebuilding targets depending on generated source files
On 03/04/2012 12:14 AM, Ajay Panyala wrote:
No, it wouldn't; check it out:
% touch a
% rm -f b
% ls b
ls: cannot access b: No such file or directory
% cmake -E copy_if_different a b
% ls b
b
% cksum a b
4294967295 0 a
4294967295 0 b
It works with one file, but I have 4 files that are generated.
I have 4 cmake -E copy_if_different commands, one for each file.
Only the last file is not copied (if similar). The others are copied
even if they are the same.
I verfied that they are the same with a diff.
Any idea what might be happening here ?
Please provide a minimal but complete example for this issue.
Regards,
Michael
On Sat, Mar 3, 2012 at 2:47 PM, Michael Hertling mhertl...@online.dewrote:
On 03/03/2012 10:36 PM, Ajay Panyala wrote:
Try cmake -E copy_if_different ...
cmake -E copy_if_different build/test1.c build/tests/test1.c
That would work when make is run atleast once.
When running make for the 1st time test1.c was never
copied to build/tests before. So I would be comparing a file with
another non-existant file and that would result in an error halting
the make process.
No, it wouldn't; check it out:
% touch a
% rm -f b
% ls b
ls: cannot access b: No such file or directory
% cmake -E copy_if_different a b
% ls b
b
% cksum a b
4294967295 0 a
4294967295 0 b
Regards,
Michael
On Sat, Mar 3, 2012 at 1:20 PM, Hendrik Sattler p...@hendrik-sattler.de
wrote:
Am Samstag, 3. März 2012, 21:41:49 schrieb Ajay Panyala:
I have a custom target which runs a command to generate
a C source file say test1.c
ADD_CUSTOM_TARGET(TestGen ALL
COMMAND genExec ${PROJECT_SOURCE_DIR}/Main.java
DEPENDS ${PROJECT_SOURCE_DIR}/Main.java
)
And I have a custom command that moves the generated *test1.c *
to a new directory inside the build directory.
ADD_CUSTOM_COMMAND(
TARGET TestGen
POST_BUILD
COMMAND mv
ARGS ${PROJECT_BINARY_DIR}/test1.c ${PROJECT_BINARY_DIR}/tests/
)
Each time I run make, the custom target is run (since custom targets
are
always
out-of-date). But I want to avoid moving the new test1.c generated each
time if build/test1.c is the same as build/tests/test1.c since there
are
other targets
like add_executable and add_library later in the CMakelists file that
are
re-built
each time since they depend on test1.c
Try cmake -E copy_if_different ...
HS
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Transitive library dependencies with parallel builds
On 02/29/2012 05:35 PM, Number Cruncher wrote:
Do transitive dependencies reduce number of jobs that can be compiled in
parallel?
If I have two libraries A and B, with an executable C, whose
dependencies are described by:
add_library(A ${A_SRC})
add_library(B ${B_SRC})
target_link_libraries(B A)
add_executable(C ${C_SRC})
target_link_libraries(C B)
I understand that when *linking* C, the transitive dependency A will be
added. However, if I build C in parallel make -j N, will CMake build
libraries A and B simultaneously, or fully compile and link A before
starting compilation of B? I.e. just because the link steps are serial
dependencies, are the compilation steps? Would it be faster to do:
add_library(A ${A_SRC})
add_library(B ${B_SRC})
add_executable(C ${C_SRC})
target_link_libraries(C B A)
Thanks.
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c void a(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){a();}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c int main(void){b(); return 0;}\n)
ADD_LIBRARY(A SHARED a.c)
ADD_LIBRARY(B SHARED b.c)
ADD_EXECUTABLE(C c.c)
IF(TRANSITIVE)
TARGET_LINK_LIBRARIES(B A)
TARGET_LINK_LIBRARIES(C B)
ELSE()
TARGET_LINK_LIBRARIES(C B A)
ENDIF()
Configure with -DTRANSITIVE=ON and inspect CMakeFiles/Makefile2:
CMakeFiles/A.dir/all:
CMakeFiles/B.dir/all: CMakeFiles/A.dir/all
CMakeFiles/C.dir/all: CMakeFiles/B.dir/all
With -DTRANSITIVE=OFF, these lines read:
CMakeFiles/A.dir/all:
CMakeFiles/B.dir/all:
CMakeFiles/C.dir/all: CMakeFiles/A.dir/all
CMakeFiles/C.dir/all: CMakeFiles/B.dir/all
The CMakeFiles/X.dir/all targets do:
$(MAKE) -f CMakeFiles/X.dir/build.make CMakeFiles/X.dir/build
Finally, CMakeFiles/X.dir/build in CMakeFiles/X.dir/build.make
does build target X completely, i.e. including the linking step.
Thus, the two-part transitive linking with -DTRANSITIVE=ON indeed
completes A before addressing B, so A and B can not be compiled in
parallel. In contrast, the one-part non-transitive linking with -D
TRANSITIVE=OFF allows for A and B to be compiled and even linked in
parallel since they haven't any interdependencies. So, with -j, the
latter is potentially faster than the former, but...
...reconsider what you're about to do: If B actually references A,
you might possibly not want to drop the TARGET_LINK_LIBRARIES(B A)
command. Run readelf -d libB.so on both results for -DTRANSITIVE
and you will see the difference. If A and B were static libraries,
CMake would lose the awareness that B must pull in A in the linker
command line.
In short, the answers to your questions are: N/Y, Y and Y.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Functions inherit parent variables?
On 03/01/2012 06:01 PM, Robert Dailey wrote:
No, the print statement is not missing. In fact it prints just fine
(function test() is able to obtain the value for variable SOME_TEST).
I meant the output SOME_TEST: HELLO WORLD was missing in your report.
This isn't exactly the same as C++. In C++, a function does not have access
to the calling function's local declarations. In order for the function to
get access to these, they must be passed in as parameters.
There wasn't talk of functions but of the { and } tokens:
#include stdio.h
int main(void)
{
int outer = 1;
{
int inner = 2;
printf(outer=%d, inner=%d\n,outer,inner);
}
return 0;
}
As you will see, there's access to the outer scope from the inner one.
However, to be more precise, C/C++'s scoping is static, i.e. it's in
effect at compilation time only, and - in contrast to Pascal, e.g. -
the ISO dialects don't allow a nested definition of functions, so a
function's scope isn't part of another function's one. Therefore, a
called function can't see the variables of the calling function as
their scopes aren't descendants but siblings.
Interpreted languages like CMake's one often have dynamic scoping,
i.e. an invocation of a function creates a new scope - capable to
hold variables - and pushes it on a stack from where it is popped
and destroyed when the function terminates. When dereferencing a
variable, it is searched by traversing the stacked scopes from
inner to outer until it is found. Therefore, a called function
can see the calling function's variables since the latter's
scope is accessible from the former's one.
Maybe, it was a rather bad idea to compare C/C++'s static
block scoping with CMake's dynamic function scoping.
Sorry about that.
Regards,
Michael
On Wed, Feb 29, 2012 at 9:54 PM, Michael Hertling mhertl...@online.dewrote:
On 03/01/2012 01:38 AM, Robert Dailey wrote:
I ran a quick test:
function( test )
message( SOME_TEST: ${SOME_TEST} )
endfunction()
function( start )
set( SOME_TEST HELLO WORLD )
test()
endfunction()
start()
Seems like a function has access to the calling scope's defined
variables.
I thought because functions created a new scope, that excluded access to
variables defined in the outer scope (i.e. calling scope)
Can someone explain?
The line SOME_TEST: HELLO WORLD is missing, I guess?
As usual with scoping mechanisms, there is access to the outer scope
from within the inner scope: Read access via ordinary dereferencing
and write access via PARENT_SCOPE. It's quite the same as in C/C++
with the { and } tokens; see also the C++ :: operator.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Functions inherit parent variables?
On 03/03/2012 02:29 AM, Robert Dailey wrote:
Well you're really comparing apples to oranges. C++ nested scoping rules
really have nothing to do with two separate functions sharing scoped
variables. It doesn't even really serve as a good analogy, so I can't be
100% certain what you were trying to tell me ;-)
What I actually intended to express is that
(1) C/C++'s static block scoping has the same effect as CMake's dynamic
function scoping *insofar* that the inner scope has access to the
outer scope - as usual - and
(2) in C/C++, a function can't see a calling function's variables for
the reason alone that they don't have nested scopes, but the fact
that caller and callee don't have nested static scopes in C/C++
doesn't mean that they don't have nested dynamic ones in CMake.
Probably, as I said before, a quite silly idea...
However I appreciate your response. I really just wanted to make sure this
isn't a bug, because the way the called function inherits the calling
function's local variables is an unusual behavior for a language, at least
in my experience. So I had to think twice about it ;)
AFAIK, it's unusual for languages knowing nested functions, but
CMake doesn't know them. Among the nested-knowing ones, e.g.,
Python can do
def outer():
value = 123
print outer:,value
def inner(): print inner:,value
inner()
value = 321
outer()
outer()
whereas Perl 5 can do it only once (will not stay shared)
use warnings;
use strict;
sub outer {
my $value;
$value = 123;
print outer: $value\n;
sub inner { print inner: $value\n; }
inner();
$value = 321;
}
outer();
outer();
but Perl 6, in turn, is said to do it like Python.
We're getting off-topic, I guess.
Regards,
Michael
On Fri, Mar 2, 2012 at 6:53 PM, Michael Hertling mhertl...@online.dewrote:
On 03/01/2012 06:01 PM, Robert Dailey wrote:
No, the print statement is not missing. In fact it prints just fine
(function test() is able to obtain the value for variable SOME_TEST).
I meant the output SOME_TEST: HELLO WORLD was missing in your report.
This isn't exactly the same as C++. In C++, a function does not have
access
to the calling function's local declarations. In order for the function
to
get access to these, they must be passed in as parameters.
There wasn't talk of functions but of the { and } tokens:
#include stdio.h
int main(void)
{
int outer = 1;
{
int inner = 2;
printf(outer=%d, inner=%d\n,outer,inner);
}
return 0;
}
As you will see, there's access to the outer scope from the inner one.
However, to be more precise, C/C++'s scoping is static, i.e. it's in
effect at compilation time only, and - in contrast to Pascal, e.g. -
the ISO dialects don't allow a nested definition of functions, so a
function's scope isn't part of another function's one. Therefore, a
called function can't see the variables of the calling function as
their scopes aren't descendants but siblings.
Interpreted languages like CMake's one often have dynamic scoping,
i.e. an invocation of a function creates a new scope - capable to
hold variables - and pushes it on a stack from where it is popped
and destroyed when the function terminates. When dereferencing a
variable, it is searched by traversing the stacked scopes from
inner to outer until it is found. Therefore, a called function
can see the calling function's variables since the latter's
scope is accessible from the former's one.
Maybe, it was a rather bad idea to compare C/C++'s static
block scoping with CMake's dynamic function scoping.
Sorry about that.
Regards,
Michael
On Wed, Feb 29, 2012 at 9:54 PM, Michael Hertling mhertl...@online.de
wrote:
On 03/01/2012 01:38 AM, Robert Dailey wrote:
I ran a quick test:
function( test )
message( SOME_TEST: ${SOME_TEST} )
endfunction()
function( start )
set( SOME_TEST HELLO WORLD )
test()
endfunction()
start()
Seems like a function has access to the calling scope's defined
variables.
I thought because functions created a new scope, that excluded access
to
variables defined in the outer scope (i.e. calling scope)
Can someone explain?
The line SOME_TEST: HELLO WORLD is missing, I guess?
As usual with scoping mechanisms, there is access to the outer scope
from within the inner scope: Read access via ordinary dereferencing
and write access via PARENT_SCOPE. It's quite the same as in C/C++
with the { and } tokens; see also the C++ :: operator.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
On 03/01/2012 10:08 PM, Alexander Neundorf wrote:
On Thursday 01 March 2012, Michael Hertling wrote:
On 02/28/2012 10:03 PM, Alexander Neundorf wrote:
...will reply later in detail.
Could you please go through the existing find-modules shipped with cmake
which support COMPONENTS and make a summary of how they handle them ?
At least FindQt4.cmake be default searches all components.
Thanks
Alex
The following CMakeLists.txt can be used to systematically investigate
the results of the component-aware find modules currently shipped with
CMake, these are Find{Boost,GTK2,HDF5,ImageMagick,Java,OpenSceneGraph,
Qt4,wxWidgets,XMLRPC}:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(FINDRESULTVARIABLES C CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FUNCTION(FindResultVariables pkg)
SET(prefix ${pkg})
IF(DEFINED ARGV1)
SET(prefix ${ARGV1})
ENDIF()
UNSET(REQUIRED)
IF(${pkg}_REQUIRED)
SET(REQUIRED REQUIRED)
ENDIF()
FIND_PACKAGE(${pkg} COMPONENTS ${${pkg}_COMPONENTS} ${REQUIRED})
MESSAGE(Begin: ${pkg} result variables)
GET_DIRECTORY_PROPERTY(v VARIABLES)
FOREACH(i IN LISTS v)
IF(i MATCHES ^${prefix}.*_FOUND$)
MESSAGE(${i}=${${i}})
ENDIF()
ENDFOREACH()
MESSAGE(${prefix}_LIBRARIES: ${${prefix}_LIBRARIES})
MESSAGE(End: ${pkg} result variables)
ENDFUNCTION()
FindResultVariables(Boost)
FindResultVariables(GTK2)
FindResultVariables(HDF5)
FindResultVariables(ImageMagick)
FindResultVariables(Java)
FindResultVariables(OpenSceneGraph)
FindResultVariables(Qt4 QT)
FindResultVariables(wxWidgets)
FindResultVariables(XMLRPC)
Thanks :-)
HDF5, OpenSceneGraph and XMLRPC aren't installed on my system; my
preliminary findings for the remaining packages are as follows:
Maybe you can have a look at the code of those ?
Perhaps, someone who has these packages already installed can take a
look at them in the meantime and run the above-noted CMakeLists.txt.
Probably, this will provide for faster results.
(1) Searching unrequested components:
Qt4: Yes.
GTK2,ImageMagick: Partially.
wxWidgets: All components if none are requested.
The remaining modules don't search unrequested components.
(2) Assigning *_*_FOUND variables:
Qt4: Only for modules which are known and found.
ImageMagick: Also for requested but unknown components.
wxWidgets: No *_*_FOUND variables at all but forwards unknown
components to *_LIBRARIES variable without an error.
The remaining modules assign only to *_*_FOUND variables for
components which they know and which have been requested.
(3) Respecting the REQUIRED flag:
wxWidgets: REQUIRED ignored completely.
This is clearly a bug.
Boost: SEND_ERROR instead of FATAL_ERROR.
This is somewhere between acceptable and bug.
GTK2,Java: Bail out on unknown components even if not REQUIRED.
Depending on how unknown components should be handled, this is either ok or
not.
I'm leaning towards supporting only known components, so the find-module or
config file knows what it is doing.
In this case this would be correct behaviour, the programmer would see this
error, not the user.
Please recall the use case of Qt5 with config file and a module XYZ
added in a later release. A FIND_PACKAGE(Qt5 COMPONENTS XYZ) against
a later Qt5 installation works flawlessly, but against an early one,
it faces Qt5Config.cmake with an unknown component XYZ, and this is
perfectly legal. How should one use the XYZ module optionally - i.e.
if available - given that Qt5Config.cmake bails out on a missing XYZ
although REQUIRED isn't flagged? IMO, without REQUIRED, config files
/ find modules should handle requested but unknown components grace-
fully by just assigning FALSE to the respective *_*_FOUND variable.
What's your opinion about the above-mentioned use case?
The remaining modules bail out on unavailable requested components.
(4) Assinging the package-related *_FOUND variable:
Java: No *_FOUND variable at all although it's documented.
Bug.
wxWidgets: TRUE even if requested components aren't found, see above.
The remaining modules return FALSE if a requested component isn't found.
My comments on these, say, multifarious findings are:
;-)
Ad.(1): In general, automatically searching unrequested components
does not mean a harm, but it is also not beneficial at all events:
- No guarantee to catch all components - consider a component added
later to the package - so no guarantee that all later *_*_FOUND
variables have been assigned a definite value by FIND_PACKAGE().
- Complicates find modules / config files due to REQUIRED/QUIET.
- Potentially higher costs due to unneeded search operations.
For the latter loint, there is a not-so-uncommon use case: Suppose
a find module wants to check whether a library matches its header.
Putting away cross-compiling issues for the moment, this requires
building and running a test
Re: [CMake] Code and API review request for Qt5 CMake files
On 02/28/2012 10:03 PM, Alexander Neundorf wrote:
...will reply later in detail.
Could you please go through the existing find-modules shipped with cmake
which
support COMPONENTS and make a summary of how they handle them ?
At least FindQt4.cmake be default searches all components.
Thanks
Alex
The following CMakeLists.txt can be used to systematically investigate
the results of the component-aware find modules currently shipped with
CMake, these are Find{Boost,GTK2,HDF5,ImageMagick,Java,OpenSceneGraph,
Qt4,wxWidgets,XMLRPC}:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(FINDRESULTVARIABLES C CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FUNCTION(FindResultVariables pkg)
SET(prefix ${pkg})
IF(DEFINED ARGV1)
SET(prefix ${ARGV1})
ENDIF()
UNSET(REQUIRED)
IF(${pkg}_REQUIRED)
SET(REQUIRED REQUIRED)
ENDIF()
FIND_PACKAGE(${pkg} COMPONENTS ${${pkg}_COMPONENTS} ${REQUIRED})
MESSAGE(Begin: ${pkg} result variables)
GET_DIRECTORY_PROPERTY(v VARIABLES)
FOREACH(i IN LISTS v)
IF(i MATCHES ^${prefix}.*_FOUND$)
MESSAGE(${i}=${${i}})
ENDIF()
ENDFOREACH()
MESSAGE(${prefix}_LIBRARIES: ${${prefix}_LIBRARIES})
MESSAGE(End: ${pkg} result variables)
ENDFUNCTION()
FindResultVariables(Boost)
FindResultVariables(GTK2)
FindResultVariables(HDF5)
FindResultVariables(ImageMagick)
FindResultVariables(Java)
FindResultVariables(OpenSceneGraph)
FindResultVariables(Qt4 QT)
FindResultVariables(wxWidgets)
FindResultVariables(XMLRPC)
HDF5, OpenSceneGraph and XMLRPC aren't installed on my system; my
preliminary findings for the remaining packages are as follows:
(1) Searching unrequested components:
Qt4: Yes.
GTK2,ImageMagick: Partially.
wxWidgets: All components if none are requested.
The remaining modules don't search unrequested components.
(2) Assigning *_*_FOUND variables:
Qt4: Only for modules which are known and found.
ImageMagick: Also for requested but unknown components.
wxWidgets: No *_*_FOUND variables at all but forwards unknown
components to *_LIBRARIES variable without an error.
The remaining modules assign only to *_*_FOUND variables for
components which they know and which have been requested.
(3) Respecting the REQUIRED flag:
wxWidgets: REQUIRED ignored completely.
Boost: SEND_ERROR instead of FATAL_ERROR.
GTK2,Java: Bail out on unknown components even if not REQUIRED.
The remaining modules bail out on unavailable requested components.
(4) Assinging the package-related *_FOUND variable:
Java: No *_FOUND variable at all although it's documented.
wxWidgets: TRUE even if requested components aren't found, see above.
The remaining modules return FALSE if a requested component isn't found.
My comments on these, say, multifarious findings are:
Ad.(1): In general, automatically searching unrequested components
does not mean a harm, but it is also not beneficial at all events:
- No guarantee to catch all components - consider a component added
later to the package - so no guarantee that all later *_*_FOUND
variables have been assigned a definite value by FIND_PACKAGE().
- Complicates find modules / config files due to REQUIRED/QUIET.
- Potentially higher costs due to unneeded search operations.
For the latter loint, there is a not-so-uncommon use case: Suppose
a find module wants to check whether a library matches its header.
Putting away cross-compiling issues for the moment, this requires
building and running a test program. If it is to be performed for
each Qt4 module, e.g., a FIND_PACKAGE(Qt4) invocation would most
certainly be quite expensive. For these reasons, I usually advice
to search only requested components, request all components going
to be used and refer only to components having been requested.
Ad.(2): Due to my guiding principle - refer only to FOUND variables
which have been assigned a definite value by FIND_PACKAGE() - I do
consider as important that a *_*_FOUND variable is assigned to for
each requested component. FindImageMagick.cmake does it right, but
the other modules - except for FindwxWidgets.cmake - have me check
*_*_FOUND variables without a definite value for requested but un-
known components. Again: The latters might become known one day.
Ad.(3): After FIND_PACKAGE(... REQUIRED), I definitely do not want
to check if all requested components including their prerequisites
are actually present. OTOH, the user must have the oppurtunity to
handle a package's or a component's absence by h(is|er)self. Thus,
FIND_PACKAGE() without REQUIRED should never bail out because of
something being not found, but with REQUIRED, it must bail out.
Ad.(4): None of the modules returning *_FOUND==FALSE just because
a component is missing could be turned into a config file at the
moment without changing its behavior. In order to address this
issue in the future, one has to decide if either
- a find module should behave like a config file in this regard and
return *_FOUND==FALSE
Re: [CMake] Functions inherit parent variables?
On 03/01/2012 01:38 AM, Robert Dailey wrote:
I ran a quick test:
function( test )
message( SOME_TEST: ${SOME_TEST} )
endfunction()
function( start )
set( SOME_TEST HELLO WORLD )
test()
endfunction()
start()
Seems like a function has access to the calling scope's defined variables.
I thought because functions created a new scope, that excluded access to
variables defined in the outer scope (i.e. calling scope)
Can someone explain?
The line SOME_TEST: HELLO WORLD is missing, I guess?
As usual with scoping mechanisms, there is access to the outer scope
from within the inner scope: Read access via ordinary dereferencing
and write access via PARENT_SCOPE. It's quite the same as in C/C++
with the { and } tokens; see also the C++ :: operator.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
On 02/26/2012 11:24 AM, Alexander Neundorf wrote: On Sunday 26 February 2012, Michael Hertling wrote: On 02/25/2012 09:43 AM, Alexander Neundorf wrote: On Friday 24 February 2012, Michael Hertling wrote: On 02/24/2012 03:34 PM, Stephen Kelly wrote: ... [...] (that is, find_package(Qt5 REQUIRED Gui Xml) might not find QtXml, but Qt5_FOUND would still be true if the Qt5Config file is found, whether the component is or not), [...] No: FIND_PACKAGE(Qt5 REQUIRED ...) is expected to bail out if any of the required components aren't found, so the value of the Qt5_FOUND variable doesn't matter in this case. BTW, note that FIND_PACKAGE() must not bail out if a component which the user hasn't requested is not found, regardless of the REQUIRED flag, unless the component is an immediate or mediate prerequisite of a required one. Regarding Qt5_FOUND, FIND_PACKAGE(Qt5 COMPONENTS ...), i.e. without REQUIRED, is more interesting, see [4]. In short: Qt5_FOUND indicates if Qt5 is basically present but says nothing about any component; the user must refer to the component-specific FOUND variables, and those must even be protected by the package-specific one: Ah, yes, I remember this discussion. I'd sum up the results as follows: * Config-mode should behave the same way as Module-mode with regard to COMPONENTS (I think this still needs changes in the find_package() implementation) Which changes do you have in mind? AFAIK, config files and find modules can perfectly behave the same - provided they're implemented correctly. I think currently cmFindPackage.cxx in Config mode doesn't evaluate the per component variables at all to decide whether the package has been found or not, which may be required for the next point: * if REQUIRED is used, find_package(Foo COMPONENTS A B C) must only succeed if all listed components have been found Perhaps, we can also include components which are immediate or mediate prerequisites of the listed ones. The REQUIRED flag should ensure that anything necessary to use the listed components is actually available. Yes. * if REQUIRED is not used, we still have two opinions: 1.) FOO_FOUND should be the major sign whether everything I wanted has been found or not. I.e. it is only set to TRUE if all listed components have been found. To check whether some of the components have been found, i.e. if FOO_FOUND==FALSE, I can check the per-component _FOUND variables. The reasoning here is I want to use some parts of a big package, if they all are found, then I can use it, otherwise I can't use the package at all If FOO_FOUND==FALSE and FIND_PACKAGE() did load a config file, none of the per-component _FOUND variables has received a definite value, i.e. you'd refer to the values they already had before the invocation of FIND_PACKAGE(). Yes. But other resulting variables are also not reset by find_package() in case of failure. So I wouldn't see this a problem. The fact that other variables remain untouched as well in this case doesn't make things better; you'd still query variables which are to be provided by the config file but have not been assigned a definite value by the latter. IMO, that's bad style, makes the configuration unneccessarily vulnerable and means asking for trouble in the long term. BTW, if FOO was a single-component package, one wouldn't use any of its typical variables for any purpose after FIND_PACKAGE() returned with FOO_FOUND==FALSE. Multi- and single-component packages should behave the same in this regard, as well as find modules and config files. FOO_FOUND's only consistent interpretation w.r.t. this is: FOO_FOUND==FALSE -- Hands off, don't use the package in any way; in particular, don't refer to any of the package's variables. 2.) FOO_FOUND should only indicate that at least something of Foo has been found. To check which modules have been found, i.e. if FOO_FOUND==TRUE, I must check the per-component _FOUND variables. The logic here is I want to use some parts of a big package, and I can use them independently from each other. Both make sense. I'd prefer the first one. Presumably, you're not surprised that I move for the second. ;-) One of my favorite points for the latter is the following use case: Suppose there's a multi-component package FOO which provides some required components and some optional ones. The user has three distinct possibilities how those components can be requested: (A) Request all of them with the REQUIRED flag: Bad, a missing optional component would terminate the configuration although all is well. I would expect that if I don't specify any (subset of) components, it will search for all, FOO_FOUND is set to TRUE if a sufficient subset of components has been found. sufficient would be package-specific. By explicitely adding components, they become part of the set of components which is considered sufficient. A casual question: With that reading, how
Re: [CMake] Code and API review request for Qt5 CMake files
On 02/25/2012 09:43 AM, Alexander Neundorf wrote: On Friday 24 February 2012, Michael Hertling wrote: On 02/24/2012 03:34 PM, Stephen Kelly wrote: ... [...] (that is, find_package(Qt5 REQUIRED Gui Xml) might not find QtXml, but Qt5_FOUND would still be true if the Qt5Config file is found, whether the component is or not), [...] No: FIND_PACKAGE(Qt5 REQUIRED ...) is expected to bail out if any of the required components aren't found, so the value of the Qt5_FOUND variable doesn't matter in this case. BTW, note that FIND_PACKAGE() must not bail out if a component which the user hasn't requested is not found, regardless of the REQUIRED flag, unless the component is an immediate or mediate prerequisite of a required one. Regarding Qt5_FOUND, FIND_PACKAGE(Qt5 COMPONENTS ...), i.e. without REQUIRED, is more interesting, see [4]. In short: Qt5_FOUND indicates if Qt5 is basically present but says nothing about any component; the user must refer to the component-specific FOUND variables, and those must even be protected by the package-specific one: Ah, yes, I remember this discussion. I'd sum up the results as follows: * Config-mode should behave the same way as Module-mode with regard to COMPONENTS (I think this still needs changes in the find_package() implementation) Which changes do you have in mind? AFAIK, config files and find modules can perfectly behave the same - provided they're implemented correctly. * if REQUIRED is used, find_package(Foo COMPONENTS A B C) must only succeed if all listed components have been found Perhaps, we can also include components which are immediate or mediate prerequisites of the listed ones. The REQUIRED flag should ensure that anything necessary to use the listed components is actually available. * if REQUIRED is not used, we still have two opinions: 1.) FOO_FOUND should be the major sign whether everything I wanted has been found or not. I.e. it is only set to TRUE if all listed components have been found. To check whether some of the components have been found, i.e. if FOO_FOUND==FALSE, I can check the per-component _FOUND variables. The reasoning here is I want to use some parts of a big package, if they all are found, then I can use it, otherwise I can't use the package at all If FOO_FOUND==FALSE and FIND_PACKAGE() did load a config file, none of the per-component _FOUND variables has received a definite value, i.e. you'd refer to the values they already had before the invocation of FIND_PACKAGE(). 2.) FOO_FOUND should only indicate that at least something of Foo has been found. To check which modules have been found, i.e. if FOO_FOUND==TRUE, I must check the per-component _FOUND variables. The logic here is I want to use some parts of a big package, and I can use them independently from each other. Both make sense. I'd prefer the first one. Presumably, you're not surprised that I move for the second. ;-) One of my favorite points for the latter is the following use case: Suppose there's a multi-component package FOO which provides some required components and some optional ones. The user has three distinct possibilities how those components can be requested: (A) Request all of them with the REQUIRED flag: Bad, a missing optional component would terminate the configuration although all is well. (B) Request all of them without the REQUIRED flag: With your preference (1), a missing optional component would result in FOO_FOUND==FALSE although all is well. As for me, that's not what I'd expect if the findings are certainly acceptable. (C) Request the required components with REQUIRED and the optional ones without this flag via a separate FIND_PACKAGE() invocation: If all required components are found but an optional component is missing, your preference (1) would result in FOO_FOUND==TRUE for the formers and FOO_FOUND==FALSE for the latters. That's even more inconsistent than (B), although the findings are likewise acceptable. Moreover, there might be reasons why one doesn't want to use more than one FIND_PACKAGE() call to request components which are going to be used together; recall the example of package X with components A and B and a possibly necessary -DX_WITH_B definition for A. As a fourth possibility, one might drop the optional components from the FIND_PACKAGE() call and rely on the assumption that unrequested components are searched unaskedly by the config file / find module. This should not be forced on the latter, and what should happen if an optional component isn't known at all? Recall the example of Qt5 with a module XYZ added in a later release: An application willing to use XYZ if available but configured against an earlier release of Qt5 via FIND_PACKAGE(Qt5) would also refer to a Qt5_XYZ_FOUND variable which has not - can't have - received a definite value. IMO, the use case with mixed required and optional components points out
Re: [CMake] Code and API review request for Qt5 CMake files
On 02/24/2012 03:34 PM, Stephen Kelly wrote:
Just forwarding to the cmake users list.
Stephen Kelly wrote:
Hi there,
Qt5 generates its own CMake files, which you will be able to use to find
Qt5 and build with it.
That is, you will port from, eg
find_package(Qt4 REQUIRED Core Gui Xml)
to
find_package(Qt5Widgets REQUIRED)
find_package(Qt5Xml REQUIRED)
find_package(Qt5Core) is also possible but is not needed because it is a
dependency of at least one of the other requirements already in this case.
find_package(Qt5) will not work currently (though it can be made to work
now or after Qt 5.0).
You will then port
target_link_libraries(foo ${QT_QTCORE_LIBRARIES})
to
target_link_libraries(foo ${Qt5Core_LIBRARIES})
etc.
Or you might use qt5_use_package:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3083
qt5_use_package(foo Core)
# That's it! Nothing more to do.
The variables all map fairly well. There is also a Qt5Transitional package
which might help with that (If it gets released, which I'm not certain it
will be): https://projects.kde.org/projects/kdesupport/extra-cmake-
modules/repository/revisions/master/entry/modules/FindQt5Transitional.cmake
The Qt5moduleConfig.cmake files are generated and installed by Qt
itself.
I'd like a review of them by people familiar enough with how CMake works
and an API review from people familiar with how it is used.
The generation of them is platform specific, and configure options
specific, eg whether you use -framework on mac, whether you use MinGW or
MSVC, whether building with an infix or a namespace. The easiest way for
you to generate the config files is:
# Note: Don't bother cloning qt5.git unless you already have it.
# That takes forever.
git clone git://gitorious.org/qt/qtbase.git
cd qtbase
./configure
ls lib/cmake
Make sure you have at least commit
c470999329ee576038c50573314699f972f48909.
You can go on to build and test them if you wish. The ctest unit tests are
in qtbase/tests/manual/cmake. These tests are not part of any
multi-platform CI system.
Compared to the last time I emailed about this, the generated Config files
have become more simple. I discovered that qmake can have conditionals in
its configure_file equivalent.
Things that work:
* Finding Qt with an infix.
* Building against Qt with a namespace.
* Finding statically built Qt (though when linking you have to list the
dependencies yourself currently)
* Finding a particular version should work as ConfigVersion files are
installed, but I have not tested it.
Things to review:
* Are the Config files created correctly for your platform and
configuration?
* Do the unit tests pass on your platform?
* Currently there is no Qt5Config.cmake.
Such a thing could probably exist and use the FIND_COMPONENTS to find what
was requested. [...]
Absolutely, I would greatly appreciate a well-designed and component-
aware Qt5Config.cmake. In general, there might be reasons why a multi-
component package's components that are to be used together should not
be requested in separate FIND_PACKAGE() invocations, see [1] and look
for package X with components A and B. However, I don't know if Qt5
will be the first example of that kind.
[...] However, because there is no way to signal from a Config
file that a component was not found [...]
No: See [2] and look for the XXX_YY_FOUND variables. They fit perfectly
to indicate if component YY of package XXX has been found or not, and
they can be set conveniently by FPHSA(XXX_YY ...), see [3].
[...] (that is, find_package(Qt5 REQUIRED
Gui Xml) might not find QtXml, but Qt5_FOUND would still be true if the
Qt5Config file is found, whether the component is or not), [...]
No: FIND_PACKAGE(Qt5 REQUIRED ...) is expected to bail out if any of
the required components aren't found, so the value of the Qt5_FOUND
variable doesn't matter in this case. BTW, note that FIND_PACKAGE()
must not bail out if a component which the user hasn't requested is
not found, regardless of the REQUIRED flag, unless the component is
an immediate or mediate prerequisite of a required one.
Regarding Qt5_FOUND, FIND_PACKAGE(Qt5 COMPONENTS ...), i.e. without
REQUIRED, is more interesting, see [4]. In short: Qt5_FOUND indicates
if Qt5 is basically present but says nothing about any component; the
user must refer to the component-specific FOUND variables, and those
must even be protected by the package-specific one:
FIND_PACKAGE(Qt5 COMPONENTS XYZ)
IF(Qt5_FOUND AND Qt5_XYZ_FOUND)
...
ENDIF()
Referring to Qt5_XYZ_FOUND alone is not reliable because this variable
wouldn't have received a definite value if Qt5Config.cmake hasn't been
found by FIND_PACKAGE(). I.e., the user would refer to this variable's
value before the FIND_PACKAGE() call; probably, that's not expected.
Note that you should also think about handling components requested
by the user but unknown to Qt5Config.cmake. Consider
Re: [CMake] add_executable and extension of source file
On 02/24/2012 06:16 PM, Kris Thielemans wrote:
Hi
I have a project where I have C++ and C source files. I'm adding executables
for this (via macros) like this
foreach(executable ${SOURCES})
add_executable(${executable} ${executable} )
target_link_libraries(${executable} ${STIR_LIBRARIES})
endforeach()
where ${SOURCES} is a list of sources WITHOUT extension, e.g.
set( SOURCES abs_image src2)
This relies on the fact that cmake should find .cxx and .c etc source files
for add_executable. At least, I think it should (I found this some tutorial,
e.g.
http://www-flc.desy.de/ldcoptimization/documents/talks/CMake_Tutorial.pdf),
but the doc for add_executable does not seem to mention this behaviour.
My current CMake files work fine on Windows and Linux, but I now have a
MacOSX user who says that it fails. He's running cmake 2.8.7 and when I
inspect that linking command, it looks like (slightly edited for brevity)
/usr/bin/c++ -O3 -DNDEBUG -ffast-math -Wl,-search_paths_first
-Wl,-headerpad_max_install_names
-o abs_image a ../buildblock/libbuildblock.a
That is, clearly the abs_image.o file is missing on this command line.
Maybe this adding a list of known extensions feature is no longer
supported? Or is the list of known extensions platform specific? (that would
be bad)
The gcc manpage states:
cite
For any given input file, the file name suffix determines what kind of
compilation is done:
file.c
C source code which must be preprocessed.
...
other
An object file to be fed straight into linking. Any file name with
no recognized suffix is treated this way.
...
-c Compile or assemble the source files, but do not link. [...]
Unrecognized input files, not requiring compilation or assembly,
are ignored.
/cite
Thus, AFAICS, CMake handles the extension-less sources correctly, but
gcc freaks out: No extension -- ignore when compiling -- no object
file. IMO, it's a quite bad idea to provide source files without a
proper suffix. However, see gcc's -x switch.
I guess I will have to set my SOURCE files with the extension, and then
strip the extension for the executable-name. maybe with something like
foreach(src ${SOURCES})
STRING(REPLACE \(.*\)\..* \1 executable ${src})
add_executable(${executable} ${src} )
...
endforeach()
SET(SOURCES abs_image.cxx src2.c)
...
FOREACH(i IN LISTS SOURCES)
GET_FILENAME_COMPONENT(j ${i} NAME_WE)
ADD_EXECUTABLE(${j} ${i})
ENDFOREACH()
or alternatively find the source file
foreach(executable ${SOURCES})
FILE(GLOB src *.cxx *.c)
add_executable(${executable} ${src} )
target_link_libraries(${executable} ${STIR_LIBRARIES})
endforeach()
Do not use FILE(GLOB ...) in a CMakeLists.txt since this makes the
latter unaware of additions/removals/renamings among your sources.
You will most certainly miss a necessary reconfiguration one day.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to recursively copy directories and subdirectories...
On 02/25/2012 03:16 AM, Sumit Kumar wrote: Hello I would like to recursively copy folders/subfolders when I do a make install. In addition, I would like to copy certain file patterns (typically *.h) files that may be in these folders. I can do this for individual files (by doing a glob / glob recurse). However, in doing this I lose the directory structure. Any help will be appreciated. Thanks and Regards Sumit INSTALL(DIRECTORY ...) with FILES_MATCHING/PATTERN/REGEX/EXCLUDE options. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] delayed target
On 02/22/2012 05:02 PM, Andrea Crotti wrote:
Again I'm having some troubles with the different building stages:
I would like to have a target that simply unzips all the files contained
in a directory,
which can be found with a simple globbing.
add_custom_target(unzip_all_eggs
file(GLOB eggs RELATIVE ${EGG_BUILD_DIRECTORY}/*egg)
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${egg}
)
The problem is that [...]
...FILE(GLOB ...) is a CMake command executed by CMake, whereas the
custom target's COMMANDs are executed by the build tool at build
time, so this approach fails from the first.
A possible solution is to make my UNZIP_SCRIPT smarter and just do the
globbing
itself, is there any other more CMake-like solution?
ADD_CUSTOM_TARGET(unzip_all_eggs
${CMAKE_COMMAND}
-DEGGDIR=${EGG_BUILD_DIRECTORY}
-P ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake)
# ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake:
SET(PYTHON_EXECUTABLE ...)
SET(UNZIP_SCRIPT ...)
FILE(GLOB eggs RELATIVE ${EGGDIR}/*egg)
EXECUTE_PROCESS(
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${eggs}
WORKING_DIRECTORY ...
)
You might want to provide an unzip_all_eggs.cmake.in template including
SET(PYTHON_EXECUTABLE @PYTHON_EXECUTABLE@)
SET(UNZIP_SCRIPT @UNZIP_SCRIPT@)
use CONFIGURE_FILE(unzip_all_eggs.cmake.in unzip_all_eggs.cmake @ONLY)
to generate the actual unzip_all_eggs.cmake after searching Python and
your script, and specify -P ${CMAKE_BINARY_DIR}/unzip_all_eggs.cmake.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] passing arguments to the final make
On 02/22/2012 04:43 PM, Andrea Crotti wrote:
I would like to be able to pass arguments to my generated Makefile.
Suppose I use an environment variable like this:
add_custom_target(run_dev_script
COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE}
COMMAND ${PYTHON_EXECUTABLE} ${SCRIPT}
)
Would that actually work?
In theory ${SCRIPT} is substituted at cmake time, so I have the
impression that it wouldn't work..
I don't find anything useful in cmake -E however, that would allow me to
do something at make time.
Any suggestions?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
ADD_CUSTOM_TARGET(echo ${CMAKE_COMMAND} -E echo \${ECHO})
After initial configuration:
% make echo ECHO=Hello World
Scanning dependencies of target echo
Hello World
Built target echo
% make echo ECHO=Goodbye World
Goodbye World
Built target echo
% make echo ECHO=Regards, Michael
Regards, Michael
Built target echo
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] passing arguments to the final make
On 02/22/2012 06:32 PM, Andrea Crotti wrote:
On 02/22/2012 05:25 PM, Michael Hertling wrote:
On 02/22/2012 04:43 PM, Andrea Crotti wrote:
I would like to be able to pass arguments to my generated Makefile.
Suppose I use an environment variable like this:
add_custom_target(run_dev_script
COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE}
COMMAND ${PYTHON_EXECUTABLE} ${SCRIPT}
)
Would that actually work?
In theory ${SCRIPT} is substituted at cmake time, so I have the
impression that it wouldn't work..
I don't find anything useful in cmake -E however, that would allow me to
do something at make time.
Any suggestions?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
ADD_CUSTOM_TARGET(echo ${CMAKE_COMMAND} -E echo \${ECHO})
After initial configuration:
% make echo ECHO=Hello World
Scanning dependencies of target echo
Hello World
Built target echo
% make echo ECHO=Goodbye World
Goodbye World
Built target echo
% make echo ECHO=Regards, Michael
Regards, Michael
Built target echo
Ah that's nice thanks, I'm not sure though that I can rely on being =
2.8 always,
and that's probably a requirement, right?
It's sufficient that \$ makes it to the Makefile and becomes $ there.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] delayed target
On 02/22/2012 07:21 PM, Andrea Crotti wrote:
On 02/22/2012 05:14 PM, Michael Hertling wrote:
On 02/22/2012 05:02 PM, Andrea Crotti wrote:
Again I'm having some troubles with the different building stages:
I would like to have a target that simply unzips all the files contained
in a directory,
which can be found with a simple globbing.
add_custom_target(unzip_all_eggs
file(GLOB eggs RELATIVE ${EGG_BUILD_DIRECTORY}/*egg)
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${egg}
)
The problem is that [...]
...FILE(GLOB ...) is a CMake command executed by CMake, whereas the
custom target's COMMANDs are executed by the build tool at build
time, so this approach fails from the first.
A possible solution is to make my UNZIP_SCRIPT smarter and just do the
globbing
itself, is there any other more CMake-like solution?
ADD_CUSTOM_TARGET(unzip_all_eggs
${CMAKE_COMMAND}
-DEGGDIR=${EGG_BUILD_DIRECTORY}
-P ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake)
# ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake:
SET(PYTHON_EXECUTABLE ...)
SET(UNZIP_SCRIPT ...)
FILE(GLOB eggs RELATIVE ${EGGDIR}/*egg)
EXECUTE_PROCESS(
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${eggs}
WORKING_DIRECTORY ...
)
You might want to provide an unzip_all_eggs.cmake.in template including
SET(PYTHON_EXECUTABLE @PYTHON_EXECUTABLE@)
SET(UNZIP_SCRIPT @UNZIP_SCRIPT@)
use CONFIGURE_FILE(unzip_all_eggs.cmake.in unzip_all_eggs.cmake @ONLY)
to generate the actual unzip_all_eggs.cmake after searching Python and
your script, and specify -P ${CMAKE_BINARY_DIR}/unzip_all_eggs.cmake.
Thanks, this is really nice in general and I might use it in the future.
The problem is that in this specific case it doesn't buy me much and
adds complexity, because
I would still have only one target unzipping all the eggs.
It would be nice to be able to generate N target 1 for each egg.
In order to define one target per egg, you'd need to know the eggs at
configuration time since you cannot define targets at build time. So,
gathering the eggs with a custom target/command will not work. As an
alternative, you might gather the eggs at configuration time with a
FILE(GLOB ...) command, loop over the resulting list and define one
target per item. However, your Makefiles would not be aware of any
changes among the eggs - additions, removals, renamings - and you
would need to remember to reconfigure your project by hand if you
don't want to miss any changes. That's somewhat error-prone and
means relinquishing one of CMake's benefits.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Shared intermediary files
On 02/20/2012 10:07 PM, Kevin Schmidt wrote: Hello, I'm in the process of converting over a large, monolithic tree with many libraries from a custom build solution over to cmake. So far, we've loved it. I am wondering about others' solutions to a problem we have encountered. We have more than a few cases of generated source files - for example, Qt moc files. These all get dumped into CMAKE_CURRENT_BINARY_DIR. Now, the libraries we have build both static shared, and have the same source files. In Visual Studio, this generates two projects in the solution. It seems that these do not share dependencies. Occasionally, this means that both libraries try to write to the generated source file at the same time, which generates a (false) build failure. What do others do? Am I misunderstanding something? Kevin How do you generate the source files? Supposedly, you're using custom commands, right? At least, QT4_WRAP_CPP() does. If so, you probably walk right into a quite common trap - from the documentation of ADD_CUSTOM_COMMAND(): Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict (instead use add_custom_target to drive the command and make the other targets depend on that one). If your issue isn't related to custom commands, could you provide more detailed information how you generate the source files in question? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] delayed target
On 02/22/2012 11:55 PM, Andrea Crotti wrote: On 02/22/2012 09:37 PM, Michael Hertling wrote: In order to define one target per egg, you'd need to know the eggs at configuration time since you cannot define targets at build time. So, gathering the eggs with a custom target/command will not work. As an alternative, you might gather the eggs at configuration time with a FILE(GLOB ...) command, loop over the resulting list and define one target per item. However, your Makefiles would not be aware of any changes among the eggs - additions, removals, renamings - and you would need to remember to reconfigure your project by hand if you don't want to miss any changes. That's somewhat error-prone and means relinquishing one of CMake's benefits. Regards, Michael - Yes sure when there are changes in that sense we need to reconfigure, but it's really not a big deal in our case because it won't almost never happen, and anyway I don't really have any other choice if I want to use the parallelization provided by make -j. There is a possibility to dynamically reconfigure/rebuild the project without an intermediate manual step and in a way that you'll have one target per egg, but that approach is disadvantageous in other regards and possibly won't work with generators other than the Makefiles ones. IMO, if you really need one target per egg, you should gather them at configure time and accept the need to reconfigure the project by hand when necessary. If one target per egg isn't a must-do, gather them at build time and use a script - CMake, shell, whatever - to unzip them; this can be done well in parallel also. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] passing arguments to the final make
On 02/23/2012 12:04 AM, John Drescher wrote:
And another thing, is it actually \${SCRIPT} a portable solution that works
on all the generators?
This is not about generators but about what shell you are running
cmake from. For example that would not work on windows since the
command prompt has a different syntax for variables.
The point is that ${SCRIPT} is substituted in the Makefile by
(1) a macro specified on the command line
(2) a macro specified in the Makefile
(3) an environment variable
in that order, or with (2) and (3) reversed if Make is invoked with the
-e switch. When the Makefile's command lines are passed to the shell,
the substitution has already taken place, so it should also work with
the Windows command prompt. However, one needs a Make program, i.e. a
parameterization of this kind probably doesn't work with non-Makefile
generators. Even with Makefiles, there are subtle pitfalls: If a line
SCRIPT = ... happens to appear somewhere in the Makefiles, invoking
Make as make SCRIPT=... will overwrite it, most certainly resulting
in surprising and undesired behaviour. Personally, I'd advise against
using this method without explicit support by the Makefile generator.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find both shared and static versions?
On 02/17/2012 01:36 AM, Dougal Sutherland wrote:
I have an application where I want to link some targets against shared
versions of Boost and some against static versions.
(I'd prefer shared in general, but I need to link against the static
version of boost for my matlab mex interface, to avoid loading the
different version of boost shipped by matlab on runtime. I'm using this
approachhttps://github.com/mariusmuja/flann/blob/master/src/matlab/CMakeLists.txtof
a custom target calling the mex command to compile the mex file.)
FindBoost.cmake honors the Boost_USE_STATIC_LIBS variable, but that doesn't
quite solve it.
I've had the following ideas, none of which I'm happy with:
1. Use -L${Boost_LIBRARY_DIRS} and then construct the name by doing a
string replacement from .so/.dylib to .a in ${Boost_THREAD_LIBRARY}.
Definitely won't work on Windows, might not work for some types of Boost
installations on Linux/Mac, and fails at link-time instead of
configure-time if the static version doesn't exist. Maybe there's an
equivalent transformation that'll probably work on Windows; I don't know,
I'm not a Windows user.
2. Copy FindBoost.cmake to FindBoostS.cmake and replace all the
variables to use a BoostS prefix, as well as making the conditionals for
USE_STATIC_LIBS always be on; then I can run find_package(Boost) as well as
find_package(BoostS).
3. There might be some trickery to approximate (2) without actually
modifying FindBoost, but I haven't figured it out.
4. Modify FindBoost.cmake either to look for both dynamic and shared
libraries and set e.g. Boost_THREAD_LIBRARY_STATIC and
Boost_THREAD_LIBRARY_SHARED if found, or to add shared and static versions
for each component, as in
http://www.cmake.org/pipermail/cmake/2012-February/049142.html
(4) is obviously the best approach, but it's also probably much more work
than I really want to do on this.
Any suggestions? Some other approach I haven't thought of, a way to do (3),
a copy of (4) floating around somewhere?
Thanks,
Dougal
You might use multiple invocations of FIND_PACKAGE(Boost ...):
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.cxx int main(void){return 0;}\n)
# main1:
FIND_PACKAGE(Boost COMPONENTS thread)
MESSAGE(Boost_LIBRARIES: ${Boost_LIBRARIES})
ADD_EXECUTABLE(main1 main.cxx)
TARGET_LINK_LIBRARIES(main1 ${Boost_LIBRARIES})
# re-set up:
UNSET(Boost_LIBRARIES)
SET(Boost_USE_STATIC_LIBS ON)
#main2:
FIND_PACKAGE(Boost COMPONENTS regex)
MESSAGE(Boost_LIBRARIES: ${Boost_LIBRARIES})
ADD_EXECUTABLE(main2 main.cxx)
TARGET_LINK_LIBRARIES(main2 ${Boost_LIBRARIES})
The main1 target is linked against the shared thread library whereas
main2 is linked against the static regex one. Note the switch in the
Boost_USE_STATIC_LIBS variable between the two FIND_PACKAGE() calls.
IMO, FindBoost.cmake behaves bad in one regard: It accumulates results
from different invocations within the same scope. For this reason, you
must intermediately unset the Boost_LIBRARIES variable - and probably
all further uncached result variables like Boost_INCLUDE_DIRS also.
Otherwise, main2 would be linked against the shared thread library,
too, although the latter has not been requested by the latest FIND_
PACKAGE() call. With Boost, AFAIK, it's sufficient to simply reset
the uncached result variables, but with {Find,Use}Qt4.cmake, e.g.,
and their QT_USE_QT* variables, it's a real annoyance to link two
targets against different sets of Qt modules within the same scope.
In summary, my vision of an improved FindBoost.cmake comprises:
- Explicitly shared and static components, e.g. thread_shared and
regex_static, so one can specifically select them even in mixed
cases: FIND_PACKAGE(Boost COMPONENTS thread_shared regex_static)
- For convenience and backward compatibility, the usual components
like thread and regex as always, with Boost_USE_STATIC_LIBS
deciding whether component X is turned into X_shared or X_static.
AFAICS, this can be accomplished as a kind of preprocessing the
Boost_FIND_COMPONENTS variable quite early in FindBoost.cmake.
- No accumulation of uncached results across multiple invocations
of FindBoost.cmake; in other words: The uncached results should
depend only on the parameters of the FindBoost.cmake invocation,
i.e. the components list, well-known variables as CMAKE_MODULE_
PATH and well-documented ones as BOOST_ROOT - though the latter
isn't mentioned in FindBoost.cmake's online documentation ATM.
In contrast, results of previous FindBoost.cmake calls should
not show up in the uncached result variables for exactly the
reason mentioned above.
Feel free to file a feature request; maybe, PL can be persuaded. ;)
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Re: [CMake] How to have a static/shared option in a Find script ?
On 02/16/2012 03:14 PM, Barth wrote:
Hi again,
I have understood what you meant :)
Hhm, actually, I talked nonsense w.r.t. DIM_USE_STATIC. ;)
For records here is what I did :
# (1) Use FIND_LIBRARY() to look for the shared and the static library
# and define DIM_SHARED_LIBRARY and DIM_STATIC_LIBRARY in the cache.
find_library(DIM_STATIC_LIBRARY NAMES libdim.a PATHS $ENV{DIMDIR}
PATH_SUFFIXES linux)
find_library(DIM_SHARED_LIBRARY NAMES dim PATHS $ENV{DIMDIR} PATH_SUFFIXES
linux)
If libdim.so doesn't exist, but libdim.a does, the last FIND_LIBRARY()
call would return libdim.a, too, which is probably not desired. Here,
one should consider to narrow the search for the respective library
type, e.g. by manipulating CMAKE_FIND_LIBRARY_SUFFIXES; see also
CMAKE_{SHARED,STATIC}_LIBRARY_{PREFIX,SUFFIX} in this regard.
# (2) Inspect DIM_FIND_COMPONENTS to see which flavor has been requested,
# defaulting to shared if no components have been requested at all.
LIST(FIND DIM_FIND_COMPONENTS static ASK_STATIC_COMP)
LIST(FIND DIM_FIND_COMPONENTS shared ASK_SHARED_COMP)
No need for them; use DIM_FIND_REQUIRED_{STATIC,SHARED} - predefined
by FIND_PACKAGE(). Refer to Modules/readme.txt for more information.
# (3) Warn or bail out if shared and static have both been requested
if ( ${ASK_STATIC_COMP} GREATER -1 AND ${ASK_SHARED_COMP} GREATER -1)
message(WARNING Two incompatible components specified : static and
shared. We are going to ignore the static component.)
endif ( ${ASK_STATIC_COMP} GREATER -1 AND ${ASK_SHARED_COMP} GREATER -1)
IF(DIM_FIND_REQUIRED_SHARED AND DIM_FIND_REQUIRED_STATIC)
MESSAGE(WARNING ...)
LIST(REMOVE_ITEM DIM_FIND_COMPONENTS static)
UNSET(DIM_FIND_REQUIRED_STATIC)
ENDIF()
Do something to the contrary if DIM_FIND_COMPONENTS is empty:
IF(NOT DIM_FIND_COMPONENTS)
LIST(APPEND DIM_FIND_COMPONENTS shared)
SET(DIM_FIND_REQUIRED_SHARED TRUE)
ENDIF()
The point is that DIM_FIND_COMPONENTS and DIM_FIND_REQUIRED_* are set
up properly *before* you are going to actually enable the components.
# (4) DIM_USE_STATIC decides if DIM_LIBRARIES receives DIM_STATIC_LIBRARY
# or DIM_SHARED_LIBRARY
option(DIM_FORCE_STATIC Turn on to force the use of the static library
OFF)
if( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
set(DIM_LIBRARIES ${DIM_STATIC_LIBRARY} )
else ( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
set(DIM_LIBRARIES ${DIM_SHARED_LIBRARY} )
endif( ${DIM_FORCE_STATIC} OR ${ASK_STATIC_COMP} GREATER -1)
UNSET(DIM_INCLUDE_DIRS)
UNSET(DIM_LIBRARIES)
SET(DIM_FOUND FALSE)
FIND_PATH(DIM_INCLUDE_DIR ...)
IF(DIM_INCLUDE_DIR)
SET(DIM_FOUND TRUE)
ENDIF
IF(DIM_FIND_REQUIRED_SHARED)
FIND_LIBRARY(DIM_SHARED_LIBRARY ...)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(
DIM_SHARED
DEFAULT_MSG
DIM_INCLUDE_DIR
DIM_SHARED_LIBRARY)
IF(DIM_SHARED_FOUND)
LIST(APPEND DIM_INCLUDE_DIRS ${DIM_INCLUDE_DIR} ...)
LIST(APPEND DIM_LIBRARIES ${DIM_SHARED_LIBRARY} ...)
ENDIF()
LIST(REMOVE DIM_FIND_COMPONENTS shared)
UNSET(DIM_FIND_REQUIRED_SHARED)
ENDIF()
IF(DIM_FIND_REQUIRED_STATIC)
FIND_LIBRARY(DIM_STATIC_LIBRARY ...)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(
DIM_STATIC
DEFAULT_MSG
DIM_INCLUDE_DIR
DIM_STATIC_LIBRARY)
IF(DIM_STATIC_FOUND)
LIST(APPEND DIM_INCLUDE_DIRS ${DIM_INCLUDE_DIR} ...)
LIST(APPEND DIM_LIBRARIES ${DIM_STATIC_LIBRARY} ...)
ENDIF()
LIST(REMOVE DIM_FIND_COMPONENTS static)
UNSET(DIM_FIND_REQUIRED_STATIC)
ENDIF()
# Consider to handle remaining components in DIM_FIND_COMPONENTS.
Note that due to the preparatory work on DIM_FIND_COMPONENTS and the
DIM_FIND_REQUIRED_* variables, the blocks for enabling the shared and
static component have a straight forward structure. Note further that
this can be achieved only with a quite simple package like yours with
two mutually exclusive libraries; with packages providing more subtly
related components - e.g. with inter-component dependencies - things
can be much more complicated. Note finally that the user must issue
IF(DIM_FOUND AND DIM_SHARED_FOUND)
e.g., in order to check for the library's availability unless the
REQUIRED flag was given to FIND_PACKAGE(). Checking for DIM_FOUND
or DIM_SHARED_FOUND alone is *not* reliable, just as referring to
a component that hasn't been requested explicitly - or enabled by
default which, in turn, should be documented explicitly.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to have a static/shared option in a Find script ?
On 02/15/2012 03:48 PM, Barth wrote: Hello, I am trying to write a Find script for a library called DIM. It is something basic but I have a problem with caching. I have an option to force choosing the static library over the shared one : Then, I decide what is the name of the library to search depending on DIM_USE_STATIC and I find it with find_library : The problem is that modifying DIM_USE_STATIC in ccmake doesn't work even though DIM_LIB_NAME is correct (ie. libdim.a). DIM_LIBRARY sticks to the previous value (the shared library). I know that find_library will not run again if it has already found the library in the past, thus how should I do ? Thank you in advance for your help, Barth Probably, you just need to reset DIM_LIBRARY to an empty string in ccmake each time you change DIM_USE_STATIC; see the FIND_LIBRARY() documentation for more information: If the library is found the result is stored in the variable and the search will not be repeated *unless the variable is cleared*. However, a conceptually cleaner approach is to consider the shared and the static version of a library as two components of a multi-component package, and write the find module / configuration file accordingly: (1) Use FIND_LIBRARY() to look for the shared and the static library and define DIM_SHARED_LIBRARY and DIM_STATIC_LIBRARY in the cache. (2) Inspect DIM_FIND_COMPONENTS to see which flavor has been requested, defaulting to shared if no components have been requested at all. (3) Warn or bail out if shared and static have both been requested unless they can be used together - rare but not impossible a priori. (4) DIM_USE_STATIC decides if DIM_LIBRARIES receives DIM_STATIC_LIBRARY or DIM_SHARED_LIBRARY, and because DIM_LIBRARIES is not cached, it can be set anew each time FIND_PACKAGE(DIM ...) is called, so the issue you report on will go away. IMO, most packages providing a library with shared and static versions should be considered in this manner, as this would be a robust mean to specifically select one or the other without the need to reset cache entries or bother with CMAKE_FIND_LIBRARY_SUFFIXES or the like. BTW, this approach would also account for the long-standing annoyance how to have FIND_LIBRARY() differentiate between a static library and an import library on Windows; each library type would simply have its own FIND_LIBRARY() call, and this would make things much easier. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] External project source
On 02/13/2012 09:02 AM, Nicholas Yue wrote:
On 13/02/12 6:47 PM, Eric Noulard wrote:
2012/2/13 Nicholas Yueyue.nicho...@gmail.com:
Hi,
There is an existing project I have access to that already have CMake
configuration file but the way it is written requires alot of preprocessing
steps (python, shell etc) before it is usable.
I wanted to investigate a cleaner (truer to CMake original design
purpose) usage of CMake,
So, I have an original-project directory which contains both the source
and the CMakeLists.txt in a nested directory structure.
I want to create my own CMake hierarchy (structure the same way) but
reference the source code in the original-project directory location.
How do I tell CMake to refer to source code at some other top level
directory as a starting point.
Is there such a concept in CMake ?
I am not sure to fully understand you request but in a CMakeLists.txt
you can perfectly
refer to source located outside the directory the CMakeLists.txt is in,
you can use either relative or absolute path and do something like:
add_executable(NiceTarget ../../relpath/to/source.c
${CMAKE_SOURCE_DIR}/abspath/to/another.c)
Yes, I know I can do that. I am hoping to avoid maintaining a hierarchy
of such modification.
There are 42 CMakeLists.txt files each with multiple libraries, test and
such.
I was hoping there is a way to (assuming I maintain the same hierarchy)
tell CMake to start looking for source from some other top level
directory 'once' and it will be able to find the source in the 'other'
location that is different to my 'cleaned-up' version of CMakeLists.txt
Regards
this is usually a bad idea but this should work.
Now that said if you do that for compatibility purpose in order to
maintain the legacy build
before doing the switch to genuine CMake build then may be using a
VCS like git would
be a better way to go.
I have this as a fall back.
You might consider to use your own versions of ADD_EXECUTABLE/LIBRARY()
which modify the source files' paths appropriately; see the following:
FUNCTION(ADD_EXECUTABLE name)
UNSET(args)
FOREACH(i IN LISTS ARGN)
IF(i STREQUAL WIN32
OR i STREQUAL MACOSX_BUNDLE
OR i STREQUAL EXCLUDE_FROM_ALL)
LIST(APPEND args ${i})
ELSE()
FILE(GLOB p RELATIVE ${CMAKE_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR})
LIST(APPEND args ${EXTERNAL_SOURCE_DIR}/${p}/${i})
ENDIF()
ENDFOREACH()
_ADD_EXECUTABLE(${name} ${args})
ENDFUNCTION()
FUNCTION(ADD_LIBRARY name)
UNSET(args)
FOREACH(i IN LISTS ARGN)
IF(i STREQUAL STATIC
OR i STREQUAL SHARED
OR i STREQUAL MODULE
OR i STREQUAL EXCLUDE_FROM_ALL)
LIST(APPEND args ${i})
ELSE()
FILE(GLOB p RELATIVE ${CMAKE_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR})
LIST(APPEND args ${EXTERNAL_SOURCE_DIR}/${p}/${i})
ENDIF()
ENDFOREACH()
_ADD_LIBRARY(${name} ${args})
ENDFUNCTION()
In this manner, the path of each source file is turned into a full path
pointing into the project's source tree denoted by EXTERNAL_SOURCE_DIR
and respecting the file's location within that tree. Thus, you can set
up a, say, shallow copy of the project, mimicking its directory tree
and populating it only with your adapted CMakeLists.txt files. Note
that this approach would need some refinements, e.g.:
- Be aware of source files generated in the build tree, i.e. check the
GENERATED source file property and don't modify the path if it's set.
- Be aware of source files with full paths within the project's source
tree from the first, i.e. check if paths start with CMAKE_SOURCE_DIR
and replace this prefix with your EXTERNAL_SOURCE_DIR accordingly.
Moreover, note that ADD_EXECUTABLE/LIBRARY() can be overwritten only
once. Personally, however, I would prefer Eric's suggestion to use a
repository managed by a nice branch-capable VCS like Git; IMO, this
will turn out to be much more robust and versatile in the long run.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying Files into build-dir under Visual Studio vs. Codeblocks/Win32 vs. Codeblocks/Linux
On 02/10/2012 09:41 AM, Eric Noulard wrote:
2012/2/10 Stefan Fendt ste...@sfendt.de:
Hi,
I'm (still) quite unsure if this isn't an FAQ (or if not maybe should be
one), but I have read through everything I could google-up regarding
this topic and found nothing usable...
I'm writing an x-platform-project which will be compiled using different
compilers and or under different systems... for this project I am
required to move some files from some location (source/data) into the
build-directory. Whileas this works under Linux/Codeblocks/GCC as well
as Windows/Codeblocks/MinGW it doesn't for Visual Studio... Under Visual
Studio the files always are copied to some directory-location directly
above the actual binary-directory.
I've tried using ${CMAKE_CURRENT_BINARY} and it copies the files to the
marked position:
build/--- copies into this directory
build/Debug
build/Release
build/source
After that I tried to do it with GET_TARGET_PROPERTY(... PROPERTY
LOCATION). I then get something like this...
'build/$(Configuration)'
...which of course doesn't solve the problem, too... because the
configuration under Visual Studio is only known after CMake-Generation
of the solution and running the compiler...
So, what is the suggested method of (if you can't avoid it) copying
files from anywhere into the build-directory, which is as compiler
agnostic as possible..?
You may use CMAKE_CFG_INTDIR.
Try:
cmake --help-variable CMAKE_CFG_INTDIR
You'll get some example with custom command/target.
Alternatively, you might use generator expressions in custom commands/
targets like $TARGET_FILE_DIR: Both, a generator expression and
CMAKE_CFG_INTDIR, are evaluated at build time, but the former is able
to handle the case of targets with individual output directories, i.e.
with RUNTIME_OUTPUT_DIRECTORY[_CONFIG] properties set. Thus, if you
actually intend to copy the files to the build directories of certain
targets instead of the build directory, generator expressions might
be the more robust choice.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] PARENT_SCOPE for unset()?
On 02/10/2012 03:59 PM, Robert Dailey wrote: I actually found that using the following worked the exact same for me: set( var PARENT_SCOPE ) It passed the NOT test in my if condition: if( NOT var ) ... endif() Does it pass the NOT DEFINED test, too? There's a difference between an empty and an undefined variable, and that's sometimes significant. Regards, Michael It might make more sense to require 2 parameters for set() (the variable name and its value). If setting to nothing, use a blank string. That way there is no ambiguity between PARENT_SCOPE and parameter 2. If people really want to unset the variable, I don't believe set() is the way... that's why unset() exists. Just my opinion. Only problem is, if you make this change, it isn't backward compatible and will probably break a lot of scripts. Looks like CMake is kind of boned here. Herb Sutter made a great point during GoingNative 2012 about how it's better to not have a feature than to misdesign it and be stuck supporting it forever. I think the latter part of the statement applies here :) This isn't a big deal though, just one of those if we could change it, this would make more sense kind of things. Big thanks for your help David, as usual. - Robert Dailey On Thu, Feb 9, 2012 at 6:19 PM, David Cole david.c...@kitware.com wrote: Yes, PARENT_SCOPE must occur as the last argument. Each command has its own code for processing its argument list. See Source/cmSetCommand.cxx for details on this one. Interesting (not quite the right adjective?) side effect: it's difficult to set a variable to the value PARENT_SCOPE because you have to do it indirectly... On Thu, Feb 9, 2012 at 7:12 PM, Robert Dailey rcdai...@gmail.com wrote: That worked, thanks David. I guess CMake goes right-to-left for function parameters? I don't see how else it doesn't think PARENT_SCOPE is a value instead of an option. - Robert Dailey On Thu, Feb 9, 2012 at 1:45 PM, David Cole david.c...@kitware.comwrote: On Thu, Feb 9, 2012 at 2:41 PM, Robert Dailey rcdai...@gmail.comwrote: I didn't try that because I thought it would actually treat PARENT_SCOPE as a string and add it to the variable. I did this instead: set( var PARENT_SCOPE ) That leaves it set, with a value of the empty string, in the parent scope. Give the one I sent a try. - Robert Dailey On Thu, Feb 9, 2012 at 1:26 PM, David Cole david.c...@kitware.comwrote: On Thu, Feb 9, 2012 at 2:22 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 09 February 2012, Robert Dailey wrote: It would seem useful to have a PARENT_SCOPE option for the unset() command, just like its set() counterpart. Is there a particular reason why it does not have it now? No, I think there is not particular reason. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake Does: set(var PARENT_SCOPE) have the intended effect? (If so, you could use that until such time as PARENT_SCOPE is added to unset.) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ansi color
On 02/10/2012 09:15 AM, Matt Fair wrote: I'd like to be able to pipe cmake output and still have the ansi color codes when the output is not TTY, is there a way to do this? Thanks, Matt You might do this by yourself using sed/awk/perl/... and the ANSI CSIs; refer to [1] for a similar example. Instead of multiple -e command line sed expressions, it is probably more convenient to use a sed script with one line per color as last part of your pipe. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg40328.html -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to use CMake with icc via configuration options when needing interprocedural optimization?
On 02/07/2012 02:43 PM, janitor 048 wrote:
Hello,
this is a question I recently asked on stackoverflow (
http://stackoverflow.com/questions/9129233/recommended-ways-to-use-cmake-with-icc-via-configuration-options)
but that has not received any response since then. Maybe this mailing list
is a better place to ask... Here goes
I would like to use the Intel compiler icc (or icpc) with a CMake-based
project (on Linux for what it's worth). I can of course export the CXX
variable when calling cmake, e.g. like
CXX=icpc cmake ../
and this works fine. I would however like to make this choice available via
a custom option. For this I parse custom option, e.g.
cmake -DMY_COMPILER_OPTION=Intel ..
as
IF (MY_COMPILER_OPTION STREQUAL Intel)
MESSAGE(STATUS ** Compiling with Intel settings **)
SET(CMAKE_CXX_COMPILER icpc)
SET(CMAKE_CXX_FLAGS_RELEASE -O3 -w)
SET(CMAKE_CXX_FLAGS_DEBUG -g)
ENDIF ()
and set CMAKE_CXX_COMPILER together with some compiler flags. This also
works, however there is an important but.
I would also like to use the option -ipo (interprocedural optimization) for
my code when compiling with icc plus I need to compile a static library
within the build process. For this to work, I need to use Intel's xiar (and
also xilink I guess).
cmake actually offers a special property for this
set_property(TARGET mytarget PROPERTY INTERPROCEDURAL_OPTIMIZATION 1)
however this only seems to works properly when the compiler has been set
via the environment variable (then xiar is used). When setting the compiler
via CMAKE_CXX_COMPILER this property is ignored.
Is there another way to do this?. Some recommended way? Or at least a
work-around?
If it actually works well when the compiler is specified via the
respective environment variable, you might try the following:
IF (MY_COMPILER_OPTION STREQUAL Intel)
MESSAGE(STATUS ** Compiling with Intel settings **)
SET(ENV{CXX} icpc)
SET(CMAKE_CXX_FLAGS_RELEASE -O3 -w)
SET(CMAKE_CXX_FLAGS_DEBUG -g)
ENDIF ()
However, note that you must do this *before* the language is enabled,
i.e. before the PROJECT() or ENABLE_LANGUAGE() commands. Note further
that this can be done only for the *initial* configuration of a build
tree; afterwards, the compiler can't be changed anymore. In order to
make that approach more robust, you might consider some refinements:
IF (MY_COMPILER_OPTION STREQUAL Intel)
FIND_PROGRAM(ICPC_PROGRAM icpc ...)
IF(ICPC_PROGRAM)
MESSAGE(STATUS ** Compiling with Intel settings **)
IF(ENV{CXX})
MESSAGE(WARNING Overwriting CXX envvar)
ENDIF()
SET(ENV{CXX} ${ICPC_PROGRAM})
SET(CMAKE_CXX_FLAGS_RELEASE -O3 -w)
SET(CMAKE_CXX_FLAGS_DEBUG -g)
ELSE()
MESSAGE(FATAL_ERROR Intel compiler not found)
ENDIF()
ENDIF ()
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Making a variable a dependency...
On 02/08/2012 11:13 PM, Oliver kfsone Smith wrote:
Michael Hertling said the following on 2/6/2012 6:39 PM:
On 02/06/2012 10:56 PM, Alexander Neundorf wrote:
On Saturday 04 February 2012, Oliver Smith wrote:
My CMakeLists uses the Subversion repository information in a couple of
places (it configures a file revision.h and it uses it for the CPack
package name).
The problem is that this variable is cached and retained until the cache
is rebuilt, instead of being calculated or evaluated per make. So if I
do a build, then do an svn update and pull some changes, it will build a
new executable but it will stamp it with the revision number from when
CMake last regenerated the make files...
Is there a way to mark a variable as volatile or something so that CMake
will always recalculate it and check if it has changed?
Would it be acceptable if cmake would rerun after every build ?
You could enforce that e.g. with a add_custom_command( POST_BUILD ... )
which
could e.g. touch CMakeCache.txt or something.
Better ideas ?
Delay the generation of the revision.h header until build phase
via a custom command; look at the following exemplary project:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_COMMAND(OUTPUT dummy revision.h
COMMAND ${CMAKE_COMMAND}
-DBD=${CMAKE_BINARY_DIR}
-DWC=${CMAKE_SOURCE_DIR}
-P ${CMAKE_SOURCE_DIR}/revision.cmake)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#includestdio.h
#include \revision.h\
int main(void)
{
printf(\%d\\n\,REVISION); return 0;
}
)
ADD_EXECUTABLE(main main.c revision.h)
# revision.cmake:
FIND_PACKAGE(Subversion)
Subversion_WC_INFO(${WC}@HEAD P)
FILE(WRITE ${BD}/revision.h.in #define REVISION @P_WC_REVISION@\n)
CONFIGURE_FILE(${BD}/revision.h.in ${BD}/revision.h @ONLY)
A make run rebuilds the main target whenever the repository's head
revision has changed - possibly inappropriate for actual usage, just
for demonstration purposes; adapt the revision.cmake script to suit
the needs.
BTW, can anybody confirm that the above-noted example doesn't work
if the order of dummy and revision.h in the custom command is
reversed? AFAICS, revision.h is removed after being generated in
this case, so the subsequent compilation fails.
Unless I'm missing something, that won't work because P_WC_REVISION gets
cached in the CMakeCache.txt -- or does using -P cause it to skip the
caching?
That's exactly the point: CMake scripts launched by cmake -P don't
have access to the cache - refer to the manual - so you can use the
services of FindSubversion.cmake without bothering whether variables
might be stuck in the cache or not. Try the example from my previous
reply and you'll see that P_WC_REVISION doesn't even show up in the
cache at all.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSBuild and automatic project file regenation
On 01/13/2012 08:02 PM, Michael Hertling wrote:
On 01/13/2012 03:42 PM, Bill Hoffman wrote:
On 1/13/2012 9:10 AM, Michael Hertling wrote:
With CMake 2.8.7 and VS 2008, I can report the following findings:
(1) Starting out from within an empty build directory: cmake ..
followed by cmake --build . configures/builds as expected.
(2) Tweaking CMakeLists.txt file only and leaving sources alone.
(3) cmake --build . rebuilds the ZERO_CHECK target and, thus,
updates the project file to reflect the changes from (2).
However, the corresponding target is not rebuilt and,
thus, does not reflect the changes from (2).
(4) A further cmake --build . does *nothing* - definitely.
(5) To get the concerned target rebuilt, I need to apply
David's hint, i.e. cmake . cmake --build ., or
clean first, i.e. cmake --build . --clean-first.
Can you provide an example and how to reproduce this?
I find it hard to believe that
cmake --build .
cmake --build .
will not build everything.
I get that the ZERO_TARGET does not get things to reload, but I don't
see how the second build would not get things up to date. It has
nothing to do with the project files depending on the targets. I assume
something really changed and there really needs to be a rebuild? What
type of thing are you changing in the CMakeLists.txt?
-Bill
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER); return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS NUMBER=0)
Steps to reproduce with CMake 2.8.7 and VS 2008:
(1) From within an empty build directory: cmake srcdir followed
by cmake --build . configures/builds correctly; Debug\main
yields 0 as expected.
(2) At the end of CMakeLists.txt, change NUMBER=0 to NUMBER=1.
(3) cmake --build . triggers the ZERO_CHECK target, regenerates
main.vcproj but doesn't use the latter for rebuilding main.
Accordingly, Debug\main still yields 0.
Assuming that MSBuild/devenv/whatever doesn't load the re-
generated project file into the currently running instance,
I can well understand this behavior, but:
(4) A further cmake --build . does nothing; in particular, it
does not rebuild main, and Debug\main still yields 0.
Here, I'd expect that the regenerated project file is
loaded and the associated target rebuilt.
(5) Rebuilding the main target can be achieved via David's hint
cmake . cmake --build . or by cleaning before, e.g. via
cmake --build . --clean-first. Afterwards, Debug\main
finally yields 1.
For additional information, if one modifies the main.vcproj file by
hand, a subsequent cmake --build . also does nothing, as well as
msbuild BUILD.sln /t:main or msbuild main.vcproj.
Regards,
Michael
Any findings w.r.t. this issue? Can anyone reproduce it? Is it actually
faulty behavior, possibly worth a bug report? If so, can it be fixed in
some way? David Cole mentioned something like that. Although this isn't
really disastrous, it would be quite nice if everything is up-to-date
after a cmake --build . command, as one is used to with Makefiles.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Making a variable a dependency...
On 02/06/2012 10:56 PM, Alexander Neundorf wrote:
On Saturday 04 February 2012, Oliver Smith wrote:
My CMakeLists uses the Subversion repository information in a couple of
places (it configures a file revision.h and it uses it for the CPack
package name).
The problem is that this variable is cached and retained until the cache
is rebuilt, instead of being calculated or evaluated per make. So if I
do a build, then do an svn update and pull some changes, it will build a
new executable but it will stamp it with the revision number from when
CMake last regenerated the make files...
Is there a way to mark a variable as volatile or something so that CMake
will always recalculate it and check if it has changed?
Would it be acceptable if cmake would rerun after every build ?
You could enforce that e.g. with a add_custom_command( POST_BUILD ... ) which
could e.g. touch CMakeCache.txt or something.
Better ideas ?
Delay the generation of the revision.h header until build phase
via a custom command; look at the following exemplary project:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_COMMAND(OUTPUT dummy revision.h
COMMAND ${CMAKE_COMMAND}
-DBD=${CMAKE_BINARY_DIR}
-DWC=${CMAKE_SOURCE_DIR}
-P ${CMAKE_SOURCE_DIR}/revision.cmake)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#include stdio.h
#include \revision.h\
int main(void)
{
printf(\%d\\n\,REVISION); return 0;
}
)
ADD_EXECUTABLE(main main.c revision.h)
# revision.cmake:
FIND_PACKAGE(Subversion)
Subversion_WC_INFO(${WC}@HEAD P)
FILE(WRITE ${BD}/revision.h.in #define REVISION @P_WC_REVISION@\n)
CONFIGURE_FILE(${BD}/revision.h.in ${BD}/revision.h @ONLY)
A make run rebuilds the main target whenever the repository's head
revision has changed - possibly inappropriate for actual usage, just
for demonstration purposes; adapt the revision.cmake script to suit
the needs.
BTW, can anybody confirm that the above-noted example doesn't work
if the order of dummy and revision.h in the custom command is
reversed? AFAICS, revision.h is removed after being generated in
this case, so the subsequent compilation fails.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake can't find some crtbegin.so, libgcc, libgcc_s under certain conditions
On 01/31/2012 09:14 PM, Jim Galarowicz wrote: Hi all, I'm running into issues with cmake or likely our set-up/usage of cmake, when trying to build the component based tool framework (CBTF) with cmake. The issue I'm seeing only occurs on machines where binutils-devel is not installed and I build my own version of binutils. It seems that something gets out of sync with ld and gcc. I'm on laboratory machines where I don't control the software that is installed, so that is why I'm building my own version of binutils. Has anyone seen something like this (output listed below) or has any suggestions on where to look and/or what to look for to solve this? * CMAKE OUTPUT: * -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- broken CMake Error at /global/common/hopper2/usg/cmake/2.8.2/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler /usr/bin/gcc is not able to compile a simple test program. It fails with the following output: Change Dir: /global/homes/j/jgalaro/hopper/cbtf/framework/build/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/gmake cmTryCompileExec/fast /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/global/u2/j/jgalaro/hopper/cbtf/framework/build/CMakeFiles/CMakeTmp' /global/common/hopper2/usg/cmake/2.8.2/bin/cmake -E cmake_progress_report /global/homes/j/jgalaro/hopper/cbtf/framework/build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o /usr/bin/gcc -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c /global/homes/j/jgalaro/hopper/cbtf/framework/build/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec /global/common/hopper2/usg/cmake/2.8.2/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1 /usr/bin/gcc CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o cmTryCompileExec -rdynamic /global/u2/j/jgalaro/hopper/cbtf_install/bin/ld: cannot find crtbegin.o: No such file or directory /global/u2/j/jgalaro/hopper/cbtf_install/bin/ld: cannot find -lgcc /global/u2/j/jgalaro/hopper/cbtf_install/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status gmake[1]: *** [cmTryCompileExec] Error 1 gmake[1]: Leaving directory `/global/u2/j/jgalaro/hopper/cbtf/framework/build/CMakeFiles/CMakeTmp' gmake: *** [cmTryCompileExec/fast] Error 2 In experimenting to get some clues about what is causing the cmake failures, I tried not setting PATH and LD_LIBRARY_PATH to point to my version of binutils. That didn't make a difference. I don't think the fact that binutils-devel is not installed is what tweaking the cmake build, it seems more like the alternative bintuils install that does it. I've tried setting LD_LIBRARY_PATH to point to the library location of crtbegin.so, libgcc, and libgcc_s that the cmake build complains that it can not find. But, this doesn't work either. I then added a line to the CMakeLists.txt file we have for building CBTF, but that also did not make a difference. When I play with this on my laptop, I can reproduce what I see on the laboratory machines. I've listed the build file (CMakeLists.txt) below. This is the line that I added to see if I could help cmake file the crtbegin.so, libgcc and libgcc_s: list( APPEND libSearchDirs /usr/lib64/gcc/x86_64-suse-linux/4.3) Any tips/help will be greatly appreciated. Thanks, Jim G * Shows where crtbegin.so, etc. are located. * hopper08-796lsr /usr/lib64/gcc/x86_64-suse-linux/4.3 total 35824 4 drwxr-xr-x 3 root root 4096 2010-05-05 05:44 ../ 756 -rw-r--r-- 1 root root 766626 2010-05-05 05:46 libsupc++.a 12148 -rw-r--r-- 1 root root 12420868 2010-05-05 05:46 libstdc++.a 252 -rw-r--r-- 1 root root 253440 2010-05-05 05:46 libgcc_eh.a 5824 -rw-r--r-- 1 root root 5951124 2010-05-05 05:46 libgcc.a 176 -rw-r--r-- 1 root root 174428 2010-05-05 05:46 libgcov.a 4 -rw-r--r-- 1 root root 170 2010-05-05 05:46 libgomp.spec 300 -rw-r--r-- 1 root root 299624 2010-05-05 05:46 libgomp.a 4 -rw-r--r-- 1 root root 3288 2010-05-05 05:46 crtprec80.o 4 -rw-r--r-- 1 root root 3480 2010-05-05 05:46 crtprec64.o 4 -rw-r--r-- 1 root root 3288 2010-05-05 05:46 crtprec32.o 4 -rw-r--r-- 1 root root 3320 2010-05-05 05:46
Re: [CMake] runtime dependencies for tests
On 01/31/2012 02:43 PM, Massaro Alessio wrote:
Hi There
I googled near and far, but could not find a way to tell CTest where to find
the 3rd-party DLLs required to run the test executables.
In particular my executable targets link with a few Boost DLLs/SOs and
obviously require them to run.
I understand on the Linux/Solaris I can use RPATH support in CMake.
But I can't find a way to do it on my primary target platform, WIN32-msvc9.
I've already tried several variants of calling configure_file in a function
the following way:
configure_file(${some_dbg_boost_dll_file}
${CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG} COPYONLY)
I'm open to all sorts of solutions: copy DLLs in place, set the PATH
environment variable, ... anything!
I just need a pointer to show me some way to do it.
Thank you in advance!
IMO, the easiest approach is to use the ENVIRONMENT test property to
tweak the PATH environment variable for the tests, e.g. by appending/
prepending ${Boost_LIBRARY_DIRS} etc. A more radical but cumbersome
approach is to use the BundleUtilities to perform a completed test
installation - preferably beneath the build tree - and run the tests
therein. Finally, you might copy the required libraries to the build
tree by a custom target or custom commands, or by a test on its own
in conjunction with the DEPENDS test property, but that's even more
cumbersome.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Custom configuration types in Visual Studio
On 01/17/2012 11:12 PM, Robert Dailey wrote:
Is it a bug that project() does not append to the user-specified
configurations? Sure seems like one...
Hmm, not really: How should PROJECT() differentiate if the user wants
to augment the list of configurations or to replace it completely?
ATM, that's not possible, so you have the choice only between
- setting CMAKE_CONFIGURATION_TYPES before PROJECT(), i.e. replace,
- appending to CMAKE_CONFIGURATION_TYPES after PROJECT() - invoked
without languages - but before ENABLE_LANGUAGE(), i.e. augment.
This is because Modules/Platform/Windows-cl.cmake et al. use
SET(CMAKE_CONFIGURATION_TYPES ... CACHE STRING ...)
which is a no-op if CMAKE_CONFIGURATION_TYPES is already set, so you
can replace CMake's standard configurations by your own ones. OTOH,
AFAIK, these files are loaded by PROJECT(), but enabled along with
the languages, so there's the opportunity to modify the list of
configurations between PROJECT() and ENABLE_LANGUAGE().
If you want to have both possibilities available all at once, look at
the attached patch. The USER_CONFIGURATION_TYPES variable allows for
the specification of additional configurations before PROJECT(), so
you can easily augment the list, and if you want to replace it, you
can do so as usual by presetting CMAKE_CONFIGURATION_TYPES in the
cache. Possibly, Modules/Platform/Windows-{df,ifort}.cmake would
need such a patch, too. Feel free to file a feature request.
Regards,
Michael
On Fri, Jan 13, 2012 at 4:52 PM, Michael Hertling mhertl...@online.dewrote:
On 01/13/2012 05:06 PM, David Cole wrote:
On Fri, Jan 13, 2012 at 10:22 AM, Michael Hertling mhertl...@online.de
wrote:
On 01/12/2012 10:23 PM, Robert Dailey wrote:
I see there is documentation for this but it doesn't have an
implementation
for VS generators:
http://www.cmake.org/Bug/view.php?id=5811
Any status updates on this bug? I'd like to be able to create my own
debug
configuration called DebugStatic that uses the /MTd flag in all
projects to
link statically against the Microsoft libraries such as CRT.
Any help?
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
SET(CMAKE_C_FLAGS_DEBUGSTATIC /MTd
CACHE STRING FORCE)
SET(CMAKE_EXE_LINKER_FLAGS_DEBUGSTATIC
CACHE STRING FORCE)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
After cmake srcdir and a subsequent cmake . from within the build
directory, I can see the DebugStatic configuration appear in the VS IDE
when the generated solution is opened. Is this what you intend?
However, I do not see DebugStatic when I open the solution right after
the initial configuration, i.e. without the reconfiguration step. Can
you confirm this behavior? Does anybody know why the reconfiguration
is necessary to make the custom configuration appear? This is with
CMake 2.8.7 and VS 2008.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
I don't know why it doesn't appear straight away, (although I suspect
it's because the variable is set after the project command)
Yes, that's it; placing the SET() command for CMAKE_CONFIGURATION_TYPES
before PROJECT() makes the new configuration appear at once, but it is
*solely* the new one. Apparently, CMake's standard configurations are
defined by PROJECT() only if there aren't already any configurations
in the cache. A working alternative is to drop the language(s) from
PROJECT(), augment the list of configurations thereafter and use
ENABLE_LANGUAGE() finally, i.e.:
PROJECT(XYZ) # -- No language(s) here!
LIST(APPEND CMAKE_CONFIGURATION_TYPES ...)
LIST(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES}
CACHE STRING CMake configuration types FORCE)
ENABLE_LANGUAGE(C)
But you should never do this unconditionally:
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
That will simply continuously append to the variable in the cache, and
it will grow on each subsequent configure in the same build tree...
Real code should check whether DebugStatic is in there already, and
avoiding appending if already present.
Uhhh... absolutely, bad mistake! Thanks for pointing this out.
Regards,
Michael
--- ../Windows-cl.cmake 2012-01-27 00:40:33.296549791 +0100
+++ Windows-cl.cmake 2012-01-27 00:39:52.706013041 +0100
@@ -15,7 +15,7 @@
ENDIF(CMAKE_GENERATOR MATCHES Visual Studio 6)
IF(NOT CMAKE_NO_BUILD_TYPE AND CMAKE_GENERATOR MATCHES Visual Studio)
SET
Re: [CMake] execute a script before and after configuration
On 01/21/2012 11:28 AM, Dominik Szczerba wrote:
On Sat, Jan 21, 2012 at 10:50 AM, Dominik Szczerba domi...@itis.ethz.ch
wrote:
You might use an EXECUTE_PROCESS() command at the beginning of your
CMakeLists.txt to unload the modules, and another EXECUTE_PROCESS()
at the end to reload them.
Will try, thanks for the hint!
Unfortunately, it does not work. Unloading the module via a call to a
bash script only unloads it for this script's process - the test run
is not affected. Instead of calling the script I tried sourcing it
(like 'source script', so the whole current session is affected) but
this in turn seems to somehow silently do nothing, it does not even
seem to be called.
Still dead end, any more ideas? It would be nice to have a general
elegant solution for cases where user is not allowed to directly run
their programs on the current node. Similar scenario will arise for
executing tests - currently make test fails because the tests are
built for the scheduler so will not run locally.
Regards,
Dominik
If I understand correctly - ATM, I've no access to a Cray machine, so
I can't investigate immediately - the modules are unloaded/reloaded
for the current process and its children only, but not for the CMake
process where it is actually needed, right? If so, and provided you
can figure out how to unload/reload the modules by C program code,
you might use the hardly deployed LOAD_COMMAND(), look here:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MODULES C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR})
ADD_LIBRARY(UnloadModules MODULE EXCLUDE_FROM_ALL UnloadModules.c)
SET_TARGET_PROPERTIES(UnloadModules PROPERTIES
OUTPUT_NAME cmUnloadModules)
FIND_LIBRARY(UNLOAD_MODULES_LIBRARY cmUnloadModules ${CMAKE_BINARY_DIR})
ADD_LIBRARY(ReloadModules MODULE EXCLUDE_FROM_ALL ReloadModules.c)
SET_TARGET_PROPERTIES(ReloadModules PROPERTIES
OUTPUT_NAME cmReloadModules)
FIND_LIBRARY(RELOAD_MODULES_LIBRARY cmReloadModules ${CMAKE_BINARY_DIR})
ADD_CUSTOM_TARGET(ModulesLoading)
ADD_DEPENDENCIES(ModulesLoading UnloadModules ReloadModules)
IF(UNLOAD_MODULES_LIBRARY AND RELOAD_MODULES_LIBRARY)
LOAD_COMMAND(UnloadModules ${CMAKE_BINARY_DIR})
MESSAGE(UnloadModules: ${CMAKE_LOADED_COMMAND_UnloadModules})
UNLOAD_MODULES()
EXECUTE_PROCESS(
COMMAND sh -c echo \CMake process: \$(pidof cmake)\)
ENDIF()
# Do usual stuff here.
IF(UNLOAD_MODULES_LIBRARY AND RELOAD_MODULES_LIBRARY)
LOAD_COMMAND(ReloadModules ${CMAKE_BINARY_DIR})
MESSAGE(ReloadModules: ${CMAKE_LOADED_COMMAND_ReloadModules})
RELOAD_MODULES()
EXECUTE_PROCESS(
COMMAND sh -c echo \CMake process: \$(pidof cmake)\)
ENDIF()
/* UnloadModules.c: */
#include cmCPluginAPI.h
#include unistd.h
#include stdio.h
void UnloadModulesInit(cmLoadedCommandInfo *);
static int initialpass(void *, void *, int, char *[]);
void UnloadModulesInit(cmLoadedCommandInfo *info)
{
info-Name = UNLOAD_MODULES;
info-InitialPass = initialpass;
}
static int initialpass(void *i, void *f, int argc, char *argv[])
{
printf(Unloading modules for process: %d\n,getpid());
return !0;
}
/* ReloadModules.c: */
#include cmCPluginAPI.h
#include unistd.h
#include stdio.h
void ReloadModulesInit(cmLoadedCommandInfo *);
static int initialpass(void *, void *, int, char *[]);
void ReloadModulesInit(cmLoadedCommandInfo *info)
{
info-Name = RELOAD_MODULES;
info-InitialPass = initialpass;
}
static int initialpass(void *i, void *f, int argc, char *argv[])
{
printf(Reloading modules for process: %d\n,getpid());
return !0;
}
The cmCPluginAPI.h header is the one from the CMake code base.
The basic idea is that the new commands are executed in the context of
the CMake process and, thus, can influence the latter, and this is not
true for commands spawned by EXECUTE_PROCESS(). As long as the {Un,Re}
loadModules targets aren't built, everything works as usual, but after
make ModulesLoading, a reconfiguration invokes the UNLOAD_MODULES()
and RELOAD_MODULES() commands which exemplarily shows the PID of the
CMake process. Therefore, if you manage to unload/reload the modules
via the two initialpass() functions, this might be a practicable way.
Refer to [1] for more information about such LOAD_COMMAND() plugins.
Alternatively, if it's possible to unload/reload the modules for an
arbitrary process, e.g. by module -p PID un/load , you might
use the above-noted example's means to find out the PID of the CMake
process and use it with EXECUTE_PROCESS().
A final remark: If I use the following executable CMake script
#!/bin/sh
if [ $1 != -E ]; then
echo Unloading modules
cmake -DCMAKE_COMMAND=$0 $@
echo Reloading modules
else
cmake $@
fi
for the initial configuration, I can see the {Un,Re}loading modules
messages appearing around each further automatic reconfiguration, e.g.
after touching CMakeLists.txt and rebuilding. Thus, Eike's
Re: [CMake] Revision header
On 01/21/2012 10:51 PM, Oliver Smith wrote:
I have a script that generates a revision.h file, I've spent the morning
trying to figure out how to make it so that ... any time CMake rebuilds
any of the other targets, it starts by running the make-new-revision script.
The idea is, I use the script manually to upversion, but anytime I type
make and /anything/ has to be done (even just a relink), it will do
the upversion first.
I've only managed to make it either source dependent or always build,
which forces the versionNo file to recompile and forces all executables
to relink, so if you type:
make ; make ... it will have to relink the executables the second time
because of an pointless upversion :)
- Oliver
There might be a solution for your concern, but it's probably somewhat
fragile; look at the following exemplary project for a demonstration:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(VERSIONHEADERIN ${CMAKE_SOURCE_DIR}/version.h.in)
SET(VERSIONHEADER ${CMAKE_BINARY_DIR}/version.h)
SET(VERSIONFILE ${CMAKE_BINARY_DIR}/version.txt)
IF(NOT EXISTS ${VERSIONFILE})
FILE(WRITE ${VERSIONFILE} 0\n)
ENDIF()
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR})
ADD_EXECUTABLE(main main.c)
ADD_CUSTOM_TARGET(version
${CMAKE_COMMAND}
-DVERSIONHEADERIN=${VERSIONHEADERIN}
-DVERSIONHEADER=${VERSIONHEADER}
-DVERSIONFILE=${VERSIONFILE}
-P ${CMAKE_SOURCE_DIR}/version.cmake)
ADD_DEPENDENCIES(main version)
ADD_CUSTOM_TARGET(upversion
${CMAKE_COMMAND}
-DVERSIONFILE=${VERSIONFILE}
-P ${CMAKE_SOURCE_DIR}/upversion.cmake)
# version.cmake:
FILE(STRINGS ${VERSIONFILE} VERSION)
EXECUTE_PROCESS(
COMMAND make -n VERBOSE=
COMMAND grep Linking
RESULT_VARIABLE GREPPED
)
IF(GREPPED EQUAL 0)
# Something will be done, thus:
MATH(EXPR VERSION ${VERSION}+1)
FILE(WRITE ${VERSIONFILE} ${VERSION}\n)
ENDIF()
CONFIGURE_FILE(${VERSIONHEADERIN} ${VERSIONHEADER} @ONLY)
# upversion.cmake:
FILE(STRINGS ${VERSIONFILE} VERSION)
MATH(EXPR VERSION ${VERSION}+1)
FILE(WRITE ${VERSIONFILE} ${VERSION}\n)
/* version.h.in: */
#define VERSION @VERSION@
/* main.c: */
#include version.h
#include stdio.h
int main(void)
{
printf(VERSION: %d\n,VERSION);
}
The basic idea is to run make -n (version.cmake), scan the output for
strings indicating an upcoming rebuild (Linking), increment a version
number accordingly (version.txt) and generate a version header in the
end (version.h.in). Anything else is done via the usual dependency
tracking. Additionally, the upversion.cmake script allows for
incrementing the version number manually.
Perhaps, you can adapt the approach to your needs. However, the critical
moment is how to detect if any actions which require the version number
to be incremented are going to happen. The example uses make -n and
grep for this purpose, but that's fragile, of course, as I remarked
at the outset.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] execute a script before and after configuration
On 01/20/2012 01:57 PM, Dominik Szczerba wrote: Hi, I am building a big software framework on a cray system whereby during cmake configuration phase I need to unload certain system modules (so that some small test programs are allowed to run without scheduler) and afterwards, before the actual build phase starts, I need to load them back. Doing it manually is troublesome, because sometimes typing make triggers cmake to re-run, and then re-build, so there is no chance to load/unload the modules. So, how would I force one script to run when cmake is started and one other script before build starts? Many thanks for any directions. Dominik You might use an EXECUTE_PROCESS() command at the beginning of your CMakeLists.txt to unload the modules, and another EXECUTE_PROCESS() at the end to reload them. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compile multiple-sources at a time?
On 01/19/2012 11:09 PM, Oliver kfsone Smith wrote: I realize not every build environment supports the option, but is there a way to get CMake to generate Makefiles which aggregate source files, e.g. $ g++ -pipe -o library.a lib1.cpp lib2.cpp lib3.cpp $ g++ -pipe -o exeutable file1.cpp file2.cpp file3.cpp library.a - Oliver Aggregating source files in this way fundamentally collides with the concept of source file properties, a well-established CMake feature. Thus, it would require a check if the aggregated source files are to be compiled with exactly the same flags/definitions/etc. If not, one would need to trade off aggregation against source file properties, perhaps by use of a variable/property/policy or whatever solution might suit. Not that trivial, IMO. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: building libs and specifying addition folders
On 01/19/2012 08:15 AM, Dev Guy wrote: On Thu, Jan 19, 2012 at 1:01 AM, John Drescher dresche...@gmail.com wrote: -- Forwarded message -- From: John Drescher dresche...@gmail.com Date: Thu, Jan 19, 2012 at 1:00 AM Subject: Re: [CMake] building libs and specifying addition folders To: Dev Guy devguy...@gmail.com On Wed, Jan 18, 2012 at 10:57 PM, Dev Guy devguy...@gmail.com wrote: Hi, I am relatively new to CMake and I've read the tutorial. However I have a few questions. 1. How can I declare a CMakeLists file to create a project to build a DLL or static lib ? I assume if I build a DLL on windows, it will build as a shared lib on Linux put SHARED in the add_library statement For more info than that type the following from a command prompt or shell: cmake --help-command add_library 2. If my main source folder has 2 sub-folders, one that only includes header files call is Include and another folder that contains source files call it Utils. How do I add declare them to my CMakeLists files so that both the header and addition source files are found and and compiled in the main source folder to build the final binary. add_subdirectory Again for help: cmake --help-command add_subdirectory John -- John M. Drescher -- John thanks, I was able to get a DLL built, now I have a program that want to link against the lib and use the DLL. What I've done is create a Lib folder under the source folder wanting to use the lib, I copied over the lib find and header file. I added the following to CMakeLists.txt add_subdirectory(Lib) target_link_libraries (SimpleTester UnitTest) However I am seeing 2 errors: Error 1, when I run CMake I see: CMake Warning (dev) at CMakeLists.txt:6 (add_subdirectory): The source directory C:/dev/Project/UnitTestSample/Lib does not contain a CMakeLists.txt file. CMake does not support this case but it used to work accidentally and is being allowed for compatibility. Policy CMP0014 is not set: Input directories must have CMakeLists.txt. Run cmake --help-policy CMP0014 for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring done -- Generating done -- Build files have been written to: C:/dev/Project/UnitTestSample/build == Error 2 When I build I get a link error, which I fix by copying over the lib file into the build folder. How can I tell the linker from CMake where to find the lib? LINK : fatal error LNK1104: cannot open file 'UnitTest.lib' LINK Pass 1 failed. with 2 NMAKE : fatal error U1077: 'C:\Program Files\CMake 2.8\bin\cmake.exe' : return code '0x' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.exe' : retu rn code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.exe' : retu rn code '0x2' Stop. Could you provide a small but self-sufficient exemplary project which demonstrates what you're doing and allows for further investigation? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] shared library with CMake in kdevelop4
On 01/16/2012 02:38 PM, paspa...@noos.fr wrote:
I am new with kdevelop and cmake so apologize for this pretty naive question,
I
create in kdevelop a proj3 project and want to link a library so I create a
second project projA within the proj3 directory
the projA CMakelist is
project(proja)
set( lib_SOURCES Execute_Msg.cpp )
add_library(proja ${lib_SOURCES} )
If you want to get a shared library, you should state this explicitly:
ADD_LIBRARY(proja SHARED ${lib_SOURCES} )
Also see the BUILD_SHARED_LIBS variable.
the proj3 CMakelist is
cmake_minimum_required(VERSION 2.8)
project(proj3)
link_directories(/pascal/pKD3/proj3/projA/build)
Never use LINK_DIRECTORIES(), it's unnecessary and dangerous. Instead,
you need ADD_SUBDIRECTORIES(projA) here to make projA known to proj3.
add_executable(proj3 main.cpp)
target_link_libraries(proj3 libproja)
In TARGET_LINK_LIBRARIES(), refer to targets to link against
by their *target names*, not by their *file names*, i.e.:
TARGET_LINK_LIBRARIES(proj3 proja)
there is a libproja file in the /pascal/pKD3/proj3/projA/build directory, so
I
don't understand why I get the message /usr/bin/ld: cannot find -llibproja
This is because ld searches a quite restricted set of directories for
libraries specifed by -l; particularly, it doesn't search the current
directory. If you specify targets by their target names, CMake uses
full paths in the linker command lines, so there will be no issue.
thanks for help
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] shared library with CMake in kdevelop4
On 01/16/2012 04:23 PM, paspa...@noos.fr wrote:
Thank you michael
in fact at the beginning I wanted just to do a static local library
(I am totally new with cmake, before I didn't use that kind of tools with VS
and
recently netbeans)
finally according to your suggestions I wrote:
projA
project(proja)
add_library(proja Execute_Msg.cpp)
If you definitely want a static library: ADD_LIBRARY(proja STATIC ...)
Without the explicit SHARED/STATIC keyword, the type of the resulting
library is determined by the BUILD_SHARED_LIBS variable which can be
controlled by the user; this might possibly be undesired.
proj3
cmake_minimum_required(VERSION 2.8)
project(proj3)
add_subdirectory(projA)
add_executable(proj3 main.cpp)
target_link_libraries(proj3 proja)
and it works
thanks again
pascal
Regards,
Michael
PS: Please don't drop the ML.
Message d'origine
De : Michael Hertling mhertl...@online.de
À : cmake@cmake.org
Objet : Re: [CMake] shared library with CMake in kdevelop4
Date : 16/01/2012 15:39:29 CET
On 01/16/2012 02:38 PM, paspa...@noos.fr wrote:
I am new with kdevelop and cmake so apologize for this pretty naive
question, I
create in kdevelop a proj3 project and want to link a library so I create
a
second project projA within the proj3 directory
the projA CMakelist is
project(proja)
set( lib_SOURCES Execute_Msg.cpp )
add_library(proja ${lib_SOURCES} )
If you want to get a shared library, you should state this explicitly:
ADD_LIBRARY(proja SHARED ${lib_SOURCES} )
Also see the BUILD_SHARED_LIBS variable.
the proj3 CMakelist is
cmake_minimum_required(VERSION 2.8)
project(proj3)
link_directories(/pascal/pKD3/proj3/projA/build)
Never use LINK_DIRECTORIES(), it's unnecessary and dangerous. Instead,
you need ADD_SUBDIRECTORIES(projA) here to make projA known to proj3.
add_executable(proj3 main.cpp)
target_link_libraries(proj3 libproja)
In TARGET_LINK_LIBRARIES(), refer to targets to link against
by their *target names*, not by their *file names*, i.e.:
TARGET_LINK_LIBRARIES(proj3 proja)
there is a libproja file in the /pascal/pKD3/proj3/projA/build directory,
so I
don't understand why I get the message /usr/bin/ld: cannot find
-llibproja
This is because ld searches a quite restricted set of directories for
libraries specifed by -l; particularly, it doesn't search the current
directory. If you specify targets by their target names, CMake uses
full paths in the linker command lines, so there will be no issue.
thanks for help
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSBuild and automatic project file regenation
On 01/10/2012 07:09 PM, Óscar Fuentes wrote: Michael Hertling mhertl...@online.de writes: But aren't the issues related at least? Dunno. If I understand correctly, cmake --build invokes MSBuild which - loads the solution file and the project files, - reinvokes CMake via the ZERO_CHECK project/target to regenerate them if CMakeLists.txt has been modified, - does *not* use the regenerated ones for building, so the affected projects/targets are left inherently out-of-date. Yep. Moreover, even an additional subsequent cmake --build command doesn't rebuild; in fact, it does nothing, as though there is no dependency of a project/target on its own project file. That doesn't happen here. The next cmake --build works fine (cmake 2.8.4, VS 10) With CMake 2.8.7 and VS 2008, I can report the following findings: (1) Starting out from within an empty build directory: cmake .. followed by cmake --build . configures/builds as expected. (2) Tweaking CMakeLists.txt file only and leaving sources alone. (3) cmake --build . rebuilds the ZERO_CHECK target and, thus, updates the project file to reflect the changes from (2). However, the corresponding target is not rebuilt and, thus, does not reflect the changes from (2). (4) A further cmake --build . does *nothing* - definitely. (5) To get the concerned target rebuilt, I need to apply David's hint, i.e. cmake . cmake --build ., or clean first, i.e. cmake --build . --clean-first. As I've already said previously, this seems as if there's no dependency of the target on its own project file. Moreover, I don't understand why rebuilding the ZERO_CHECK project and reconfiguring with cmake . do obviously have different results - the latter makes cmake --build . rebuild, the former doesn't. If I understand correctly, the purpose of ZERO_CHECK is to rerun CMake in order to update the project files, so the cmake --build . from (4) - at the lastest - should rebuild the affected targets. AFAICS for now, it's solely David's hint, i.e. cmake . cmake --build ., that results in the project being actually rebuilt after CMakeLists.txt has changed, unless one uses the --clean-first option. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. Do you file a feature request / bug report? Nope. Personally, I'd like to be sure that after a cmake --build command, everything is up-to-date as it is with Makefiles, provided it can be realized with MSBuild at all. Obviously, how MSBuild works when the project files are regenerated on the fly is a bug. I have no idea about how hard is to fix it, though. Try http://www.cmake.org/pipermail/cmake/2011-November/047802.html. Hmmm... After reading your example, I can't say for sure that when `cmake --build' worked the second time here it didn't cointain changes on the source files too. CMake with VS 10 and/or MSBuild is pesky, apart from the problems MSBuild has on its own. I'm looking at using other generators that support parallel builds. JOM is not truly parallel (it only builds a toplevel target at once). Ninja looks like the right thing, but doesn't work on MS Windows. Perhaps, David Cole can give us some enlightenment; since he used to work for MS, he certainly has some intimate insights into the Visual World. ;-) Anyway, this issue is no catastrophe, provided one knows the trick with cmake . cmake --build ., but it is annoying and error-prone; usually, I'd expect that after cmake --build, every- thing is up-to-date. BTW, does cmake --build work correctly in this regard with other non-Makefile generators, notably XCode? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Custom configuration types in Visual Studio
On 01/12/2012 10:23 PM, Robert Dailey wrote:
I see there is documentation for this but it doesn't have an implementation
for VS generators:
http://www.cmake.org/Bug/view.php?id=5811
Any status updates on this bug? I'd like to be able to create my own debug
configuration called DebugStatic that uses the /MTd flag in all projects to
link statically against the Microsoft libraries such as CRT.
Any help?
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
SET(CMAKE_C_FLAGS_DEBUGSTATIC /MTd
CACHE STRING FORCE)
SET(CMAKE_EXE_LINKER_FLAGS_DEBUGSTATIC
CACHE STRING FORCE)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
After cmake srcdir and a subsequent cmake . from within the build
directory, I can see the DebugStatic configuration appear in the VS IDE
when the generated solution is opened. Is this what you intend?
However, I do not see DebugStatic when I open the solution right after
the initial configuration, i.e. without the reconfiguration step. Can
you confirm this behavior? Does anybody know why the reconfiguration
is necessary to make the custom configuration appear? This is with
CMake 2.8.7 and VS 2008.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSBuild and automatic project file regenation
On 01/13/2012 03:42 PM, Bill Hoffman wrote:
On 1/13/2012 9:10 AM, Michael Hertling wrote:
With CMake 2.8.7 and VS 2008, I can report the following findings:
(1) Starting out from within an empty build directory: cmake ..
followed by cmake --build . configures/builds as expected.
(2) Tweaking CMakeLists.txt file only and leaving sources alone.
(3) cmake --build . rebuilds the ZERO_CHECK target and, thus,
updates the project file to reflect the changes from (2).
However, the corresponding target is not rebuilt and,
thus, does not reflect the changes from (2).
(4) A further cmake --build . does *nothing* - definitely.
(5) To get the concerned target rebuilt, I need to apply
David's hint, i.e. cmake . cmake --build ., or
clean first, i.e. cmake --build . --clean-first.
Can you provide an example and how to reproduce this?
I find it hard to believe that
cmake --build .
cmake --build .
will not build everything.
I get that the ZERO_TARGET does not get things to reload, but I don't
see how the second build would not get things up to date. It has
nothing to do with the project files depending on the targets. I assume
something really changed and there really needs to be a rebuild? What
type of thing are you changing in the CMakeLists.txt?
-Bill
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#include stdio.h
int main(void)
{
printf(\%d\\n\,NUMBER); return 0;
}
)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS NUMBER=0)
Steps to reproduce with CMake 2.8.7 and VS 2008:
(1) From within an empty build directory: cmake srcdir followed
by cmake --build . configures/builds correctly; Debug\main
yields 0 as expected.
(2) At the end of CMakeLists.txt, change NUMBER=0 to NUMBER=1.
(3) cmake --build . triggers the ZERO_CHECK target, regenerates
main.vcproj but doesn't use the latter for rebuilding main.
Accordingly, Debug\main still yields 0.
Assuming that MSBuild/devenv/whatever doesn't load the re-
generated project file into the currently running instance,
I can well understand this behavior, but:
(4) A further cmake --build . does nothing; in particular, it
does not rebuild main, and Debug\main still yields 0.
Here, I'd expect that the regenerated project file is
loaded and the associated target rebuilt.
(5) Rebuilding the main target can be achieved via David's hint
cmake . cmake --build . or by cleaning before, e.g. via
cmake --build . --clean-first. Afterwards, Debug\main
finally yields 1.
For additional information, if one modifies the main.vcproj file by
hand, a subsequent cmake --build . also does nothing, as well as
msbuild BUILD.sln /t:main or msbuild main.vcproj.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Custom configuration types in Visual Studio
On 01/13/2012 05:06 PM, David Cole wrote:
On Fri, Jan 13, 2012 at 10:22 AM, Michael Hertling mhertl...@online.de
wrote:
On 01/12/2012 10:23 PM, Robert Dailey wrote:
I see there is documentation for this but it doesn't have an implementation
for VS generators:
http://www.cmake.org/Bug/view.php?id=5811
Any status updates on this bug? I'd like to be able to create my own debug
configuration called DebugStatic that uses the /MTd flag in all projects to
link statically against the Microsoft libraries such as CRT.
Any help?
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
SET(CMAKE_C_FLAGS_DEBUGSTATIC /MTd
CACHE STRING FORCE)
SET(CMAKE_EXE_LINKER_FLAGS_DEBUGSTATIC
CACHE STRING FORCE)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
After cmake srcdir and a subsequent cmake . from within the build
directory, I can see the DebugStatic configuration appear in the VS IDE
when the generated solution is opened. Is this what you intend?
However, I do not see DebugStatic when I open the solution right after
the initial configuration, i.e. without the reconfiguration step. Can
you confirm this behavior? Does anybody know why the reconfiguration
is necessary to make the custom configuration appear? This is with
CMake 2.8.7 and VS 2008.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
I don't know why it doesn't appear straight away, (although I suspect
it's because the variable is set after the project command)
Yes, that's it; placing the SET() command for CMAKE_CONFIGURATION_TYPES
before PROJECT() makes the new configuration appear at once, but it is
*solely* the new one. Apparently, CMake's standard configurations are
defined by PROJECT() only if there aren't already any configurations
in the cache. A working alternative is to drop the language(s) from
PROJECT(), augment the list of configurations thereafter and use
ENABLE_LANGUAGE() finally, i.e.:
PROJECT(XYZ) # -- No language(s) here!
LIST(APPEND CMAKE_CONFIGURATION_TYPES ...)
LIST(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES}
CACHE STRING CMake configuration types FORCE)
ENABLE_LANGUAGE(C)
But you should never do this unconditionally:
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
CACHE STRING FORCE)
That will simply continuously append to the variable in the cache, and
it will grow on each subsequent configure in the same build tree...
Real code should check whether DebugStatic is in there already, and
avoiding appending if already present.
Uhhh... absolutely, bad mistake! Thanks for pointing this out.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How not to copy a link
On 01/11/2012 04:52 PM, David Cole wrote:
On Wed, Jan 11, 2012 at 10:10 AM, Michael Hertling mhertl...@online.de
wrote:
On 01/07/2012 03:52 PM, David Cole wrote:
On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de
wrote:
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
It works if you use:
GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)
I'm not 100% sure if the behavior is expected to be defined for
non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
try to remember to ask him about it on Monday.
HTH,
David
It appears to be resolved w.r.t. the current *source* directory when
you do not give the full path, and since xyz.dat does not actually
exist in the source dir, there's no way we can know that it is
supposed to be a symlink.
But get_filename_component has to work with non-existing files since
some people need that simply to compute where files should go, or what
other file's base names should be based on CMake variables alone...
Hope that explains it better.
Yes, it does; thanks for straightening this out. Actually, it's rather
obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT()
do need a reference point, but perhaps, one should document explicitly
that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR
won't be taken into account. Elsewhere, CMake behaves differently.
Is it CMAKE_CURRENT_SOURCE_DIR? Or is it the current working directory
of the cmake process, which happens to be CMAKE_CURRENT_SOURCE_DIR
when you make the call ...?
Because of questions like these, I asked for refined documentation. ;)
AFAICS from the source code, a relative path is evaluated w.r.t. CMAKE_
CURRENT_SOURCE_DIR only. Anyway, the ABSOLUTE clause has made me think
that it is mainly meant to be used on relative paths, and if it is to
work on non-existing files, too, it needs a single reference point to
evaluate against. Actually, such facts should be mentioned in the docs
since they are essential if ABSOLUTE/REALPATH are to be used correctly.
I know it's *possible* to use non-full paths in many contexts within
CMake and still get the results you expect, but because of little
nuggets like this, ...
... I always, always, always use full paths anyway, unconditionally. [...]
With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously...
Yes, even with them. Exception: when I'm editing
Re: [CMake] Cmake coloring gcc output on errror
On 01/10/2012 07:17 PM, vivek goel wrote:
Is there a way to color warning/error of gcc with cmake ?
AFAIK, no, but you might remember the power of *nix, feed the output
of make VERBOSE=1 21 into sed/awk/perl/your-favorite-here and
use ANSI Control Sequence Initiators:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){Return 0;}\n)
SET_SOURCE_FILES_PROPERTIES(main.c PROPERTIES COMPILE_FLAGS -Wall)
ADD_EXECUTABLE(main main.c)
% cmake srcdir
...
% make VERBOSE=1 21 | sed \
-e 's%^.*: error: .*$%\x1b[37;41m\x1b[m%' \
-e 's%^.*: warning: .*$%\x1b[30;43m\x1b[m%'
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How not to copy a link
On 01/07/2012 03:52 PM, David Cole wrote:
On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de
wrote:
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
It works if you use:
GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)
I'm not 100% sure if the behavior is expected to be defined for
non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
try to remember to ask him about it on Monday.
HTH,
David
It appears to be resolved w.r.t. the current *source* directory when
you do not give the full path, and since xyz.dat does not actually
exist in the source dir, there's no way we can know that it is
supposed to be a symlink.
But get_filename_component has to work with non-existing files since
some people need that simply to compute where files should go, or what
other file's base names should be based on CMake variables alone...
Hope that explains it better.
Yes, it does; thanks for straightening this out. Actually, it's rather
obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT()
do need a reference point, but perhaps, one should document explicitly
that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR
won't be taken into account. Elsewhere, CMake behaves differently.
I know it's *possible* to use non-full paths in many contexts within
CMake and still get the results you expect, but because of little
nuggets like this, ...
... I always, always, always use full paths anyway, unconditionally. [...]
With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously...
[...] I
always recommend to everyone that they also adopt this CMake best
practice of referring to files by their full path names whenever
possible. It eliminates confusion, ambiguity and unintended mistaken
results -- and is 100% absolutely worth the effort.
Definitely agreed, but there're some commands which are typically used
with relative paths, although it's not explicitly documented how they
behave in this respect. Notable examples are the already mentioned
ADD_EXECUTABLE/LIBRARY() or SET_SOURCE_FILES_PROPERTIES() - IMO, the
latter should behave in the same manner as the formers, so one can use
the same source file specifications. Perhaps, one could add a few lines
to the documentation in order to clarify for which commands/properties/
etc. a relative path does behave well, e.g. like for ADD_SUBDIRECTORY().
Regards,
Michael
Re: [CMake] MSBuild and automatic project file regenation
On 01/09/2012 02:34 PM, David Cole wrote: On Sun, Jan 8, 2012 at 11:59 PM, Óscar Fuentes o...@wanadoo.es wrote: When MSBuild.exe is used (typically by cmake --build) for building a VS2010 project generated by cmake, it correctly invokes cmake for regenerating the project files if changes to the CMakeLists.txt files are detected. However, the build does not restart nor abort, so MSBuild continues using the outdated project files that it previously read, ending some time later with lots of error messages from the compiler or linker, hence wasting time, causing confusion and making difficult to notice that a regeneration had happened. Is there any trick for stopping MSBuild as soon as cmake ends regenerating the project files? -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake No trick, but to avoid this, perhaps we should change the --build handler to run the cmake configure generate step before calling out to MSBuild. You can easily do this yourself from the command line by adopting the pattern: cmake . cmake --build . --config Release This is a good idea for a feature request. Not sure if we should just always do that by default and provide a way to turn off with a --no-regenerate, or vice-versa with a --please-generate-first ... :-) HTH, David Just out of curiosity: In [1], item (1), I reported on the fact that one can modify a project's CMakeLists.txt, and cmake --build will reconfigure/regenerate, but not rebuild. Is this the same issue the OP asks about? If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying of 3rd party DLLs in a POST-BUILD step
On 01/09/2012 10:05 AM, Michael Stürmer wrote:
I have found some topics related to my issue on the web, but none so far
helped me to fix it:
I use Visual Studio 2010 on Windows 7 64Bit.
During my build, all binaries are collected in one folder, which makes it
easier for me to debug the project. But to be able to run the program
actually, I have to copy several dlls (like Qt, openCV etc.) into the folder
for the program to find them. Putting the libraries in the system path is not
an option for me, as I switch between 32- and 64-bit on the same system.
I managed to locate the folder where the dlls are (using some
CMake-Variables) and using a custom command like
ADD_CUSTOM_COMMAND( TARGET CopyDlls POST_BUILD
COMMAND copy ${DLL_3RD}/*.dll
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$CONFIGURATION
COMMENT copying dlls .
)
This copies ALL dlls from the ${DLL_3RD} folder to the binary folder, for Qt
that would be the relase as well as the debug libraries.
Now my question:
I would like to only copy those dlls I need, i.e. I have to determine somehow
if I'm in debug or release mode and select the appropriate libraries by
adding d for debug versions. For openCV I need opencv_core231.dll in
release and opencv_core231d.dll in debug mode. Does anyone have a
solution/workaround/idea for this problem?
Best regards,
Michael
Perhaps, you might perform a temporary installation for debugging
purposes and use the BundleUtilities for this installation only:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
INSTALL(TARGETS main DESTINATION bin)
INSTALL(CODE
IF(CMAKE_INSTALL_PREFIX STREQUAL \${CMAKE_BINARY_DIR}/debuginstall\)
MESSAGE(\Use BundleUtilities here\)
ENDIF()
)
If you specify ${CMAKE_BINARY_DIR}/debuginstall as CMAKE_INSTALL_PREFIX,
the BundleUtilities are included - if you replace the MESSAGE() command,
of course - and should do the job. Otherwise, i.e. with different CMAKE_
INSTALL_PREFIX, the installation runs as usual. In this way, you do not
need an installation component or the like to have CMake recognize your
special debugging installation. The downside is that you've to rebuild
the project with the final CMAKE_INSTALL_PREFIX when performing the
real installation, but usually, you do this anyway in order to
switch from the debug configuration to the release one.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSBuild and automatic project file regenation
On 01/09/2012 07:56 PM, Óscar Fuentes wrote: Michael Hertling mhertl...@online.de writes: On 01/09/2012 02:34 PM, David Cole wrote: No trick, but to avoid this, perhaps we should change the --build handler to run the cmake configure generate step before calling out to MSBuild. You can easily do this yourself from the command line by adopting the pattern: cmake . cmake --build . --config Release Fortunately my cmake scripts are simple enough so the extra invocation does not add much to the build. Thanks David. This is a good idea for a feature request. Not sure if we should just always do that by default and provide a way to turn off with a --no-regenerate, or vice-versa with a --please-generate-first ... :-) The effect of --no-regenerate would be the same as the current buggy behavior (MSBuild.exe uses outdated project files). IMHO the --please-generate-first is the right thing. Just out of curiosity: In [1], item (1), I reported on the fact that one can modify a project's CMakeLists.txt, and cmake --build will reconfigure/regenerate, but not rebuild. Is this the same issue the OP asks about? No. But aren't the issues related at least? If I understand correctly, cmake --build invokes MSBuild which - loads the solution file and the project files, - reinvokes CMake via the ZERO_CHECK project/target to regenerate them if CMakeLists.txt has been modified, - does *not* use the regenerated ones for building, so the affected projects/targets are left inherently out-of-date. Moreover, even an additional subsequent cmake --build command doesn't rebuild; in fact, it does nothing, as though there is no dependency of a project/target on its own project file. AFAICS for now, it's solely David's hint, i.e. cmake . cmake --build ., that results in the project being actually rebuilt after CMakeLists.txt has changed, unless one uses the --clean-first option. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. Do you file a feature request / bug report? Personally, I'd like to be sure that after a cmake --build command, everything is up-to-date as it is with Makefiles, provided it can be realized with MSBuild at all. [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html This returns 404. Try http://www.cmake.org/pipermail/cmake/2011-November/047802.html. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to setup cmake_c/xx_flags per toolchain?
On 01/07/2012 12:56 AM, Paweł Sikora wrote:
Hi,
i'm trying to setup a toolchain file for cross-compilation with target specfic
options and afaics cmake dosen't use flags from such file:
$ cat CMakeLists.txt
cmake_minimum_required( VERSION 2.8.7 )
project( test CXX )
add_executable( main main.cpp )
$ cat CMakeToolchain-x86_64-gnu-linux.txt
set( CMAKE_SYSTEM_NAME Linux )
set( CMAKE_SYSTEM_VERSION 1 )
set( CMAKE_CXX_COMPILER
/local/devel/toolchain46/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ )
set( CMAKE_CXX_FLAGS -Wall -O1 -gdwarf-4 -g2 -std=gnu++0x )
set( CMAKE_FIND_ROOT_PATH /usr )
$ LANG=C sh -x ./build.sh
+ rm -rf build
+ mkdir build
+ cd build
+ cmake ../ -DCMAKE_TOOLCHAIN_FILE=../CMakeToolchain-x86_64-gnu-linux.txt
-- The CXX compiler identification is GNU
-- Check for working CXX compiler:
/local/devel/toolchain46/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++
-- Check for working CXX compiler:
/local/devel/toolchain46/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
(...)
[100%] Building CXX object CMakeFiles/main.dir/main.cpp.o
/local/devel/toolchain46/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -o
CMakeFiles/main.dir/main.cpp.o -c
/home/users/pluto/src/cmake-cross-build/main.cpp
^^^ no cxx
flags.
is it a bug or a feature?
BR,
Paweł.
Try SET(CMAKE_CXX_FLAGS ... CACHE STRING ...) in the toolchain
file, and cf. [1]. AFAIK, the toolchain file is processed first,
but later in CMakeCXXInformation.cmake:
# Load compiler-specific information.
IF(CMAKE_CXX_COMPILER_ID)
INCLUDE(Compiler/${CMAKE_CXX_COMPILER_ID}-CXX OPTIONAL)
ENDIF(CMAKE_CXX_COMPILER_ID)
This loads Compiler/GNU-CXX.cmake and subsequently Compiler/GNU.cmake
which empties CMAKE_CXX_FLAGS_INIT. Again later in the same file:
# add the flags to the cache based
# on the initial values computed in the platform/*.cmake files
# use _INIT variables so that this only happens the first time
# and you can set these flags in the cmake cache
SET(CMAKE_CXX_FLAGS_INIT $ENV{CXXFLAGS} ${CMAKE_CXX_FLAGS_INIT})
# avoid just having a space as the initial value for the cache
IF(CMAKE_CXX_FLAGS_INIT STREQUAL )
SET(CMAKE_CXX_FLAGS_INIT)
ENDIF(CMAKE_CXX_FLAGS_INIT STREQUAL )
SET (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_INIT} CACHE STRING
Flags used by the compiler during all build types.)
If CMAKE_CXX_FLAGS is not cached by that time, the SET() command sets
this variable to CMAKE_CXX_FLAGS_INIT, both in the cache *and* in the
current scope, thus overwriting the value from the toolchain file and
having CMAKE_CXX_FLAGS be empty. Already writing it to the cache in
the toolchain file makes the incriminated SET() command a no-op, so
the desired value will survive. However, I'm not completely sure if
this is the intended way to handle language flags when they are to
be preset in a toolchain file.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg33240.html
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How not to copy a link
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with set_source_files_properties
On 01/05/2012 02:42 PM, Mateusz Loskot wrote:
On 5 January 2012 12:31, vivek goel goelvivek2...@gmail.com wrote:
I am using code
where f contains the file name
set(MY_PATH -D__RELATIVE_PATH__=\\\ab\\\)
set_source_files_properties(${f} PROPERTIES
COMPILE_FLAGS ${MY_PATH})
I am not able to see -D__RELATIVE_PATH__ inside compilation flags.
You have read the 2nd paragraph of COMPILE_FLAGS section in manual, haven't
you.
Best regards,
Although COMPILE_FLAGS is not meant to specify definitions,
it usually works; look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
SET_SOURCE_FILES_PROPERTIES(main.c
PROPERTIES COMPILE_FLAGS -D__RELATIVE_PATH__=\\\ab\\\)
Make's output reveals:
.../gcc -D__RELATIVE_PATH__=\ab\ -o .../main.c.o -c .../main.c
Vivek, perhaps a mistake with regard to the variable f? BTW, note
that the COMPILE_DEFINITIONS properties take account for proper
escaping and then some; the COMPILE_FLAGS ones don't, AFAIK.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interrupt problems in cmake-gui
On 12/31/2011 02:10 AM, Robert Dailey wrote: I'd like to introduce boost into CMake for this. Whenever I've advocated CMake as build system, one of the strongest selling points has been its self-sufficiency, i.e. the fact that it does not have any external dependencies except for a C++ environment. IMO, each further dependency on external packages - be it Boost, be it Qt or what ever - would compromise CMake's chances to be preferred to other build systems. For this reason, I'd support Bill's position and recommend to be particularly conservative w.r.t. the introduction of additional dependencies into the CMake executable. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to install then test?
On 12/29/2011 08:01 PM, Denis Scherbakov wrote:
Dear All!
Maybe someone can help me: I have a project, we compile binaries and then
using various INSTALL directives finish the job by copying files where they
belong: to bin, man, libexec, etc. The point is, we need to run
executables after they got installed into this tree, because otherwise
they won't find all auxiliary files during runtime.
So I am really missing the point here: how to install files (to a temporary
directory, for example) and then run various tests? Maybe someone has ideas...
Sincerely,
Denis
As an alternative to what Eric has already suggested, you might use
installation components or POST_BUILD custom commands to achieve a
temporary installation for testing purposes:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ENABLE_TESTING()
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
# Target main1:
ADD_EXECUTABLE(main1 main.c)
INSTALL(TARGETS main1 DESTINATION bin
COMPONENT main)
INSTALL(TARGETS main1 DESTINATION ${CMAKE_BINARY_DIR}/test/bin
COMPONENT test)
ADD_CUSTOM_TARGET(install.main ${CMAKE_COMMAND}
-DCOMPONENT=main -P ${CMAKE_BINARY_DIR}/cmake_install.cmake)
ADD_CUSTOM_TARGET(install.test ${CMAKE_COMMAND}
-DCOMPONENT=test -P ${CMAKE_BINARY_DIR}/cmake_install.cmake)
ADD_TEST(NAME main1
COMMAND ${CMAKE_BINARY_DIR}/test/bin/$TARGET_FILE_NAME:main1)
# Target main2:
ADD_EXECUTABLE(main2 main.c)
ADD_CUSTOM_COMMAND(TARGET main2 POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
$TARGET_FILE:main2
${CMAKE_BINARY_DIR}/test/bin/$TARGET_FILE_NAME:main2)
INSTALL(TARGETS main2 DESTINATION bin)
ADD_TEST(NAME main2
COMMAND ${CMAKE_BINARY_DIR}/test/bin/$TARGET_FILE_NAME:main2)
For target main1, there're the installation components main and
test, each one triggered via a custom target as usual. Component
main does the regular installation, and component test installs
to a temporary location where the test main1 looks for the main1
executable. The downside of this approach is that the installation
components are part of the common install target - therefor the
additional install.main component - and you need to trigger the
install.test target before testing because of issue #8438, as
Eric has already pointed out.
The binary built by target main2 is copied to a temporary location
via a POST_BUILD custom command, so the test main2 is able to find
it there. Probably, this approach is less complicated than the first
one and won't compromise the common install target with additional
installation components, but you may lose the benefits of the quite
powerful INSTALL() command for the temporary installation.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] RC compiler on Linux - new problem
On 01/04/2012 02:08 PM, pellegrini wrote:
Hi Michael
first of all best wishes for 2012 !
Thanks, the same to you!
Let's start 2012 with a new question for CMake community ! It is related
with prior discussions we had about rc
compiler on Linux. Sorry but I had many things to do in the meantime and
I could only come back to it recently.
As a reminder, my problem was:
- I must use the winteracter Fortran library resource compiler
- it does not accept any output flag so that the output resource
object is always created in-source
- on Linux, it produces a .o object file instead of a .res file
which mess up the rc process of CMake
I tried your last suggestion that was to create a wrapper script and use
it as the RC when I set the WINTERACTER_RC_COMPILER variable. My
CMakeLists.txt file looks now like:
...
IF(${WINTERACTER_RC_COMPILER})
CONFIGURE_FILE(winteracter_rc.sh.in winteracter_rc.sh @ONLY)
SET(CMAKE_RC_COMPILER winteracter_rc.sh CACHE STRING RC compiler FORCE)
ENDIF()
PROJECT(toto Fortran RC)
...
that I build with cmake -GUnix Makefile -DWINTERACTER_RC_COMPILER=ON ..\.
However, the build ends up with an infinite loop that replicates endlessly
the following pattern:
-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler: /home/cs/pellegrini/bin/ifort
-- Check for working Fortran compiler: /home/cs/pellegrini/bin/ifort -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /home/cs/pellegrini/bin/ifort supports Fortran 90
-- Checking whether /home/cs/pellegrini/bin/ifort supports Fortran 90 -- yes
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_RC_COMPILER= winteracter_rc.sh
would you have an idea of what is going wrong with my settings ?
thanks a lot
Eric
First of all, I can confirm the configuration loop you've reported on.
AFAICS, this is because the CMAKE_RC_COMPILER variable mustn't be set
to certain values in the cache as they invalidate the latter and make
CMake reconfigure the project, thus resulting in the infinite loop.
Look at the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RC_LOOP RC)
MESSAGE(CMAKE_RC_COMPILER: ${CMAKE_RC_COMPILER})
When configuring with -DCMAKE_RC_COMPILER=/bin/true, everything works
fine, but with -DCMAKE_RC_COMPILER=true, the loop occurs although the
true executable is in the path. This behavior seems a bit faulty to
me and doesn't occur with CMAKE_C_COMPILER, e.g., in that manner, but
perhaps, a CMake developer can provide us with some enlightenment.
As a solution/workaround, you might try a full path for the wrapper
script as I have also done in my example, or change the line
SET(CMAKE_RC_COMPILER winteracter_rc.sh CACHE STRING ... FORCE)
to
SET(ENV{RC} ${CMAKE_BINARY_DIR}/winteracter_rc.sh)
preferably also with full path, as the evaluation of the RC environment
variable seems to be more robust than CMAKE_RC_COMPILER in this regard.
Some additional remarks:
(1) The wrapper script is meant to contain a @WINTERACTER_RC_COMPILER@
placeholder, so the CONFIGURE_FILE() command will embed the RC's
path, and you shouldn't use WINTERACTER_RC_COMPILER as a boolean
variable, but for the path to the actual RC executable.
Alternatively, you might do roughly the following:
OPTION(WINTERACTER Use Winteracter tools ...)
IF(WINTERACTER)
FIND_PROGRAM(WINTERACTER_RC_COMPILER ...)
IF(NOT WINTERACTER_RC_COMPILER)
MESSAGE(FATAL_ERROR ...)
ENDIF()
CONFIGURE_FILE(winteracter_rc.sh.in winteracter_rc.sh @ONLY)
SET(ENV{RC} ${CMAKE_BINARY_DIR}/winteracter_rc.sh)
ENDIF()
PROJECT(... RC)
(2) Have you already complaint to the Winteracter people w.r.t. their
RC's behavior? ;-) IMO, forcing the output into the same location
as the input is hardly acceptable, as source trees might be read-
only.
Regards,
Michael
Michael Hertling a écrit :
On 10/25/2011 10:16 AM, pellegrini wrote:
Hi Michael,
I tried to adapt the files you gave me to my project. It almost works.
As a reminder, there were a CMakeLists.txt with an overloaded
add_executable function that created a sym_link for the rc files and a
shell file (rc.sh) used to suit the rc compiler call to my needs.
I found one problem that I still not have solved. The shell script is
declared under the following command:
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE bash rc.sh
CMAKE_RC_COMPILER SOURCE OBJECT)
However, this command makes that even my f90 files uses the rc compiler
which obvioulsy makes my build crash. I tried to use something like
set_property(SOURCE myrcfile.rc PROPERTY RULE_LAUNCH_COMPILE ... in
order to apply the patch only when a rc file
Re: [CMake] Add Custom COmmand and CMAKE_CFG_INTDIR
On 01/04/2012 10:11 PM, Bill Hoffman wrote:
On 1/4/2012 4:03 PM, Michael Jackson wrote:
I robbed this from the HDF5 project which does something very similar to
what I am doing:
SET (CMD ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}${CFG_INIT}/H5detect${EXE_EXT})
That seems to at least point to the proper location. Now to get Visual
Studio to actually execute the executable.
That is pretty old stuff...
There are better ways to do that in CMake now:
Especially if one possibly wants to use the RUNTIME_OUTPUT_NAME target
property to make the executable's name differ from the target's name.
cmake --help-command add_custom_command
Arguments to COMMAND may use generator expressions with the syntax
$ Generator expressions are evaluted during build system
generation to produce information specific to each build
configuration. Valid expressions are:
$CONFIGURATION = configuration name
$TARGET_FILE:tgt= main file (.exe, .so.1.2, .a)
$TARGET_LINKER_FILE:tgt = file used to link (.a, .lib, .so)
$TARGET_SONAME_FILE:tgt = file with soname (.so.3)
This should work:
COMMAND $TARGET_FILE:FilterWidgetCodeGen
AFAIK, CMake examines the first argument after the COMMAND clause in
ADD_CUSTOM_COMMAND() whether it denotes an executable target, i.e.
COMMAND $TARGET_FILE:FilterWidgetCodeGen
and
COMMAND FilterWidgetCodeGen
should be equivalent, shouldn't they?
Besides, Mike, both above-noted variants establish target-level
dependencies on the executable target following COMMAND for the
targets which trigger the custom command; most certainly, this
isn't done if one provides expressions like
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}${CFG_INIT}/H5detect${EXE_EXT}
for the COMMAND.
Regards,
Michael
-Bill
--
Mike Jacksonwww.bluequartz.net
On Jan 4, 2012, at 3:54 PM, clin...@elemtech.com wrote:
Have you tried excluding the .exe thing? I thought cmake did the right
thing for targets used in custom commands.
Clint
- Reply message -
From: Michael Jacksonmike.jack...@bluequartz.net
Date: Wed, Jan 4, 2012 1:28 pm
Subject: [CMake] Add Custom COmmand and CMAKE_CFG_INTDIR
To: cmake@cmake.org Listcmake@cmake.org
I am having trouble getting add_custom_Command and CMAKE_CFG_INTDIR to work
correctly together. This is what I have so far.
# -- Setup output Directories -
SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY
${PROJECT_BINARY_DIR}/Bin
CACHE PATH
Single Directory for all Libraries
)
# Create our custom executable that will generate most of our QFilterWidget
# classes from information stored in the Filters themselves.
configure_file( ${FilterWidgets_SOURCE_DIR}/CodeGen.cpp.in
${FilterWidgets_BINARY_DIR}/FilterWidgetCodeGen.cpp)
add_executable(FilterWidgetCodeGen
${FilterWidgets_BINARY_DIR}/FilterWidgetCodeGen.cpp)
target_link_libraries(FilterWidgetCodeGen MXA EbsdLib DREAM3DLib)
set(EXE_EXTENSION )
if (WIN32)
set (EXE_EXTENSION .exe)
endif()
# Now run the code to generate the header files which will over write the
place
# holder files that were generated from above
add_custom_command(TARGET FilterWidgetCodeGen POST_BUILD
COMMAND FilterWidgetCodeGen${EXE_EXTENSION}
WORKING_DIRECTORY ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
I know this is going to fail on visual studio, which it did. The issue is,
what combination of CMAKE_CFG_INTDIR and anything else do I use to get this
to work?
Thanks
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Trying to get build info for a target
On 01/01/2012 07:47 AM, Gary Kramlich wrote:
On 12/31/2011 05:03 PM, Robert Dailey wrote:
Storing the source directory will require the exact idea you had
mentioned. Use an internal cache variable or, even better, a target
property. This is how I have done it. Each target that I create
specifies a list of its include directories (where other targets that
depend on it can find its header files, and will append this directory
to its list of searchable include directories).
I learned the hard way, that the target property can't be named
SOURCE_LOCATION, since it just spit out the value for the LOCATION
property, which seems like a bug, unless SOURCE_LOCATION was left around
for compatibility, but I couldn't find it documented anywhere.
A target's sources may reside in arbitrary directories; there is no
guarantee that they're located next to the CMakeLists.txt file which
defines the target. Furthermore, source files with relative path are
searched w.r.t. CMAKE_CURRENT_SOURCE_DIR and - if not found - w.r.t.
CMAKE_CURRENT_BINARY_DIR, so the notion of a source directory
associated with a target is not reliable, IMO.
Apart from this, I can confirm that a target property ending in
_LOCATION does always yield the same result as the LOCATION
target property:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LOCATION C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES XYZ_LOCATION xyz)
GET_TARGET_PROPERTY(p main XYZ_LOCATION)
MESSAGE(XYZ_LOCATION: ${p})
yields
XYZ_LOCATION: .../main
instead of xyz, and without the SET_TARGET_PROPERTIES() command, it
still yields the same instead of p-NOTFOUND. Indeed, this seems to
be strange behavior which is possibly worth a bug report, but maybe,
a CMake developer can provide some enlightenment.
For defines, and I think cflags, you can use get_target_property().
Coming up empty for the target and the directory. Tried DEFINITIONS,
COMPILE_DEFINITIONS, and COMPILE_FLAGS. When used on the target, i get
a -NOTFOUND, and I get an empty string when used on the source directory.
Each of these properties usually contains only a part of the flags/
definitions used to compile a target's source files, and even their
entirety does not necessarily contain all flags/definitions. AFAIK,
there's no single instance - variable, property or the like - that
one might query in order to retrieve the complete set of flags/
definitions that will be in effect for the compilations.
Moreover, note that these flags/definitions are configuration-specific,
and with multi-config generators, the configuration is chosen at build
time. Thus, gathering such information for a target at configuration
time is generally also not reliable, unless one takes the different
configurations into account.
For libraries, I've also maintained a list in a target property. This is
how you build recursive dependencies. CMake will automatically set up
build order based on your dependencies, however you cannot query these
libraries without maintaining them yourself. Also, another benefit to
maintaining dependencies in target properties is that you can throw an
error message if a target depends on another target that does not yet
exist (used to ensure that targets are defined in the proper order in
the cmake scripts).
It looks like I'll have to be setting these up manually too, since even
though cmake has knowledge about it, it won't give the information out
to scripts.
The libraries a target's binary will be linked against may also depend
on the configuration - possibly chosen at build time - so predicting
them at configuration time is generally unreliable, too.
Regards,
Michael
Maybe I'll be better off requiring that this module be included in the
CMakeLists.txt for the target it's going to work on... But that's
really annoying that cmake is dictating how a module can work, even
though all I'm trying to do is query a target...
Hope that helps.
It helps in the sense that I'm not chasing something that can't be done
anymore ;)
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [EXTERNAL] Re: execute_process appending redirected output
On 12/28/2011 05:39 PM, Belcourt, K. Noel wrote:
Hi Aaron,
On Dec 27, 2011, at 11:04 PM, Aaron Ten Clay wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/27/11 16:16, Belcourt, Kenneth wrote:
I'm trying to get CMake to execute this command
INSTALL(CODE
EXECUTE_PROCESS (COMMAND cat
\${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt
${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf\)
)
but this doesn't work, here's the error I get when I run the install.
I've checked that both the source and target files exist and are
writable. Any ideas on how to get this to work?
It looks as thought you might be missing some escaped double-quotes.
I've tried quite a few quoting permutations, none work.
INSTALL(CODE
EXECUTE_PROCESS (COMMAND cat
\${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt\
\${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf\)
)
Unfortunately this doesn't work.
AFAIK, this is because EXECUTE_PROCESS() doesn't fork a shell to run
the COMMANDs, so the redirection operators like are meaningless.
It's also worth noting that this is not a cross-platform command.
Yup, we're a unix only shop.
Then use one of the premier *nix tools:
INSTALL(CODE EXECUTE_PROCESS(COMMAND sh -c \cat
\\\${CMAKE_CURRENT_SOURCE_DIR}/onejar_classpath.txt\\\
\\\${CMAKE_INSTALL_PREFIX}/onejar/boot-manifest.mf))
Regards,
Michael
Maybe
look at file(READ ...) followed by file(APPEND ...)?
Looks promising, I'll check this out.
Thanks for the help Aaron.
-- Noel
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_EXE_LINKER_FLAGS for shared libraries?
On 12/13/2011 11:19 PM, Michael Hertling wrote: On 12/13/2011 09:21 PM, David Cole wrote: On Tue, Dec 13, 2011 at 2:09 PM, Robert Dailey rcdai...@gmail.com wrote: Thanks for the info. It's a bit disappointing that it doesn't work like I expect. The CMAKE_MFC_FLAG should work as you say the link flags should, but it does not. As long as CMAKE_MFC_FLAG is set before I create my target, it works. Since CMAKE_SHARED_LINK_FLAGS does not work the same, I consider this a bug. There is no reason for it to exist up to the end of the file... it should only exist up to the call to create the target. For example, if I want to have 2 calls to add_library() in the same file, but specify link flags differently for each, how am I expected to do this without using the target specific property? You're not expected to do that. You should use the target property in that case. That's what they're there for. Or use sub-directory organization to have one target per sub-dir, and then set the variable appropriately in each sub-dir's CMakeLists file. And, there is a reason for it to exist up to the end of the file: it's called backwards compatibility, and we take it pretty seriously. The fact is that some variables are examined at configure-time, while CMake is processing add_executable and add_library calls, and all the other myriad commands that are affected by variables values, ... ... and some variables are examined later at generate-time, *after* CMake is done processing the commands, (in other words, at the end of the file). So: this particular case may be considered a bug by some, and a feature by others. Personally, I'm not sure what side of that fence to fall on. However, the primary purpose of this mailing list is to try to show you how you can do what you want to do with *existing* CMake. We also like to discuss options and future plans here. If you would like to report this as a bug, please feel free to add a bug report to the bug tracker. As for me, I wouldn't consider it as a bug, but it should perhaps be mentioned in the documentation which variables undergo this kind of lazy evaluation, i.e. configure-time vs. generate-time evaluation. This variable is not evaluated until the generation takes place, so the value at the end of the CMakeLists.txt will be in effect. Alternatively, one might add a brief description of the two evaluation kinds right beneath [1] but before [2] and mark the generation-time- evaluated variables with a short tag afterwards. Regards, Michael [1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Variables [2] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_VariablesThatChangeBehavior On Mon, Dec 12, 2011 at 11:26 PM, Michael Wild them...@gmail.com wrote: It needs to exist **at the end** of the CMakeLists.txt file containing the target. If you don't want to do that (or can't, as in your case), you can use the LINK_FLAGS target property instead. HTH Michael On 12/12/2011 11:39 PM, Robert Dailey wrote: I have attached a small CMake project that reproduces the issue I'm referring to. Please take a look :) - Robert Dailey On Mon, Dec 12, 2011 at 4:11 PM, Robert Dailey rcdai...@gmail.com mailto:rcdai...@gmail.com wrote: I forgot to say that the main issue is that my /NODEFAULTLIB link flag isn't showing up in visual studio. - Robert Dailey On Mon, Dec 12, 2011 at 4:10 PM, Robert Dailey rcdai...@gmail.com mailto:rcdai...@gmail.com wrote: Another issue... At what point is it most important for the values of CMAKE_SHARED_LINK_FLAGS to exist? I set the value of this variable before my call to add_library(), however after that at some point the flags will get reverted because I'm stepping out of function scope. Does it need to exist up to the end of the current cmake script? My flow is basically this (pseudo call stack): Enter CMakeLists.txt - Call define_project() function (in a separate cmake module) - - Call ignore_libs() function - - - Set CMAKE_SHARED_LINK_FLAGS with PARENT_SCOPE - - Call create_target() function - - - Call add_library() command Leave CMakeLists.txt I've done some testing and I find that before the call to add_library(), my flags are setup properly in the CMAKE_SHARED_LINK_FLAGS variable. - Robert Dailey On Mon, Dec 12, 2011 at 2:20 PM, Michael Wild them...@gmail.com mailto:them...@gmail.com wrote: On 12/12/2011 09:13 PM, Robert Dailey wrote: On Mon, Dec 12, 2011 at 2:10 PM, David Cole david.c...@kitware.com mailto:david.c...@kitware.com mailto:david.c...@kitware.com mailto:david.c...@kitware.com wrote: Apparently
Re: [CMake] 2D arrays
On 12/01/2011 06:04 PM, Robert Dailey wrote: On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling mhertl...@online.dewrote: On 11/30/2011 03:29 AM, Robert Dailey wrote: I use macros so the _array2d_ variables fall through the scope of the macro and are available in the next call to array2d_advance(). I could use functions + properties but this solution works, I saw no need to use the slightly more verbose global properties feature. What I've had in mind are functions and the PARENT_SCOPE option of SET(). This is a good idea, thanks. What specific helper variables are you referring to? I would most likely use more uniquely mangled local variables instead, but I figured the preceeding underscore in front of each was sufficient. What would you recommend here? I'd like to avoid a cleanup() method because it seems unnecessary. If my local variables cause conflicts later, and if name mangling isn't the idiomatic solution, I'd like to hear whatever idea you have (that doesn't involve cleanup() if possible). Because you must preserve some variables between multiple function/macro invocations - i.e. you can't work with local variables only - one might like to have a mean to purge these variables when their job is done in order to not pollute the current scope more than necessary. Of course, it's not absolutely indispensable, but if a set of non-local variables is used just internally by a set of related functions, it is possibly worth a thought how to not have these variables hang around later on. When you say pollute the current scope, what specific issues are you referring to? In my experience the biggest danger are naming conflicts, which are silent issues and cause subtle symptoms that are hard to debug. I've attempted to remedy this, as I said, by using name mangling... i.e. prefix everything with _array2d_, which I'm pretty sure no one else will ever use. Some remarks w.r.t. your name mangling: - In array2d_advance(), you are using variables offset, _index or _size, i.e. non-mangled names. As long as array2d_advance() is a macro, you're at risk to overwrite equally named variables within the caller's scope - one more point for using functions. - You must be prepared that the user performs *nested* iterations. - You must even be prepared for nested iterations over the *same* array; therefore, the name mangling must be sufficiently unique. I respect the notion of a cleanup method. I will implement one but it really is optional... whether you call it or not, in practice, the differences will never be noticed since the names are unique enough. Now, if keeping those variables lingering around cause performance issues or memory issues in CMake, then that's a different discussion. Regarding clean-up operations, I've had no special issues in mind. IMO, it is just good style to think about the lifetime of non-local objects, i.e. objects which do not go out of scope automatically. An example for a necessary clean-up are the XXX_FIND_REQUIRED_YYY variables defined by FIND_PACKAGE(). While the variables defined by the find module / config file are conveyed to the caller, i.e. they're persistent in this sense, the XXX_FIND_REQUIRED_YYY ones are removed since they might influence a subsequent processing of the same find module / config file. What would this buy me? Typically I've avoided ARGN unless it is absolutely necessary, but a variable in this case seems more direct. Can you explain what benefits this has? AFAICS, you don't need the width parameter because it can be obtained as the length of var_names. Thus, additionally specifying width is error-prone; e.g. (width,var_names)=(3,fruit;animal) is inherently invalid. Using ARGN would allow the user to specify the array elements freely as separate arguments at the end of array2d_begin_loop(), without the need to pass them in as a semicolon-separated list in double quotes. Oh, I didn't realize you eliminated the width parameter. That's actually a very awesome idea. I misread your code sample and thought you still kept 'width' but simply moved the list of field names to the end. I wasn't sure what that would provide me :) Great ideas and I will implement these and re-post my code. Hopefully it can be added to CMake later or become useful to other people. BTW, why just 2D arrays, why not nD? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 2D arrays
On 12/01/2011 08:14 PM, Robert Dailey wrote:
PARENT_SCOPE isn't working for me. For example, I changed one line in
array2d_begin_loop to the following:
set( _array2d_index 0 PARENT_SCOPE )
And from within array2d_advance(), I do:
message( _array2d_index: ${_array2d_index} )
and it prints no value. Can you try this and see if it works for you?
You say that you changed *one* line, i.e. array2d_begin_loop() is still
a macro? If so, this can't work; you need to turn array2d_begin_loop()
into a function in order to have PARENT_SCOPE show the desired effect.
Regards,
Michael
On Thu, Dec 1, 2011 at 11:04 AM, Robert Dailey rcdai...@gmail.com wrote:
On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling mhertl...@online.dewrote:
On 11/30/2011 03:29 AM, Robert Dailey wrote:
I use macros so the _array2d_ variables fall through the scope of the
macro
and are available in the next call to array2d_advance(). I could use
functions + properties but this solution works, I saw no need to use the
slightly more verbose global properties feature.
What I've had in mind are functions and the PARENT_SCOPE option of SET().
This is a good idea, thanks.
What specific helper variables are you referring to? I would most likely
use more uniquely mangled local variables instead, but I figured the
preceeding underscore in front of each was sufficient. What would you
recommend here? I'd like to avoid a cleanup() method because it seems
unnecessary. If my local variables cause conflicts later, and if name
mangling isn't the idiomatic solution, I'd like to hear whatever idea
you
have (that doesn't involve cleanup() if possible).
Because you must preserve some variables between multiple function/macro
invocations - i.e. you can't work with local variables only - one might
like to have a mean to purge these variables when their job is done in
order to not pollute the current scope more than necessary. Of course,
it's not absolutely indispensable, but if a set of non-local variables
is used just internally by a set of related functions, it is possibly
worth a thought how to not have these variables hang around later on.
When you say pollute the current scope, what specific issues are you
referring to? In my experience the biggest danger are naming conflicts,
which are silent issues and cause subtle symptoms that are hard to debug.
I've attempted to remedy this, as I said, by using name mangling... i.e.
prefix everything with _array2d_, which I'm pretty sure no one else will
ever use.
I respect the notion of a cleanup method. I will implement one but it
really is optional... whether you call it or not, in practice, the
differences will never be noticed since the names are unique enough. Now,
if keeping those variables lingering around cause performance issues or
memory issues in CMake, then that's a different discussion.
What would this buy me? Typically I've avoided ARGN unless it is
absolutely
necessary, but a variable in this case seems more direct. Can you
explain
what benefits this has?
AFAICS, you don't need the width parameter because it can be obtained
as the length of var_names. Thus, additionally specifying width is
error-prone; e.g. (width,var_names)=(3,fruit;animal) is inherently
invalid.
Using ARGN would allow the user to specify the array elements freely as
separate arguments at the end of array2d_begin_loop(), without the need
to pass them in as a semicolon-separated list in double quotes.
Oh, I didn't realize you eliminated the width parameter. That's actually
a very awesome idea. I misread your code sample and thought you still kept
'width' but simply moved the list of field names to the end. I wasn't sure
what that would provide me :)
Great ideas and I will implement these and re-post my code. Hopefully it
can be added to CMake later or become useful to other people.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Transitive link question
On 12/13/2011 11:00 PM, Biddiscombe, John A. wrote: Sure, when project A is loaded into project B it either needs to search and load the hdf5 cmake file or require that to be done in project B before loading project A. Then the hdf5 target will be known in project B too and linking will work fine. Using find_package in project B is an option, but what I was really trying to ask is if there's a way to make the transitive link get the correct library on its own. Since I have a number of different versions of the hdf5 package installed, there's a chance that project B will use the wrong one (ok, not when I'm doing it because I know, but if a third party needs to do the same). Since project A knows the correct library and name/lib other target properties, I would like it to make it available to project B/C/D etc If A is linked against HDF5, and hdf5 is an imported target, the latter will appear among A's transitive link dependencies with its symbolic name instead of a full path to the library. In fact, this separation of target names and library paths is the basic idea of imported targets, and what you're asking for is rather the opposite. If you really want to have HDF5's debug library mentioned explicitly among A's prerequisites, you might query the IMPORTED_LOCATION_DEBUG property of hdf5 and link A against that value. However, in this way, you lose the flexibility w.r.t. choosing libraries in link command lines based on the build/configuration type. Generally, IMO, the best bet is to provide a full-featured config file AConfig.cmake which includes the appropriate file(s) provided by HDF5, so any of A's clients can issue FIND_PACKAGE(A) and receives complete information about A and its prerequisites. This is the most powerful solution, and you might even parameterize AConfig.cmake in a manner so that the client can choose which HDF5 installation the config file should look for, e.g. via an HDF5_ROOT variable. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to find list of directories
On 12/15/2011 02:34 PM, Renato Utsch wrote:
Hello,
I am writing a plugin compiler that will do linke this:
-- main
plugin
| CMakeLists.txt (in the plugin folder)
-- example (example plugin)
--| CMakeLists.txt (in the example folder)
The CMakeLists.txt file inside the plugin folder will do a foreach() to use
add_subdirectory() for each folder inside the plugin directory:
foreach( FOREACH_FOLDER ${FOLDERS_INSIDE_PLUGIN} )
add_subdirectory( ${FOREACH_FOLDER} )
endforeach()
Then, the CMakeLists.txt of each folder will do the compilation of the
plugin
How can I set the FOLDERS_INSIDE_PLUGIN variable to a list with all the
folder names in the plugin directory? My program will be compiled only in
UNIX (and cygwin), so if there is an UNIX command that does this, it can
work as well (couldn't remember any)...
You might use FILE(GLOB ...), iterate over the results and pick out the
directories with IF(IS_DIRECTORY ...), but you shouldn't do this: Your
project wouldn't be aware of added/removed/renamed directories, the
typical pitfall when using FILE(GLOB ...) in CMakeLists.txt files.
Instead, play safe and explicitly specify the directories in the
FOLDERS_INSIDE_PLUGIN variable by hand.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Top level target depending on a file
On 12/14/2011 09:30 AM, Alexander Broekhuis wrote:
Hi,
CMake takes great care regarding dependencies on files which are needed
to build targets, i.e. usually, it's not necessary to specify any extra
dependencies of a target on a file. In my exemplary project, the README
file is actually not needed to build the library target, so CMake does
not add an appropriate dependency. However, the README file is needed
to generate the ZIP file, so the latter must be a separate target with
dependencies on its own, whereas the approach to generate the ZIP file
by a TARGET-style custom command for the library target is wrong, IMO;
one can just trigger the ZIP file target in this way. In other words:
You have two targets with different dependencies - don't mix them up.
In my case the output is the ZIP file. So the zip file is produced by the
top level target, and I don't want/need a separate target for it.
The generated zip file (bundle) is the deployable unit which contains a
library and additional information needed (at runtime) to use the library,
which is located in the manifest file. If the manifest file changes,
without a change to the library source, the zip file still needs to be
regenerated. As such the output of the target depends on the manifest file,
hence the need for a dependency to a file.
First of all, you definitely need the library target in order to build
the library, and CMake ignores each file in the list of sources which
is not necessary for this purpose. IMO, that's quite reasonable; e.g.,
you wouldn't want to have the library relinked or even completely re-
built because the manifest has been touched. Actually, there's simply
no dependency of the library on the manifest. Furthermore, a TARGET-
style custom command is triggered only when its target is rebuilt, so
generating the ZIP file in this way is unsuitable since you will miss
its dependency on the manifest. Thus, to express this dependency, you
need to have an own target for the ZIP file, so you will end up with
two targets if you want to have the dependencies set up correctly,
although you'd prefer to have just one. BTW, is this really bad?
Regards,
Michael
PS: Please don't drop the ML.
I am used to mailing lists having the reply-to set, will try to keep it in
mind.
2011/12/13 Michael Hertling mhertl...@online.de
On 12/12/2011 11:40 AM, Alexander Broekhuis wrote:
Hi,
Can anyone help me with this? I haven't found a proper solution myself
yet..
Does the following examplary project do what you intend?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# The library target:
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
# The README file:
FILE(WRITE ${CMAKE_BINARY_DIR}/README Very important information!\n)
# The ZIP file command:
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/f.zip
COMMAND zip -j ${CMAKE_BINARY_DIR}/f.zip
${CMAKE_BINARY_DIR}/README
$TARGET_FILE:f
DEPENDS ${CMAKE_BINARY_DIR}/README)
# The ZIP file target:
ADD_CUSTOM_TARGET(zip ALL DEPENDS ${CMAKE_BINARY_DIR}/f.zip)
# Trigger ZIP file target after library target:
ADD_CUSTOM_COMMAND(TARGET f POST_BUILD
COMMAND ${CMAKE_COMMAND} -E remove ${CMAKE_BINARY_DIR}/f.zip
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target zip)
The basic idea is the decomposition of the ZIP file's generation into a
custom target, an OUTPUT-style custom command and a TARGET-style custom
command, the latter in conjunction with CMake's --build switch.
Regards,
Michael
2011/12/8 Alexander Broekhuis a.broekh...@gmail.com
Hi all,
In my project, some top level targets depend on simple text files.
These
targets produce a zip file as output, this is done using a custom
command
with a post-build to a library target.
Part of the zip file are some simple text files, which are included
using
some custom CPack handling inside the custom command.
How can I let the top level target depend on these text files as well?
In
other words, if a text files changes, the zip file has to be
regenerated.
These text files are not generated or copied etc. So a simple DEPENDS
would
suffice. I know add_custom_command(OUTPUT has support for this, but am
wondering how to do this with add_custom_command(TARGET.
TiA!
--
Met vriendelijke groet,
Alexander Broekhuis
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Top level target depending on a file
On 12/14/2011 10:55 AM, Alexander Broekhuis wrote: Hi, Thanks for you replies, In my case the output is the ZIP file. So the zip file is produced by the top level target, and I don't want/need a separate target for it. Yes but CMake's jobs is to build libraries and executables not bundle which is more the CPack's job, however I understand your point. An extra target may be a small price to pay, no? Well I'd rather have a solution without CPack, CPack being a package creator, whereas my bundle is a development item. If all fails I could make the extra target, but again, the zip file in my case is equivalent to a library. Not technically, because the ZIP file has different dependencies than the library, and these dependencies can't be expressed for the latter. However, if you (1) absolutely want to generate the ZIP file by a TARGET-style custom command attached to the library target, (2) get along with Makefiles and (3) are willing to pay an extra charge, you might use the LINK_DEPENDS target property for your purposes. If set on the library target and specifying the manifest file, it will have the library relinked and, thus, the ZIP file command triggered when the manifest is newer than the library. Of course, this means to accept actually unnecessary link operations which can be quite expensive. Regards, Michael Yes sure, sometimes file dependencies are needed. By the way I see you custom-commands in order to create a bundle on MacOS? Did you try try CPack MacOSX bundle generator? http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29 My bundles don't have anything to do with MacOS bundles, the name is a coincidence. Some background might be helpful now.. I am using CMake to build Apache Celix, which is a project in the Apache Incubator. Apache Celix is an implementation of the OSGi specification in C. I am not sure if you are familiar with OSGi, but it provides a modular system for Java in which new functionality can be added/removed/updated at runtime. In Java OSGi a bundle is a regular Jar file with additional information in the Manifest file. For Celix we use a similar solution (since a jar file is actually a zip file..) where the library is packed in a zip file together with the manifest file. One bundle contains always one library, this is why I see the Celix bundles as top level artifacts, and not the library. As such, from the Celix point of view it makes sense to have one target for creating a Bundle. More information can be found at: http://incubator.apache.org/celix/ And specifically on the build files: http://incubator.apache.org/celix/documentation/buildingandrunning.html I hope this makes all a little bit clearer, I understand I am using a rather specific solution, but the flexibility of CMake has really helped my achieving what I wanted (until now?). This way fits the modular development needed in an OSGi based environment. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Top level target depending on a file
On 12/14/2011 11:23 AM, Alexander Broekhuis wrote:
Hi,
First of all, you definitely need the library target in order to build
the library, and CMake ignores each file in the list of sources which
is not necessary for this purpose. IMO, that's quite reasonable; e.g.,
you wouldn't want to have the library relinked or even completely re-
built because the manifest has been touched. Actually, there's simply
no dependency of the library on the manifest.
This makes sense, the dependency is the other way, from the bundle to the
library. Until now I tried to see the manifest file as part of the target,
but I could as well see it a separate step.
Yes, the dependencies in your case are, if I'm not mistaken,
+-- library
|
bundle --+
|
+-- manifest
with -- meaning depends on. With your original approach, you tried
to express them as bundle -- library -- manifest, and that's not
appropriate as it does not reflect the actual relationships.
Furthermore, a TARGET-
style custom command is triggered only when its target is rebuilt, so
generating the ZIP file in this way is unsuitable since you will miss
its dependency on the manifest. Thus, to express this dependency, you
need to have an own target for the ZIP file, so you will end up with
two targets if you want to have the dependencies set up correctly,
although you'd prefer to have just one. BTW, is this really bad?
Reading the replies I think this might be the best solution. In this case I
would like to be able to add dependencies to the top-level target, eg I
would like to add my bundle targets to ALL since building the project
implicitly means the bundles need to be generated.
This sounds perfectly reasonable, IMO.
Again, previously I tried to see the Manifest file as a part of the
compilation unit. So a change to the file would trigger a rebuild of the
library and zip file, instead of only the zip file.
In this regard, the question is: Is the manifest actually necessary to
build the library, i.e. must the latter be recompiled and/or relinked
when the former changes? AFAICS, that's not the case, so the manifest
should not be considered as one of the library's prerequisites.
Regards,
Michael
2011/12/13 Michael Hertling mhertl...@online.de
On 12/12/2011 11:40 AM, Alexander Broekhuis wrote:
Hi,
Can anyone help me with this? I haven't found a proper solution
myself
yet..
Does the following examplary project do what you intend?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# The library target:
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
# The README file:
FILE(WRITE ${CMAKE_BINARY_DIR}/README Very important information!\n)
# The ZIP file command:
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/f.zip
COMMAND zip -j ${CMAKE_BINARY_DIR}/f.zip
${CMAKE_BINARY_DIR}/README
$TARGET_FILE:f
DEPENDS ${CMAKE_BINARY_DIR}/README)
# The ZIP file target:
ADD_CUSTOM_TARGET(zip ALL DEPENDS ${CMAKE_BINARY_DIR}/f.zip)
# Trigger ZIP file target after library target:
ADD_CUSTOM_COMMAND(TARGET f POST_BUILD
COMMAND ${CMAKE_COMMAND} -E remove ${CMAKE_BINARY_DIR}/f.zip
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target zip)
The basic idea is the decomposition of the ZIP file's generation into
a
custom target, an OUTPUT-style custom command and a TARGET-style
custom
command, the latter in conjunction with CMake's --build switch.
Regards,
Michael
2011/12/8 Alexander Broekhuis a.broekh...@gmail.com
Hi all,
In my project, some top level targets depend on simple text files.
These
targets produce a zip file as output, this is done using a custom
command
with a post-build to a library target.
Part of the zip file are some simple text files, which are included
using
some custom CPack handling inside the custom command.
How can I let the top level target depend on these text files as
well?
In
other words, if a text files changes, the zip file has to be
regenerated.
These text files are not generated or copied etc. So a simple
DEPENDS
would
suffice. I know add_custom_command(OUTPUT has support for this, but
am
wondering how to do this with add_custom_command(TARGET.
TiA!
--
Met vriendelijke groet,
Alexander Broekhuis
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: Re: Compiler debug file, howto remove in clean?
On 12/14/2011 09:43 AM, Totte Karlsson wrote:
On 12/13/2011 4:15 PM, David Cole wrote:
RUNTIME_OUTPUT_DIRECTORY is a target property, not a variable. You'd
have to use get_property to retrieve its value, not
${RUNTIME_OUTPUT_DIRECTORY}...
Thanks! I ended up with the following, in the targets CMakeList file
get_property(exe_path TARGET ${target} PROPERTY RUNTIME_OUTPUT_DIRECTORY)
set_property(DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES
${exe_path}/${target}.tds)
and that seem to work fine.
Question 1: What is best practice? To do the get_property in a top level
CmakeList file and set_property in each targets CMakeList file. Or do I need
both lines in each target CMakeList file?
The latter, as the target must be defined before you can query its
properties; thus, the GET_PROPERTY() command should reside in the
respective CMakeLists.txt file next to the target. Moreover, the
RUNTIME_OUTPUT_DIRECTORY property is empty if it's neither set
explicitly nor initialized by CMAKE_RUNTIME_OUTPUT_DIRECTORY;
perhaps, you should handle this case, e.g.:
ADD_EXECUTABLE(xyz ...)
GET_PROPERTY(s TARGET xyz PROPERTY RUNTIME_OUTPUT_DIRECTORY SET)
IF(s)
GET_PROPERTY(... TARGET xyz PROPERTY RUNTIME_OUTPUT_DIRECTORY)
SET_PROPERTY(DIRECTORY APPEND PROPERTY ADDITIONAL_MAKE_CLEAN_FILES ...)
ELSE()
# Warn or bail out or do just nothing...
ENDIF()
Q 2: I have
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY${PROJECT_BINARY_DIR}/bins)
in the top level CMakeList file. If I want a variable corresponding to the
RUNTIME_OUTPUT_DIRECTORY property, is there a best practice naming convention
for such? For example, is it possible to create a variable with the same
name, like:
get_property(RUNTIME_OUTPUT_DIRECTORY TARGET ${target} PROPERTY
RUNTIME_OUTPUT_DIRECTORY)
?
Yes, because properties and variables are different types of objects
with separate namespaces, and property-related predefined variables
usually have the CMAKE_ prefix.
Regards,
Michael
On Tue, Dec 13, 2011 at 10:04 AM, Totte Karlsson
to...@dunescientific.com wrote:
not sure if the following was sent to the newsgroup?
Sorry if posting double..
set_property(DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES
${RUNTIME_OUTPUT_DIRECTORY}/${target}.tds
)
Is your RUNTIME_OUTPUT_DIRECTORY variable set up correctly?
In the top Cmake file I have
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bins)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${EXECUTABLE_OUTPUT_PATH})
Not sure if that is best practice? I'm a cmake beginner
Do you
perhaps mean the target property of this name instead, and what's
the value of your target variable?
In the 'target' cmake file, where the target is an application or a dll, it
looks something like (for an application 'read_from_file'):
set(target read_from_file)
add_executable(${target} main.cpp)
#MTK libraries
target_link_libraries (${target} mtkCommon)
...
#VTK libraries
target_link_libraries(${target} vtkCommon)
ADD_CUSTOM_COMMAND(
TARGET ${target} POST_BUILD
COMMAND echo ${target} and ${EXECUTABLE_OUTPUT_PATH}
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_SOURCE_DIR}/ball.mtk ${EXECUTABLE_OUTPUT_PATH}
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_SOURCE_DIR}/Alanine.mtk ${EXECUTABLE_OUTPUT_PATH}
)
set_property(DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES
${EXECUTABLE_OUTPUT_PATH}/ball.mtk
${EXECUTABLE_OUTPUT_PATH}/Alanine.mtk
${RUNTIME_OUTPUT_DIRECTORY}/${target}.tds
)
#then comes installs, omitted...
install (TARGETS ${target} DESTINATION bins)
...
In the set_property command, the cleaning works for the text files, ball and
Alanine.mtk. Interestingly, if I change it to
${EXCECUTABLE_PATH}/${target}.tds
So I guess the RUNTIME_OUTPUT_DIRECTORY variable is not set correctly? I
thought
I read somewhere it is setup when the CMAKE_RUNTIME_OUTPUT_DIRECTORY is
setup?
Any feedback appreciated!
totte
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] target dependency in subdirectory not found
On 12/12/2011 08:42 PM, Jos van den Oever wrote:
I'm trying to get get CMake to do the equivalent from this Makefile. I'm
using
cp in this simple example, but want to use different commands in my project.
==Makefile==
srcdir=..
hij: a/efg
cp a/efg hij
a/efg: $(srcdir)/a/abc
-mkdir a
cp $(srcdir)/a/abc a/efg
==
For this I am using two CMakeLists.txt files.
==CMakeLists.txt==
cmake_minimum_required(VERSION 2.8)
add_subdirectory(a)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/hij
COMMAND ${CMAKE_COMMAND} ARGS -E copy_if_different
${CMAKE_CURRENT_BINARY_DIR}/a/efg
${CMAKE_CURRENT_BINARY_DIR}/hij
DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/a/efg
VERBATIM
)
add_custom_target(hij_target ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/hij)
==
==a/CMakeLists.txt==
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/efg
COMMAND ${CMAKE_COMMAND} ARGS -E copy_if_different
${CMAKE_CURRENT_SOURCE_DIR}/abc
${CMAKE_CURRENT_BINARY_DIR}/efg
DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/abc
VERBATIM
)
This gives me the error:
make[2]: *** No rule to make target `a/efg', needed by `hij'. Stop.
make[1]: *** [CMakeFiles/hij_target.dir/all] Error 2
make: *** [all] Error 2
How can cmake be made to understand this simple dependency?
Cheers,
Jos
OUTPUT-style custom commands must be triggered by an {executable,
library,custom} target from within the *same* CMakeLists.txt file;
refer to the documentation for more information. Thus, you need an
ADD_CUSTOM_TARGET(efg_target ALL
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/efg)
or the like in a/CMakeLists.txt and an
ADD_DEPENDENCIES(hij_target efg_target)
somewhere, preferably in your top-level CMakeLists.txt after the
ADD_SUBDIRECTORY() and ADD_CUSTOM_TARGET() commands. Finally, the
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/a/efg
clause in the custom command for ${CMAKE_CURRENT_BINARY_DIR}/hij is
pointless since ${CMAKE_CURRENT_BINARY_DIR}/a/efg isn't generated
by a custom command in the same CMakeLists.txt file.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Top level target depending on a file
On 12/12/2011 11:40 AM, Alexander Broekhuis wrote:
Hi,
Can anyone help me with this? I haven't found a proper solution myself yet..
Does the following examplary project do what you intend?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# The library target:
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
# The README file:
FILE(WRITE ${CMAKE_BINARY_DIR}/README Very important information!\n)
# The ZIP file command:
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/f.zip
COMMAND zip -j ${CMAKE_BINARY_DIR}/f.zip
${CMAKE_BINARY_DIR}/README
$TARGET_FILE:f
DEPENDS ${CMAKE_BINARY_DIR}/README)
# The ZIP file target:
ADD_CUSTOM_TARGET(zip ALL DEPENDS ${CMAKE_BINARY_DIR}/f.zip)
# Trigger ZIP file target after library target:
ADD_CUSTOM_COMMAND(TARGET f POST_BUILD
COMMAND ${CMAKE_COMMAND} -E remove ${CMAKE_BINARY_DIR}/f.zip
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target zip)
The basic idea is the decomposition of the ZIP file's generation into a
custom target, an OUTPUT-style custom command and a TARGET-style custom
command, the latter in conjunction with CMake's --build switch.
Regards,
Michael
2011/12/8 Alexander Broekhuis a.broekh...@gmail.com
Hi all,
In my project, some top level targets depend on simple text files. These
targets produce a zip file as output, this is done using a custom command
with a post-build to a library target.
Part of the zip file are some simple text files, which are included using
some custom CPack handling inside the custom command.
How can I let the top level target depend on these text files as well? In
other words, if a text files changes, the zip file has to be regenerated.
These text files are not generated or copied etc. So a simple DEPENDS would
suffice. I know add_custom_command(OUTPUT has support for this, but am
wondering how to do this with add_custom_command(TARGET.
TiA!
--
Met vriendelijke groet,
Alexander Broekhuis
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiler debug file, howto remove in clean?
On 12/13/2011 02:00 PM, Totte Karlsson wrote:
Hi,
I'm using cmake with codegear compiler. I have been able to setup a build
system
to compile some dll's and executables.
When compiled in Debug mode, a extra .tds file is generated and placed in the
same folder as the executable, or dll. In corresponding CMakeLists.txt file I
have:
set_property(DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES
${RUNTIME_OUTPUT_DIRECTORY}/${target}.tds
)
But that does not work. Any tips on what's wrong? I suspect ${target} is the
name + .exe or .dll, but not sure. If so, how to cut off the extension?
-totte
Is your RUNTIME_OUTPUT_DIRECTORY variable set up correctly? Do you
perhaps mean the target property of this name instead, and what's
the value of your target variable? Could you post a minimal but
complete CMakeLists.txt file which demonstrates your issue?
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Top level target depending on a file
On 12/13/2011 03:24 PM, Alexander Broekhuis wrote:
Hi,
Thanks for the hint, I haven't tried it yet, but looks good at the first
glance!
I'll try this.
Is this worth a feature request? To be able to add a file as a dependency
to a target would make sense to me.. The posted issue (
http://public.kitware.com/Bug/view.php?id=8438) talks about target
dependencies, not as much about file dependenies.
CMake takes great care regarding dependencies on files which are needed
to build targets, i.e. usually, it's not necessary to specify any extra
dependencies of a target on a file. In my exemplary project, the README
file is actually not needed to build the library target, so CMake does
not add an appropriate dependency. However, the README file is needed
to generate the ZIP file, so the latter must be a separate target with
dependencies on its own, whereas the approach to generate the ZIP file
by a TARGET-style custom command for the library target is wrong, IMO;
one can just trigger the ZIP file target in this way. In other words:
You have two targets with different dependencies - don't mix them up.
What might be really worth a feature request are generator expressions
in the DEPENDS clause of custom commands/targets. If we're able to say
DEPENDS ${CMAKE_BINARY_DIR}/README) $TARGET_FILE:f
in the ZIP file's custom command, it wouldn't be necessary to remove
the ZIP file prior to triggering its target after the library has
been (re)built. This could also be slightly more efficient.
Regards,
Michael
PS: Please don't drop the ML.
2011/12/13 Michael Hertling mhertl...@online.de
On 12/12/2011 11:40 AM, Alexander Broekhuis wrote:
Hi,
Can anyone help me with this? I haven't found a proper solution myself
yet..
Does the following examplary project do what you intend?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# The library target:
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
# The README file:
FILE(WRITE ${CMAKE_BINARY_DIR}/README Very important information!\n)
# The ZIP file command:
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/f.zip
COMMAND zip -j ${CMAKE_BINARY_DIR}/f.zip
${CMAKE_BINARY_DIR}/README
$TARGET_FILE:f
DEPENDS ${CMAKE_BINARY_DIR}/README)
# The ZIP file target:
ADD_CUSTOM_TARGET(zip ALL DEPENDS ${CMAKE_BINARY_DIR}/f.zip)
# Trigger ZIP file target after library target:
ADD_CUSTOM_COMMAND(TARGET f POST_BUILD
COMMAND ${CMAKE_COMMAND} -E remove ${CMAKE_BINARY_DIR}/f.zip
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target zip)
The basic idea is the decomposition of the ZIP file's generation into a
custom target, an OUTPUT-style custom command and a TARGET-style custom
command, the latter in conjunction with CMake's --build switch.
Regards,
Michael
2011/12/8 Alexander Broekhuis a.broekh...@gmail.com
Hi all,
In my project, some top level targets depend on simple text files. These
targets produce a zip file as output, this is done using a custom
command
with a post-build to a library target.
Part of the zip file are some simple text files, which are included
using
some custom CPack handling inside the custom command.
How can I let the top level target depend on these text files as well?
In
other words, if a text files changes, the zip file has to be
regenerated.
These text files are not generated or copied etc. So a simple DEPENDS
would
suffice. I know add_custom_command(OUTPUT has support for this, but am
wondering how to do this with add_custom_command(TARGET.
TiA!
--
Met vriendelijke groet,
Alexander Broekhuis
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: Re: Compiler debug file, howto remove in clean?
On 12/13/2011 04:04 PM, Totte Karlsson wrote:
not sure if the following was sent to the newsgroup?
Wasn't. ;-)
Sorry if posting double..
Only to me. ;)
set_property(DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES
${RUNTIME_OUTPUT_DIRECTORY}/${target}.tds
)
Is your RUNTIME_OUTPUT_DIRECTORY variable set up correctly?
In the top Cmake file I have
set(EXECUTABLE_OUTPUT_PATH${PROJECT_BINARY_DIR}/bins)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${EXECUTABLE_OUTPUT_PATH})
Not sure if that is best practice? I'm a cmake beginner
Don't use EXECUTABLE_OUTPUT_PATH, it's obsolete. With regard to
the RUNTIME_OUTPUT_DIRECTORY variable, refer to David's reply.
Regards,
Michael
Do you
perhaps mean the target property of this name instead, and what's
the value of your target variable?
In the 'target' cmake file, where the target is an application or a dll, it
looks something like (for an application 'read_from_file'):
set(target read_from_file)
add_executable(${target} main.cpp)
#MTK libraries
target_link_libraries (${target} mtkCommon)
...
#VTK libraries
target_link_libraries(${target} vtkCommon)
ADD_CUSTOM_COMMAND(
TARGET ${target} POST_BUILD
COMMAND echo ${target} and ${EXECUTABLE_OUTPUT_PATH}
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_SOURCE_DIR}/ball.mtk ${EXECUTABLE_OUTPUT_PATH}
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_SOURCE_DIR}/Alanine.mtk ${EXECUTABLE_OUTPUT_PATH}
)
set_property(DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES
${EXECUTABLE_OUTPUT_PATH}/ball.mtk
${EXECUTABLE_OUTPUT_PATH}/Alanine.mtk
${RUNTIME_OUTPUT_DIRECTORY}/${target}.tds
)
#then comes installs, omitted...
install (TARGETS ${target}DESTINATION bins)
...
In the set_property command, the cleaning works for the text files, ball and
Alanine.mtk. Interestingly, if I change it to
${EXCECUTABLE_PATH}/${target}.tds
So I guess the RUNTIME_OUTPUT_DIRECTORY variable is not set correctly? I
thought
I read somewhere it is setup when the CMAKE_RUNTIME_OUTPUT_DIRECTORY is setup?
Any feedback appreciated!
totte
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copy a input file from src folder to EXECUTABLE_OUTPUT_PATH
On 12/12/2011 04:36 PM, Michael Wild wrote:
On 12/12/2011 04:29 PM, Totte Karlsson wrote:
At build time:
ADD_CUSTOM_COMMAND(TARGET OneOfYourExecutables
COMMAND ${CMAKE_COMMAND} -E copy_if_different
path/to/input.txt $TARGET_FILE_DIR:OneOfYourExecutables)
ADD_CUSTOM_COMMAND(TARGET AnotherExecutable
COMMAND ${CMAKE_COMMAND} -E copy_if_different
path/to/input.txt $TARGET_FILE_DIR:AnotherExecutable)
Personally, I'd prefer the latter as it's clean and quite flexible.
I decided to use
ADD_CUSTOM_COMMAND(
TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_COMMAND} -E
copy_if_different
P:/mtkLib/Examples/${PROJECT_NAME}/ball.mtk
$TARGET_FILE_DIR:${PROJECT_NAME}
)
It works fine. But I have a few more questions:
1) How can I get rid of the absolute path in the expression for the
source file?
Use the ${PROJECT_SOURCE_DIR} variable. It points to the directory
containing the CMakeLists.txt file with the last project() call.
2) when doing make clean, the file in the target file dir is not
deleted. How to add it to 'clean'?
See the ADDITIONAL_MAKE_CLEAN_FILES directory property. However, this is
going to be somewhat tricky since you are using $TARGET_FILE_DIR:...
in your custom command, and AFAIK the set_directory_property command is
not aware of this notation. Do you really need ball.mtk to be in the
same directory as your output file?
If one comes to the conclusion that it's worth the effort, one
could also record any additional files to clean at build time
and use a custom target to trigger the built-in clean target
as well as to remove the recorded files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
ADD_CUSTOM_COMMAND(TARGET f POST_BUILD
COMMAND ${CMAKE_COMMAND} -E touch $TARGET_FILE_DIR:f/f.dat
COMMAND ${CMAKE_COMMAND}
-DF=$TARGET_FILE_DIR:f/f.dat
-DL=${CMAKE_BINARY_DIR}/files.dat
-P ${CMAKE_SOURCE_DIR}/record.cmake)
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c void g(void){}\n)
ADD_LIBRARY(g SHARED g.c)
ADD_CUSTOM_COMMAND(TARGET g POST_BUILD
COMMAND ${CMAKE_COMMAND} -E touch $TARGET_FILE_DIR:g/g.dat
COMMAND ${CMAKE_COMMAND}
-DF=$TARGET_FILE_DIR:g/g.dat
-DL=${CMAKE_BINARY_DIR}/files.dat
-P ${CMAKE_SOURCE_DIR}/record.cmake)
FILE(WRITE ${CMAKE_BINARY_DIR}/h.c void h(void){}\n)
ADD_LIBRARY(h SHARED h.c)
ADD_CUSTOM_COMMAND(TARGET h POST_BUILD
COMMAND ${CMAKE_COMMAND} -E touch $TARGET_FILE_DIR:h/h.dat
COMMAND ${CMAKE_COMMAND}
-DF=$TARGET_FILE_DIR:h/h.dat
-DL=${CMAKE_BINARY_DIR}/files.dat
-P ${CMAKE_SOURCE_DIR}/record.cmake)
ADD_CUSTOM_TARGET(totalclean
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target clean
COMMAND ${CMAKE_COMMAND}
-DL=${CMAKE_BINARY_DIR}/files.dat
-P ${CMAKE_SOURCE_DIR}/remove.cmake)
# record.cmake:
IF(EXISTS ${L})
FILE(STRINGS ${L} FILES)
ENDIF()
LIST(APPEND FILES ${F})
LIST(REMOVE_DUPLICATES FILES)
STRING(REGEX REPLACE ; \n FILES ${FILES})
FILE(WRITE ${L} ${FILES}\n)
# remove.cmake:
IF(EXISTS ${L})
FILE(STRINGS ${L} FILES)
FILE(REMOVE ${FILES})
FILE(REMOVE ${L})
ENDIF()
The downside is that one cannot use the well-known clean target
anymore to purge the files but must trigger totalclean instead.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_EXE_LINKER_FLAGS for shared libraries?
On 12/13/2011 09:21 PM, David Cole wrote: On Tue, Dec 13, 2011 at 2:09 PM, Robert Dailey rcdai...@gmail.com wrote: Thanks for the info. It's a bit disappointing that it doesn't work like I expect. The CMAKE_MFC_FLAG should work as you say the link flags should, but it does not. As long as CMAKE_MFC_FLAG is set before I create my target, it works. Since CMAKE_SHARED_LINK_FLAGS does not work the same, I consider this a bug. There is no reason for it to exist up to the end of the file... it should only exist up to the call to create the target. For example, if I want to have 2 calls to add_library() in the same file, but specify link flags differently for each, how am I expected to do this without using the target specific property? You're not expected to do that. You should use the target property in that case. That's what they're there for. Or use sub-directory organization to have one target per sub-dir, and then set the variable appropriately in each sub-dir's CMakeLists file. And, there is a reason for it to exist up to the end of the file: it's called backwards compatibility, and we take it pretty seriously. The fact is that some variables are examined at configure-time, while CMake is processing add_executable and add_library calls, and all the other myriad commands that are affected by variables values, ... ... and some variables are examined later at generate-time, *after* CMake is done processing the commands, (in other words, at the end of the file). So: this particular case may be considered a bug by some, and a feature by others. Personally, I'm not sure what side of that fence to fall on. However, the primary purpose of this mailing list is to try to show you how you can do what you want to do with *existing* CMake. We also like to discuss options and future plans here. If you would like to report this as a bug, please feel free to add a bug report to the bug tracker. As for me, I wouldn't consider it as a bug, but it should perhaps be mentioned in the documentation which variables undergo this kind of lazy evaluation, i.e. configure-time vs. generate-time evaluation. This variable is not evaluated until the generation takes place, so the value at the end of the CMakeLists.txt will be in effect. Regards, Michael On Mon, Dec 12, 2011 at 11:26 PM, Michael Wild them...@gmail.com wrote: It needs to exist **at the end** of the CMakeLists.txt file containing the target. If you don't want to do that (or can't, as in your case), you can use the LINK_FLAGS target property instead. HTH Michael On 12/12/2011 11:39 PM, Robert Dailey wrote: I have attached a small CMake project that reproduces the issue I'm referring to. Please take a look :) - Robert Dailey On Mon, Dec 12, 2011 at 4:11 PM, Robert Dailey rcdai...@gmail.com mailto:rcdai...@gmail.com wrote: I forgot to say that the main issue is that my /NODEFAULTLIB link flag isn't showing up in visual studio. - Robert Dailey On Mon, Dec 12, 2011 at 4:10 PM, Robert Dailey rcdai...@gmail.com mailto:rcdai...@gmail.com wrote: Another issue... At what point is it most important for the values of CMAKE_SHARED_LINK_FLAGS to exist? I set the value of this variable before my call to add_library(), however after that at some point the flags will get reverted because I'm stepping out of function scope. Does it need to exist up to the end of the current cmake script? My flow is basically this (pseudo call stack): Enter CMakeLists.txt - Call define_project() function (in a separate cmake module) - - Call ignore_libs() function - - - Set CMAKE_SHARED_LINK_FLAGS with PARENT_SCOPE - - Call create_target() function - - - Call add_library() command Leave CMakeLists.txt I've done some testing and I find that before the call to add_library(), my flags are setup properly in the CMAKE_SHARED_LINK_FLAGS variable. - Robert Dailey On Mon, Dec 12, 2011 at 2:20 PM, Michael Wild them...@gmail.com mailto:them...@gmail.com wrote: On 12/12/2011 09:13 PM, Robert Dailey wrote: On Mon, Dec 12, 2011 at 2:10 PM, David Cole david.c...@kitware.com mailto:david.c...@kitware.com mailto:david.c...@kitware.com mailto:david.c...@kitware.com wrote: Apparently, they are undocumented, but there are also: CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS (and their per-config variants) for SHARED and MODULE library targets as well. Use CMAKE_SHARED_LINKER_FLAGS instead. Thanks for the information guys. I'm having a minor
Re: [CMake] Question about add_custom_target
On 12/07/2011 09:09 PM, Robert Dailey wrote: Anyone? AFAICT, all generator expressions documented for ADD_CUSTOM_COMMAND() and ADD_TEST() also work for ADD_CUSTOM_TARGET() although this isn't mentioned explicitly. IMO, you should file an appropriate bug report in order to have ADD_CUSTOM_TARGET()'s documentation enhanced, or to advise against using generator expressions therein in case it works just by accident. Regards, Michael On Tue, Dec 6, 2011 at 4:36 PM, Robert Dailey rcdai...@gmail.com wrote: Does $CONFIGURATION work in add_custom_target as it does in add_custom_command? The documentation doesn't state anything about this that I can see, but it seems like it should work. - Robert Dailey -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copy a input file from src folder to EXECUTABLE_OUTPUT_PATH
On 12/05/2011 10:30 PM, Totte Karlsson wrote:
Hi,
I have a tree of applications, some needing an inoput file to run. I have
CMake
compiling all of them and moving the executables to
EXECUTABLE_OUTPUT_PATH. In the src directories, I have some input.txt files
that
I want to be moved to the same folder as the executables.
How do I do that in CMake?
At configuration time:
CONFIGURE_FILE(path/to/input.txt ${EXECUTABLE_OUTPUT_PATH} COPYONLY)
Note that the destination directory, i.e. the EXECUTABLE_OUTPUT_PATH,
possibly must already exist, and refer to the EXECUTABLE_OUTPUT_PATH
variable only after it has received its value. BTW, this variable is
obsolete, use [CMAKE_]RUNTIME_OUTPUT_DIRECTORY[_CONFIG] variable/
properties instead.
At build time:
ADD_CUSTOM_TARGET(input ${CMAKE_COMMAND} -E copy_if_different
path/to/input.txt ${EXECUTABLE_OUTPUT_PATH})
ADD_DEPENDENCIES(OneOfYourExecutables input)
ADD_DEPENDENCIES(AnotherExecutable input)
or
ADD_CUSTOM_COMMAND(TARGET OneOfYourExecutables
COMMAND ${CMAKE_COMMAND} -E copy_if_different
path/to/input.txt $TARGET_FILE_DIR:OneOfYourExecutables)
ADD_CUSTOM_COMMAND(TARGET AnotherExecutable
COMMAND ${CMAKE_COMMAND} -E copy_if_different
path/to/input.txt $TARGET_FILE_DIR:AnotherExecutable)
Personally, I'd prefer the latter as it's clean and quite flexible.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
