Re: [CMake] Code and API review request for Qt5 CMake files

[Michael Hertling]

On 03/05/2012 01:35 AM, Stephen Kelly wrote:
> Michael Hertling wrote:
> 
>> Suppose the Qt folks decide that Qt5's core module doesn't need to
>> be explicitly requested because it is prerequisite for everything
>> else.
> 
> Just to disseminate information here, this is already the case.
> 
> You can currently do this:
> 
> find_package(Qt5Declarative)
> include_directories(${Qt5Declarative_INCLUDE_DIRS})
> add_definitions(${Qt5Declarative_DEFINITONS})
> target_link_libraries(foo ${Qt5Declarative_LIBRARIES})
> 
> Each find_package finds its dependencies and adds its dependencies values to 
> its own variables. So already, the core module (and in the above example, 
> the gui module) don't need to be explicitly mentioned.

That's not what I had in mind. AFAICS, the Qt5 modules' config files
are all single-component, and of course, they are expected to enable
all prerequisites necessary to enable their respective module.

What I thought of is: Suppose there's a comprehensive multi-component
Qt5Config.cmake which does not provide a Qt5Core component explicitly
because the latter is silently enabled anyway. So, FIND_PACKAGE(Qt5)
would yield solely Qt5Core, and FIND_PACKAGE(Qt5 COMPONENTS Qt5Gui)
would yield Qt5Gui and Qt5Core, e.g. Now, if Qt5_FOUND is allowed to
be FALSE just because Qt5Gui is missing, one can't use this variable
anymore to determine Qt5Core's availability; a totally unavailabe Qt5
would yield the same result. For a project that does need Qt5Core and
can use Qt5Gui - if available - this is crucial, but a reliable check
for the presence of Qt5Core would require further measures. However,
Alex recently came up with a proposal to distinguish mandatory from
optional components already in the FIND_PACKAGE() invocation, and
this seems capable to address that issue.

> This is one of the things I'd like feedback on, and on of the reasons I'm 
> asking people to try this out, or to read the generated Config files.
> 
> Can anyone say they've read the generated files? Has anyone confirm they 
> have run this or something like it? :
> 
> git clone git://gitorious.org/qt/qtbase.git
> cd qtbase
> ./configure
> ls lib/cmake

Yes. :)

> To see the input files for the generated config files see:
> 
> https://qt.gitorious.org/qt/qtbase/blobs/master/mkspecs/cmake/Qt5BasicConfig.cmake.in

Some remarks, though I haven't dissected each and every detail:

(1) Protecting imported targets: I suppose lines like

if (NOT _Qt5Gui_target)
set(_Qt5Gui_target 1)
add_library(Qt5::Gui SHARED IMPORTED)
endif()

serve to protect the Qt5::Gui imported target against redefinition
within the same scope? If so, look at the end of [1]. An inherited
directory property might be a cleaner and slightly more robust
alternative to a - rather fragile - variable:

DEFINE_PROPERTY(DIRECTORY PROPERTY Qt5Gui INHERITED ...)
GET_PROPERTY(p DIRECTORY PROPERTY Qt5Gui SET)
IF(NOT p)
SET_PROPERTY(DIRECTORY PROPERTY Qt5Gui TRUE)
ADD_LIBRARY(Qt5::Gui SHARED IMPORTED)
ENDIF()

Anyway, a minor issue and possibly not worth the effort.

(2) Enabling prerequisite Qt5 modules:

foreach(_module_dep ${_Qt5_MODULE_DEPENDENCIES})
if (NOT Qt5${_module_dep}_FOUND)
find_package(Qt5${_module_dep} REQUIRED)
endif()

endforeach()

Basically, the information provided by FIND_PACKAGE() here is already
available at configuration time, so there's no actual need to query it
at, say, deploy time. Instead, it could be weaved immediately into the
config file. However, doing it in the above-noted manner might be very
well intended, e.g. to keep the config files compact and regular and
to straightly express the modules' dependencies. If one decides to
do so, one should consider to use:

FIND_PACKAGE(Qt5${_module_dep} REQUIRED PATHS ... NO_DEFAULT_PATH)

Otherwise, FIND_PACKAGE() might load a config file from another Qt5
installation due to its fine-grained parameterization by variables
like CMAKE_PREFIX_PATH, in the cache as well as the environment.

(3) Enabling prerequisite external packages:

!!IF contains(QT_CONFIG, system-png)
find_package(PNG REQUIRED)
list(APPEND Qt5Gui_LIB_DEPENDENCIES ${PNG_LIBRARIES})
!!ENDIF

A similar consideration as in (2), but note that PNG does not have a
config file, so the PATHS/NO_DEFAULT_PATH interception will not work.
Is it permissible that a binary using Qt5Gui might be built against
a different PNG library than Qt5Gui has been built against? If so,
you could perhaps think about REQUIRED: IMO, FIND_PACKAGE() called
without that flag must not bail out because of anything not being
found. Instead, the user must have the chance to handle this by him/
herself. Note that Qt5 might be optional for the user's project. So,
REQUIRED should be passed to the internal FIND_PACKAGE() invocations
only if Qt5*_FIND_REQUIRED is set,

Re: [CMake] Code and API review request for Qt5 CMake files

[Michael Hertling]

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] Using cmake to build & link to autotools based project

[Michael Hertling]

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] CMake Linking Error

[Michael Hertling]

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::vector >*,
> std::vector >*)':
> 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(
> ) 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] Operator Precedence

[Michael Hertling]

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] top level make

[Michael Hertling]

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

[Michael Hertling]

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 b

Re: [CMake] Forcibly run 'moc' on Qt files that are NOT part of the build

[Michael Hertling]

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] transitive linking with separate projects

[Michael Hertling]

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] transitive linking with separate projects

[Michael Hertling]

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 /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] failing target

[Michael Hertling]

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] failing target

[Michael Hertling]

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] POST_BUILD & ALL_BUILD

[Michael Hertling]

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 target<1> ... target)

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] How to make package depend on tests?

[Michael Hertling]

On 03/06/2012 12:36 AM, Oliver kfsone Smith wrote:
> I have test and package configurations on my project, I want:
> 
>  cmake .
>  make package
> 
> to run force injection of the "test" target prior to building the 
> package target.
> 
> Can it be done? How? :)

By filing a solution to [1]. ;-)

In the meantime, you might provide a target on your own:

ADD_CUSTOM_TARGET(test_and_pack
  COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} --target test
  COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} --target package
)

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

[Michael Hertling]

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] Functions inherit parent variables?

[Michael Hertling]

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] Question regarding source tree structure and how to find libraries easily within that structure

[Michael Hertling]

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] avoid rebuilding targets depending on generated source files

[Michael Hertling]

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 wrote:
> 
>> 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 2>&1 > /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 2>&1 > /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 2>&1 > /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
&g

Re: [CMake] avoid rebuilding targets depending on generated source files

[Michael Hertling]

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 2>&1 > /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 2>&1 > /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 2>&1 > /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 wrote:
> 
>> 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_COMMA

Re: [CMake] avoid rebuilding targets depending on generated source files

[Michael Hertling]

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 wrote:
> 
>> 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 >> 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 

Re: [CMake] Transitive library dependencies with parallel builds

[Michael Hertling]

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/.dir/all targets do:

$(MAKE) -f CMakeFiles/.dir/build.make CMakeFiles/.dir/build

Finally, CMakeFiles/.dir/build in CMakeFiles/.dir/build.make
does build target  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] avoid rebuilding targets depending on generated source files

[Michael Hertling]

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 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 >> 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] Problems with CMake and static Qt plugins

[Michael Hertling]

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:
> 
> 
> #include
> #include
> 
> 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

[Michael Hertling]

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 
> 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] Functions inherit parent variables?

[Michael Hertling]

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 wrote:
> 
>> 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 
>>
>> 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 >> 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()
>>>>>
>>>>&

Re: [CMake] Functions inherit parent variables?

[Michael Hertling]

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 

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 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

[Michael Hertling]

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 a

Re: [CMake] Functions inherit parent variables?

[Michael Hertling]

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

[Michael Hertling]

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
  retu

Re: [CMake] Code and API review request for Qt5 CMake files

[Michael Hertling]

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".
>>>
>>

Re: [CMake] Code and API review request for Qt5 CMake files

[Michael Hertling]

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

Re: [CMake] How to recursively copy directories and subdirectories...

[Michael Hertling]

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] add_executable and extension of source file

[Michael Hertling]

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:


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.


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] Code and API review request for Qt5 CMake files

[Michael Hertling]

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 Qt5Config.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 variabl

Re: [CMake] passing arguments to the final make

[Michael Hertling]

On 02/23/2012 11:11 AM, Andrea Crotti wrote:
> On 02/23/2012 06:20 AM, Michael Hertling wrote:
>>
>> 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
>>
> Yes well the problem is that it should work on Windows, and at least
> with MinGW and with Gnu Makefiles.
> I tried and I failed with this approach so I'll just drop the idea...

If you want to revive it, please come up with a minimal hand-written
Makefile that exhibits this behaviour for further investigation, but
like I said, I'd recommend against that approach for CMake-generated
Makefiles.

> Also because typing
> 
> make do_this
> ./test.py
> 
> is not much different than "SCRIPT=test.py make do_this"

Note that

SCRIPT=test.py make do_this

and

make do_this SCRIPT=test.py

aren't equivalent, see (1) and (3) above. They might differ right
w.r.t. the SCRIPT macro's value while the Makefile is processed.

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

[Michael Hertling]

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] delayed target

[Michael Hertling]

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] Shared intermediary files

[Michael Hertling]

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

[Michael Hertling]

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] passing arguments to the final make

[Michael Hertling]

On 02/22/2012 06:56 PM, Andrea Crotti wrote:
> On 02/22/2012 05:32 PM, Andrea Crotti wrote:
>>
>> 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?
>>
> 
> I tried what you suggested and with this:
> add_custom_target(dev_no_run
>COMMAND ${PYTHON_EXECUTABLE} ${DEV_MAIN} -w ${WORKSPACE} 
> ${APPLICATION} --develop_only -l info
>COMMAND ${PYTHON_EXECUTABLE} \${SCRIPT}
>)
> 
> I get this in the Makefile:
> 
> CMakeFiles/dev_no_run:
>  /usr/bin/python 
> /home/andrea/git_projs/PSI_Hamburg/utils/utils/bin/dev_main.py -w 
> /home/andrea/git_projs 
> /home/andrea/git_projs/Minimum_Drag/airbus.application.minimum_drag 
> --develop_only -l info
>  /usr/bin/python ${SCRIPT}
> 
> which is probably not what I want, because for a Makefile it should be 
> $(SCRIPT), right?

In Makefiles, $(SCRIPT) and ${SCRIPT} are equivalent, see [1]. However,
parentheses can have a special meaning w.r.t. a library's object files,
and $() is primarily associated with the shell's command substitution.
Thus, I personally prefer ${} for dereferencing macros in Makefiles
since it's quite unambiguous.

Regards,

Michael

> [1] http://www.gnu.org/software/make/manual/html_node/Reference.html#Reference
--

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

[Michael Hertling]

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] passing arguments to the final make

[Michael Hertling]

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] delayed target

[Michael Hertling]

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] External projects and make clean

[Michael Hertling]

On 02/17/2012 10:16 AM, Oliver Boesche wrote:
> Hi,
> 
> I use external projects e.g. to build BOOST for my own project. In that 
> case I want to prevent the project to be system or version dependent.
> 
> So I build my dependencies successful with external project (and its 
> great), but if use make clean it will clean all stuff and I have to 
> rebuild the external projects again (take some time with BOOST).
> 
> Is there a solution to prevent an external project from cleaning when I 
> call 'make clean'?
> 
> Kind regards
> 
> Oliver Boesche

For the Makefile generators, I could offer the following approach:

# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)

INCLUDE(ExternalProject)

ExternalProject_Add(external
SOURCE_DIR ${CMAKE_SOURCE_DIR}/external
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=
)

FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
ExternalProject_Get_Property(external INSTALL_DIR)
TARGET_LINK_LIBRARIES(main ${INSTALL_DIR}/lib/libf.so)

ExternalProject_Get_Property(external STAMP_DIR)

ADD_CUSTOM_TARGET(restorestampfiles
COMMAND ${CMAKE_COMMAND}
-DSTAMP_DIR="${STAMP_DIR}"
-P "${CMAKE_SOURCE_DIR}/restorestampfiles.cmake"
COMMENT "Restoring stamp files")

ADD_CUSTOM_TARGET(backupstampfiles
COMMAND ${CMAKE_COMMAND}
-DSTAMP_DIR="${STAMP_DIR}"
-P "${CMAKE_SOURCE_DIR}/backupstampfiles.cmake"
COMMENT "Backing up stamp files")

ADD_CUSTOM_TARGET(toplevel-clean
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
 --target backupstampfiles
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
 --target clean
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
 --target restorestampfiles)

# external/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(EXTERNAL C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
ADD_LIBRARY(f SHARED f.c)
INSTALL(TARGETS f DESTINATION lib)

# backupstampfiles.cmake:
FILE(GLOB_RECURSE STAMP_FILES "${STAMP_DIR}/*")
FOREACH(i IN LISTS STAMP_FILES)
IF(NOT i MATCHES "\\.bak$" AND NOT IS_DIRECTORY "${i}")
FILE(RENAME "${i}" "${i}.bak")
ENDIF()
ENDFOREACH()

# restorestampfiles.cmake:
FILE(GLOB_RECURSE STAMP_FILES "${STAMP_DIR}/*")
FOREACH(i IN LISTS STAMP_FILES)
IF(i MATCHES "\\.bak$")
STRING(REGEX REPLACE "\\.bak$" "" j "${i}")
FILE(RENAME "${i}" "${j}")
ENDIF()
ENDFOREACH()

The basic idea is to backup the external project's stamp files before
cleaning, and restore them afterwards. In this way, the steps of the
external project aren't performed during the next build. As a proof,
configure and build the above-noted exemplary project, then issue:

make clean; make

You'll see that the external and the toplevel project are both rebuild
although the external one's binary survives the cleaning. Now, issue:

make toplevel-clean; make

This time, the external project's steps are left out, and only the
toplevel project is rebuilt. In order to be absolutely sure, remove
the ${CMAKE_BINARY_DIR}/external-prefix/lib/libf.so library file to
see "make toplevel-clean; make" fail, whereas "make clean; make" re-
builds the missing file and, thus, succeeds.

Regrettably, the targets "restorestampfiles" and "backupstampfiles"
can not be turned into a custom step of the external project:

ExternalProject_Add_Step(external restore
COMMAND ${CMAKE_COMMAND} ... -P ...restorestampfiles.cmake
DEPENDERS mkdir)

ExternalProject_Add_Step(external backup
COMMAND ${CMAKE_COMMAND} ... -P ...backupstampfiles.cmake
DEPENDEES install)

This would be quite elegant, but apparently, the out-of-dateness of the
external project's steps is recognized before the stamp files are re-
stored. Moreover, I didn't manage to make this appoach work with VS.

IMO, the principal question in this regard is: What do we expect from
the "clean" target w.r.t. external projects? Usually, the latters are
not subject to the toplevel project's development, so one would like
to build them once, but omit them from cleaning. OTOH, there must be
a possibility to clean the toplevel project along with the external
ones in order to perform a full rebuild. AFAICS, the EP module does
not support both variants. A conceptual solution I can imagine is:

- Add a "clean" step - running a CLEAN_COMMAND, possibly defaulting
  to "make clean" - to the external project which is performed when
  the toplevel project is cleaned.

- Add a flag, say, EXCLUDE_FROM_CLEAN that, when specified, excludes
  the external project from the toplevel project's "clean" target.

This EXCLUDE_FROM_CLEAN flag in conjunction with the STEP_TARGETS option
of ExternalProject_Add() would allow for the definition of fine-grained
"clean" targets for external projects. E.g.,

External_Project_Add(boost
...
E

Re: [CMake] find both shared and static versions?

[Michael Hertling]

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
> approachof
> 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 p

Re: [CMake] How to have a static/shared option in a Find script ?

[Michael Hertling]

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 ?

[Michael Hertling]

On 02/16/2012 11:10 AM, Barth wrote:
> Hello again, 
> 
> A short question about your proposal :
> 
> Michael Hertling wrote
>>
>> (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.
>>
> Why use DIM_USE_STATIC here, and not DIM_FIND_COMPONENTS ? 
> I would think that we get rid of DIM_USE_STATIC if we use components. 

Uhhh, yes, you're absolutely right. Of course, with a component-
aware find module, one would request the static library via

FIND_PACKAGE(DIM COMPONENTS static)

instead of DIM_USE_STATIC. In fact, the latter becomes obsolete
and can be dropped. Thanks for the hint, and sorry for not re-
reading my own reply carefully before hitting "Send"... ;-)

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 ?

[Michael Hertling]

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] MSBuild and automatic project file regenation

[Michael Hertling]

On 02/09/2012 05:35 PM, Bill Hoffman wrote:
> I took a look at this, and it is behaving as expected with VS.  VS does 
> NOT have a depend on compile flags.  You can change a .vcproj file and 
> the flags it uses all you want, and VS will NOT rebuild any files 
> because of that.

OK, I see. So, it's a shortcoming of VS, if I understand correctly: No
dependency of object files on project files, and I guess that this is
not amendable by the means of CMake.

> So, as far as VS is concerned your source file has not changed and does 
> not need to rebuild.  I modified your example and --build works 
> perfectly (I change the NUMBER in the CMakeLists.txt and main is rebuilt 
> with one invocation of cmake --build .)
> 
> 
> 
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(BUILD C)
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "#include 
> #include 
> int main(void)
> {
>printf(\"%d\\n\",NUMBER);
>return 0;
> }
> ")
> include_directories(${CMAKE_BINARY_DIR})
> ADD_EXECUTABLE(main main.c)
> set(NUMBER 2)
> configure_file(main.h.in main.h)
> 
> 
> $ cat ../main.h.in
> #define NUMBER @NUMBER@

I.e., in order to trigger a rebuild with VS, an actual change in the
sources must have taken place - good to know. Many thanks, Bill and
Aaron, for spending time on this 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] External project source

[Michael Hertling]

On 02/13/2012 09:02 AM, Nicholas Yue wrote:
> On 13/02/12 6:47 PM, Eric Noulard wrote:
>> 2012/2/13 Nicholas Yue:
>>> 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] How to use CMake with icc via configuration options when needing interprocedural optimization?

[Michael Hertling]

On 02/10/2012 12:48 PM, janitor 048 wrote:
> Thank you so much for the hint. Setting the environment variable CXX from
> within my CMakeLists.txt via
> SET(ENV{CXX} "icpc")
> but before any call to project() or enable_language() seems indeed to do
> the trick.
> 
> Setting CMAKE_CXX_FLAGS_RELEASE or CMAKE_CXX_FLAGS_DEBUG at this stage
> however does not work. This apparently needs to go after the project()
> statement.

Sorry, my bad: CMAKE_CXX_FLAGS_ are typical cache variables,
i.e. they are meant to receive their values on the command line or
in the GUI, and their default fallback values are set when C++ is
enabled in Modules/CMakeCXXInformation.cmake by:

SET(CMAKE_CXX_FLAGS_... "${CMAKE_CXX_FLAGS_..._INIT}" CACHE STRING "...")

This SET() command overwrites the value in the current scope if there's
not already a value in the cache. Thus, in order to set these variables
along with the compiler in your IF()-ENDIF() block before PROJECT() or
ENABLE_LANGUAGE() - where there're placed well, IMO - just cache them:

IF (MY_COMPILER_OPTION STREQUAL "Intel")
  MESSAGE(STATUS "** Compiling with Intel settings **")
  SET(ENV{CXX} "icpc")
  SET(CMAKE_CXX_FLAGS_RELEASE "-O3 -w" CACHE STRING "...")
  SET(CMAKE_CXX_FLAGS_DEBUG "-g" CACHE STRING "...")
ENDIF ()

This will make the above-noted SET() command a no-op. Consider to use
the FORCE option if you want to modify/enhance/replace flags the user
might have already specified on the command line or in the GUI.

> I could of course set the environment cxx-flags in the same way as above.
> This would somewhat sacrifice the nice RELEASE / DEBUG distinction but
> maybe this can be done by some if-statements (there certainly is a way to
> query the CMAKE_BUILD_TYPE variable, right?).

Constructs like

IF(CMAKE_BUILD_TYPE STREQUAL Debug)
...
ENDIF()

or better

STRING(TOUPPER "${CMAKE_BUILD_TYPE}" CMAKE_BUILD_TYPE)
IF(CMAKE_BUILD_TYPE STREQUAL DEBUG)
...
ENDIF()

are possible, but only meaningful for single-configuration generators.
The CMAKE_CXX_FLAGS_ variables are definitely the way to go.

Regards,

Michael

> 2012/2/9 Michael Hertling 
> 
>> 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 **")
>>  

Re: [CMake] ansi color

[Michael Hertling]

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] PARENT_SCOPE for unset()?

[Michael Hertling]

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  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  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 wrote:
>>>
 On Thu, Feb 9, 2012 at 2:41 PM, Robert Dailey wrote:

> 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 wrote:
>
>> 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] Copying Files into build-dir under Visual Studio vs. Codeblocks/Win32 vs. Codeblocks/Linux

[Michael Hertling]

On 02/10/2012 09:41 AM, Eric Noulard wrote:
> 2012/2/10 Stefan Fendt :
>> 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 $. 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[_] 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] MSBuild and automatic project file regenation

[Michael Hertling]

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 
> 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 " 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/ 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...

[Michael Hertling]

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
>> "#include
>> #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] How to use CMake with icc via configuration options when needing interprocedural optimization?

[Michael Hertling]

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...

[Michael Hertling]

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 
#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] runtime dependencies for tests

[Michael Hertling]

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] cmake can't find some crtbegin.so, libgcc, libgcc_s under certain conditions

[Michael Hertling]

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-796>lsr /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

Re: [CMake] Adding a generated file as a dependency to a target

[Michael Hertling]

On 01/27/2012 07:15 PM, Michael Hertling wrote:
> On 01/27/2012 06:41 PM, Schuchard, Matthew wrote:
>> Contrary to the CMake FAQ, but consistent with what I have been reading 
>> elsewhere, it does not seem possible for me with CMake 2.8.6 to add a 
>> generated file as a dependency to a target, even in the same directory.
>>
>> I have done something similar to the following:
>>
>> add_custom_command(OUTPUT foo.ext)
>> add_executable(foo foo2.ext)
>> add_custom_target(foo_custom DEPENDS foo.ext)
>> set_source_files_properties(foo.ext PROPERTIES GENERATED TRUE)
>> add_dependencies(foo foo_custom)
>>
>> The above will not cause a dependency of foo on foo.ext, and when attempting 
>> to run make, throws an error of:
>> No rule to make target 'CMakeFiles/foo_custom.dir/requires'
>>
>> Could anyone please shine some light on this?
>> What I have been reading elsewhere (CMake mailing list, stackoverflow, etc.) 
>> is that the majority of the time, attempting something similar to the above 
>> does not succeed.
>> Could this fix be included among 2.8.8 updates?
> 
> Is foo2.txt in ADD_EXECUTABLE() a typo? Could you provide a minimal but
> complete example which exposes your issue for detailed investigation?
> 
> The DEPENDS clause of custom targets/commands should always be used
> with *full* paths, even if the concerned files are generated in the
> same CMakeLists.txt, since the behavior w.r.t. relative paths isn't
> specified. [...]

Addendum: The documentation for ADD_CUSTOM_COMMAND/TARGET() states

[ADD_CUSTOM_COMMAND()]
"If an output name is a relative path it will be interpreted relative to
the build tree directory corresponding to the current source directory."
...
"If any dependency is an OUTPUT of another custom command in the same
directory (CMakeLists.txt file) CMake automatically brings the other
custom command into the target in which this command is built."

and

[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)."

IMO, these wordings imply that within the same CMakeLists.txt, one can
specify the same paths for the DEPENDS clauses as have been specified
for the OUTPUT clause - including relative ones, and AFAICS, it does
actually work. Nonetheless, the usual advice to use full paths makes
things bullet-proof.

Regards,

Michael

> [...] So, you might retry with DEPENDS ${CMAKE_CURRENT_BINARY_
> DIR}/foo.ext. Besides, the GENERATED property doesn't need to be set
> on files generated by ADD_CUSTOM_COMMAND(OUTPUT ...) as this is done
> automatically.
> 
> 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] Adding a generated file as a dependency to a target

[Michael Hertling]

On 01/27/2012 06:41 PM, Schuchard, Matthew wrote:
> Contrary to the CMake FAQ, but consistent with what I have been reading 
> elsewhere, it does not seem possible for me with CMake 2.8.6 to add a 
> generated file as a dependency to a target, even in the same directory.
> 
> I have done something similar to the following:
> 
> add_custom_command(OUTPUT foo.ext)
> add_executable(foo foo2.ext)
> add_custom_target(foo_custom DEPENDS foo.ext)
> set_source_files_properties(foo.ext PROPERTIES GENERATED TRUE)
> add_dependencies(foo foo_custom)
> 
> The above will not cause a dependency of foo on foo.ext, and when attempting 
> to run make, throws an error of:
> No rule to make target 'CMakeFiles/foo_custom.dir/requires'
> 
> Could anyone please shine some light on this?
> What I have been reading elsewhere (CMake mailing list, stackoverflow, etc.) 
> is that the majority of the time, attempting something similar to the above 
> does not succeed.
> Could this fix be included among 2.8.8 updates?

Is foo2.txt in ADD_EXECUTABLE() a typo? Could you provide a minimal but
complete example which exposes your issue for detailed investigation?

The DEPENDS clause of custom targets/commands should always be used
with *full* paths, even if the concerned files are generated in the
same CMakeLists.txt, since the behavior w.r.t. relative paths isn't
specified. So, you might retry with DEPENDS ${CMAKE_CURRENT_BINARY_
DIR}/foo.ext. Besides, the GENERATED property doesn't need to be set
on files generated by ADD_CUSTOM_COMMAND(OUTPUT ...) as this is done
automatically.

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

[Michael Hertling]

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 wrote:
> 
>> On 01/13/2012 05:06 PM, David Cole wrote:
>>> On Fri, Jan 13, 2012 at 10:22 AM, Michael Hertling 
>> 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 " 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 t

Re: [CMake] execute a script before and after configuration

[Michael Hertling]

On 01/21/2012 11:28 AM, Dominik Szczerba wrote:
> On Sat, Jan 21, 2012 at 10:50 AM, Dominik Szczerba  
> 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 
#include 
#include 

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 
#include 
#include 

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  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 s

Re: [CMake] Revision header

[Michael Hertling]

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 
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] Fwd: building libs and specifying addition folders

[Michael Hertling]

On 01/19/2012 08:15 AM, Dev Guy wrote:
> On Thu, Jan 19, 2012 at 1:01 AM, John Drescher  wrote:
>> -- Forwarded message --
>> From: John Drescher 
>> Date: Thu, Jan 19, 2012 at 1:00 AM
>> Subject: Re: [CMake] building libs and specifying addition folders
>> To: Dev Guy 
>>
>>
>> On Wed, Jan 18, 2012 at 10:57 PM, Dev Guy  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] Compile multiple-sources at a time?

[Michael Hertling]

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] execute a script before and after configuration

[Michael Hertling]

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] shared library with CMake in kdevelop4

[Michael Hertling]

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" 
>  >À : 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] shared library with CMake in kdevelop4

[Michael Hertling]

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] Custom configuration types in Visual Studio

[Michael Hertling]

On 01/13/2012 05:06 PM, David Cole wrote:
> On Fri, Jan 13, 2012 at 10:22 AM, Michael Hertling  
> 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 " 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] MSBuild and automatic project file regenation

[Michael Hertling]

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 
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 " 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/ 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

[Michael Hertling]

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 " 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

[Michael Hertling]

On 01/10/2012 07:09 PM, Óscar Fuentes wrote:
> Michael Hertling 
> 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] How not to copy a link

[Michael Hertling]

On 01/11/2012 04:52 PM, David Cole wrote:
> On Wed, Jan 11, 2012 at 10:10 AM, Michael Hertling  
> wrote:
>> On 01/07/2012 03:52 PM, David Cole wrote:
>>> On Sat, Jan 7, 2012 at 9:47 AM, David Cole  wrote:
>>>> On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling  
>>>> 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,
>>>

Re: [CMake] How not to copy a link

[Michael Hertling]

On 01/07/2012 03:52 PM, David Cole wrote:
> On Sat, Jan 7, 2012 at 9:47 AM, David Cole  wrote:
>> On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling  
>> 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_CURRE

Re: [CMake] Cmake coloring gcc output on errror

[Michael Hertling]

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 2>&1" into sed/awk/perl/ 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 
...
% make VERBOSE=1 2>&1 | 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] MSBuild and automatic project file regenation

[Michael Hertling]

On 01/09/2012 07:56 PM, Óscar Fuentes wrote:
> Michael Hertling 
> 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] Copying of 3rd party DLLs in a POST-BUILD step

[Michael Hertling]

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}/$"
> 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

[Michael Hertling]

On 01/09/2012 02:34 PM, David Cole wrote:
> On Sun, Jan 8, 2012 at 11:59 PM, Óscar Fuentes  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] How not to copy a link

[Michael Hertling]

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] how to setup cmake_c/xx_flags per toolchain?

[Michael Hertling]

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 to "install" then "test"?

[Michael Hertling]

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 main2:
ADD_EXECUTABLE(main2 main.c)
ADD_CUSTOM_COMMAND(TARGET main2 POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
$
${CMAKE_BINARY_DIR}/test/bin/$)
INSTALL(TARGETS main2 DESTINATION bin)
ADD_TEST(NAME main2
COMMAND ${CMAKE_BINARY_DIR}/test/bin/$)

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] Interrupt problems in cmake-gui

[Michael Hertling]

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] Problem with set_source_files_properties

[Michael Hertling]

On 01/05/2012 02:42 PM, Mateusz Loskot wrote:
> On 5 January 2012 12:31, vivek goel  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] Add Custom COmmand and CMAKE_CFG_INTDIR

[Michael Hertling]

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 name
>   $= main file (.exe, .so.1.2, .a)
>   $ = file used to link (.a, .lib, .so)
>   $ = file with soname (.so.3)
> 
> This should work:
>COMMAND $

AFAIK, CMake examines the first argument after the COMMAND clause in
ADD_CUSTOM_COMMAND() whether it denotes an executable target, i.e.

COMMAND $

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 Jackson
>>
>> 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 Jackson"
>>> Date: Wed, Jan 4, 2012 1:28 pm
>>> Subject: [CMake] Add Custom COmmand and CMAKE_CFG_INTDIR
>>> To: "cmake@cmake.org List"
>>>
>>> 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] RC compiler on Linux - new problem

[Michael Hertling]

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 -G"Unix 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 

Re: [CMake] Trying to get build info for a target

[Michael Hertling]

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

[Michael Hertling]

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] 2D arrays

[Michael Hertling]

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  wrote:
> 
>> On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling wrote:
>>
>>> 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] 2D arrays

[Michael Hertling]

On 12/01/2011 06:04 PM, Robert Dailey wrote:
> On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling wrote:
> 
>> 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] CMAKE_EXE_LINKER_FLAGS for shared libraries?

[Michael Hertling]

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  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  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 >>>> <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 >>>> <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
>

Re: [CMake] How to find list of directories

[Michael Hertling]

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] Transitive link question

[Michael Hertling]

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] Fwd: Re: Compiler debug file, howto remove in clean?

[Michael Hertling]

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
>>   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] Top level target depending on a file

[Michael Hertling]

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 
>>>>>
>>>>>> 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
>>>>>>   $
>>>>>>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 $
>>>>>> --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
>>>>>>
>>>>>>&

Re: [CMake] Top level target depending on a file

[Michael Hertling]

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

[Michael Hertling]

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 
>>>
>>>> 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
>>>>   $
>>>>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 $
>>>> --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 
>>>>>
>>>>>> 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 l

Re: [CMake] CMAKE_EXE_LINKER_FLAGS for shared libraries?

[Michael Hertling]

On 12/13/2011 09:21 PM, David Cole wrote:
> On Tue, Dec 13, 2011 at 2:09 PM, Robert Dailey  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  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 >>> > 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 >>> > 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 >>> > wrote:

 On 12/12/2011 09:13 PM, Robert Dailey wrote:
 > On Mon, Dec 12, 2011 at 2:10 PM, David Cole
 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

Re: [CMake] Copy a input file from src folder to EXECUTABLE_OUTPUT_PATH

[Michael Hertling]

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
>>>  //input.txt $)
>>> ADD_CUSTOM_COMMAND(TARGET AnotherExecutable
>>>  COMMAND ${CMAKE_COMMAND} -E copy_if_different
>>>  //input.txt $)
>>>
>>> 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"
>> $
>> )
>>
>> 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 $
> 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 $/f.dat
COMMAND ${CMAKE_COMMAND}
-DF=$/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 $/g.dat
COMMAND ${CMAKE_COMMAND}
-DF=$/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 $/h.dat
COMMAND ${CMAKE_COMMAND}
-DF=$/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 $
--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