date:20130213

Re: [CMake] Dependencies of generated files

2013-02-13 Thread Petr Kmoch

Hi Olaf.

You're missing a DEPENDS argument in your custom command to make
${foo_STATIC_LEXER_HPP} depend on ${foo_LEXER_HPP}. (Or, in your case,
MAIN_DEPENDENCY would probably be more appropriate).

Next, the custom target driving the lexer generation should depend on
its output, not its input - if no target requires a custom command's
output, that command is not run.

Finally, you don't need to set the dependency on
generate_foo_static_lexer - CMake does that automatically for
executable targets used in custom commands. Also, the GENERATED
property will be set by CMake.

In all, your CMakeList should look like this:

project(foo)

# generate foo's static lexer into the root of out-of-source build directory
set(foo_INCLUDE_PATH ${CMAKE_BINARY_DIR}/include/foo/io/foo)
set(foo_STATIC_LEXER_HPP ${foo_INCLUDE_PATH}/foo_static_lexer.hpp)
file(MAKE_DIRECTORY ${foo_INCLUDE_PATH})
set(foo_LEXER_HPP ${CMAKE_SOURCE_DIR}/include/foo/io/foo/lexer_impl.hpp)

add_executable(generate_foo_static_lexer generate_foo_static_lexer.cpp)
set_target_properties(generate_foo_static_lexer PROPERTIES
COMPILE_DEFINITIONS
"foo_LEXER_DYNAMIC_TABLES;BOOST_SPIRIT_LEXERTL_DEBUG")

add_custom_command(
   OUTPUT  ${foo_STATIC_LEXER_HPP}
   COMMAND generate_foo_static_lexer ${foo_STATIC_LEXER_HPP}
   MAIN_DEPENDENCY ${foo_LEXER_HPP}
   COMMENT "Generating foo static DFA lexer header ${foo_STATIC_LEXER_HPP}"
   )
add_custom_target(foo_dfa DEPENDS ${foo_STATIC_LEXER_HPP})

Hope this helps.

Petr

On Wed, Feb 13, 2013 at 7:20 PM, Olaf Peter  wrote:
>
> Hello,
>
> obviously I have a problem with the understanding of generating dependencies 
> of generated files.
>
> generate_foo_static_lexer is using ${foo_LEXER_HPP} to generate a header file 
> ${foo_STATIC_LEXER_HPP}. Each time ${foo_STATIC_LEXER_HPP} is changed the 
> header shall be regenerated. Later, ${foo_STATIC_LEXER_HPP} can be more than 
> one file (maybe list(xxx_HPP A;B;C)?? ).
>
> But this doesn't happen, only the exe is re-created. What's wrong?
>
> project(foo)
>
> # generate foo's static lexer into the root of out-of-source build directory
> set(foo_INCLUDE_PATH ${CMAKE_BINARY_DIR}/include/foo/io/foo)
> set(foo_STATIC_LEXER_HPP ${foo_INCLUDE_PATH}/foo_static_lexer.hpp)
> file(MAKE_DIRECTORY ${foo_INCLUDE_PATH})
> set(foo_LEXER_HPP ${CMAKE_SOURCE_DIR}/include/foo/io/foo/lexer_impl.hpp)
>
> add_executable(generate_foo_static_lexer generate_foo_static_lexer.cpp)
> set_target_properties(generate_foo_static_lexer PROPERTIES 
> COMPILE_DEFINITIONS "foo_LEXER_DYNAMIC_TABLES;BOOST_SPIRIT_LEXERTL_DEBUG")
>
> add_custom_command(
>OUTPUT  ${foo_STATIC_LEXER_HPP}
>COMMAND generate_foo_static_lexer ${foo_STATIC_LEXER_HPP}
>COMMENT "Generating foo static DFA lexer header ${foo_STATIC_LEXER_HPP}"
>)
> add_custom_target(foo_dfa DEPENDS ${foo_LEXER_HPP})
> add_dependencies(foo_dfa generate_foo_static_lexer)
> set_source_files_properties(${foo_STATIC_LEXER_HPP} PROPERTIES GENERATED 1)
> --
>
> 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] Parellel Visual Studio builds of targets in the same CMakeLists.txt sometimes fail

2013-02-13 Thread Brad King

On 11/05/2012 05:48 PM, Todd Greer wrote:
> in parallel, these targets sometimes seem to collide, yielding an error like 
> this:
> 
> CUSTOMBUILD : CMake error : Cannot restore timestamp 
> \CMakeFiles\generate.stamp

FYI, I've fixed this in upstream CMake here:

 VS: Replace generation timestamp file atomically
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2dc17f88

-Brad
--

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] Dynamic library RPATH on OSX

2013-02-13 Thread Steve Skutnik

After some more attempts, I discovered the issue which was somewhat unclear
to me before.

CMake has the option CMAKE_INSTALL_NAME_DIR which specifies the parameter
for the install_name_tool in OSX. I was attempting to use this with "Module
B", however it turns out this is incorrect. Instead, the user should use
this command on "Module A" such that when "Module B" links to "Module A",
it pulls up the full path to find "Module A".

Adding this to the "Module A" CMakeLists.txt and rebuilding correctly
propagated the path to "Module A" when building "Module B" - my executable
now finds the dynamic library correctly.

Hopefully this helps someone else in the future...

-Steve
---
Steve Skutnik, Ph.D.
http://neutroneconomy.blogspot.com


On Wed, Feb 13, 2013 at 11:58 AM, Steve Skutnik  wrote:

> I'm having an issue with the RPATH not showing up for one of my shared
> libraries on OSX. Basically, I end up with a "bare" rpath to one of my
> shared libraries (i.e., no path prefix) when I check my binary using otool
> - L
>
> Specifically, I have a project with a structure that looks like this
>
> project/module_A
> project/module_B
>
> I'm trying to build "Module B", which depends on a shared library I build
> in "Module A". (I also use several other shared libraries, but all of them
> are in system paths, i.e., /usr/local and /usr/lib.). What ends up
> happening is that all of the rpaths are set *except* for my shared library
> from Module A (for both the build and install versions of the binary).
>
> After carefully reading the CMake primer on RPath handling here:
>
> http://www.cmake.org/Wiki/CMake_RPATH_handling
>
> I tried the suggestion under "Always full rpath", i.e., my CMakeLists.txt
> file has the following:
>
> # use, i.e. don't skip the full RPATH for the build tree
> SET(CMAKE_SKIP_BUILD_RPATH  FALSE)
>
> # when building, don't use the install RPATH already
> # (but later on when installing)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>
> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
>
> # add the automatically determined parts of the RPATH
> # which point to directories outside the build tree to the install RPATH
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
>
>
> # the RPATH to be used when installing, but only if it's not a system 
> directory
> LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES 
> "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
> IF("${isSystemDir}" STREQUAL "-1")
>SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> ENDIF("${isSystemDir}" STREQUAL "-1")
>
>
> However, this still doesn't appear to be setting the RPATH variable for my
> dynamic library.  I likewise checked that CMAKE_INSTALL_RPATH is set
> correctly (i.e., the library from Module A sits in that directory).
> However, nothing I do seems to prefix an RPATH directory to my shared
> library for Module A.
>
> One other thing - I've also tried building this code on Linux
> (Ubuntu-12.10), and I've noticed that the same configuration correctly sets
> the RPATH for Module A - so this seems to be specific to OSX.
>
> What am I missing here? Going through the list archives, I've seen this
> problem pop up a few times with respect to OSX, but I haven't really seen
> anything that specifically solves this issue. Specifically, this message
> from a few weeks ago seems to be running into the exact same issue, but I
> don't see any replies:
>
> http://www.cmake.org/pipermail/cmake/2013-January/053335.html
>
> The only other thread I've seen on this recently is here:
>
> http://www.cmake.org/pipermail/cmake/2011-April/043888.html
>
> The solution here was pretty much to either use install_name_tool manually
> (which does work, but it requires one to do it each time you build) or to
> use BundleUtilities. However, I noticed that CMake runs install_name_tool
> on its own for a library which is built with Module B (i.e., I have
> libModuleB_core.dylib which is built and linked into the moduleB binary);
> i.e., this shows up in cmake_install.cmake. So shouldn't there be some way
> to get CMake to appropriately run install_name_tool for me for Module A as
> well? Or at the very least, is there a reason no RPATH is being appended to
> Module A?
>
> Thanks.
>
> -Steve
> ---
> Steve Skutnik, Ph.D.
> http://neutroneconomy.blogspot.com
>
--

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

[CMake] Dependencies of generated files

2013-02-13 Thread Olaf Peter


Hello,

obviously I have a problem with the understanding of generating 
dependencies of generated files.


generate_foo_static_lexer is using ${foo_LEXER_HPP} to generate a header 
file ${foo_STATIC_LEXER_HPP}. Each time ${foo_STATIC_LEXER_HPP} is 
changed the header shall be regenerated. Later, ${foo_STATIC_LEXER_HPP} 
can be more than one file (maybe list(xxx_HPP A;B;C)?? ).


But this doesn't happen, only the exe is re-created. What's wrong?

project(foo)

# generate foo's static lexer into the root of out-of-source build directory
set(foo_INCLUDE_PATH ${CMAKE_BINARY_DIR}/include/foo/io/foo)
set(foo_STATIC_LEXER_HPP ${foo_INCLUDE_PATH}/foo_static_lexer.hpp)
file(MAKE_DIRECTORY ${foo_INCLUDE_PATH})
set(foo_LEXER_HPP ${CMAKE_SOURCE_DIR}/include/foo/io/foo/lexer_impl.hpp)

add_executable(generate_foo_static_lexer generate_foo_static_lexer.cpp)
set_target_properties(generate_foo_static_lexer PROPERTIES 
COMPILE_DEFINITIONS "foo_LEXER_DYNAMIC_TABLES;BOOST_SPIRIT_LEXERTL_DEBUG")


add_custom_command(
   OUTPUT  ${foo_STATIC_LEXER_HPP}
   COMMAND generate_foo_static_lexer ${foo_STATIC_LEXER_HPP}
   COMMENT "Generating foo static DFA lexer header ${foo_STATIC_LEXER_HPP}"
   )
add_custom_target(foo_dfa DEPENDS ${foo_LEXER_HPP})
add_dependencies(foo_dfa generate_foo_static_lexer)
set_source_files_properties(${foo_STATIC_LEXER_HPP} PROPERTIES GENERATED 1)
--

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

[CMake] Dynamic library RPATH on OSX

2013-02-13 Thread Steve Skutnik

I'm having an issue with the RPATH not showing up for one of my shared
libraries on OSX. Basically, I end up with a "bare" rpath to one of my
shared libraries (i.e., no path prefix) when I check my binary using otool
- L

Specifically, I have a project with a structure that looks like this

project/module_A
project/module_B

I'm trying to build "Module B", which depends on a shared library I build
in "Module A". (I also use several other shared libraries, but all of them
are in system paths, i.e., /usr/local and /usr/lib.). What ends up
happening is that all of the rpaths are set *except* for my shared library
from Module A (for both the build and install versions of the binary).

After carefully reading the CMake primer on RPath handling here:

http://www.cmake.org/Wiki/CMake_RPATH_handling

I tried the suggestion under "Always full rpath", i.e., my CMakeLists.txt
file has the following:

# use, i.e. don't skip the full RPATH for the build tree
SET(CMAKE_SKIP_BUILD_RPATH  FALSE)

# when building, don't use the install RPATH already
# (but later on when installing)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)

SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

# add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)


# the RPATH to be used when installing, but only if it's not a system directory
LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
"${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
IF("${isSystemDir}" STREQUAL "-1")
   SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
ENDIF("${isSystemDir}" STREQUAL "-1")


However, this still doesn't appear to be setting the RPATH variable for my
dynamic library.  I likewise checked that CMAKE_INSTALL_RPATH is set
correctly (i.e., the library from Module A sits in that directory).
However, nothing I do seems to prefix an RPATH directory to my shared
library for Module A.

One other thing - I've also tried building this code on Linux
(Ubuntu-12.10), and I've noticed that the same configuration correctly sets
the RPATH for Module A - so this seems to be specific to OSX.

What am I missing here? Going through the list archives, I've seen this
problem pop up a few times with respect to OSX, but I haven't really seen
anything that specifically solves this issue. Specifically, this message
from a few weeks ago seems to be running into the exact same issue, but I
don't see any replies:

http://www.cmake.org/pipermail/cmake/2013-January/053335.html

The only other thread I've seen on this recently is here:

http://www.cmake.org/pipermail/cmake/2011-April/043888.html

The solution here was pretty much to either use install_name_tool manually
(which does work, but it requires one to do it each time you build) or to
use BundleUtilities. However, I noticed that CMake runs install_name_tool
on its own for a library which is built with Module B (i.e., I have
libModuleB_core.dylib which is built and linked into the moduleB binary);
i.e., this shows up in cmake_install.cmake. So shouldn't there be some way
to get CMake to appropriately run install_name_tool for me for Module A as
well? Or at the very least, is there a reason no RPATH is being appended to
Module A?

Thanks.

-Steve
---
Steve Skutnik, Ph.D.
http://neutroneconomy.blogspot.com
--

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

[CMake] Cmake 2.8.10 with Qt 5.0.1 under Win8 with VS2012: undefined external symbol

2013-02-13 Thread Meteorhead

Hi!

I have started fiddling with CMake aiming to serve as the makefile for a new
project aiming linux and Windows platforms, involving many other libs, test
modules, etc. Therefore it seems like the optimal choice. I wanted to create
a comprehensive “tutorial” for some friends (and collegues) coming mainly
from the Windows side of application development. Heavily commented
makefiles with multiple interdependant projects, each showing one feature of
CMake and getting more complex down the road.

However with Qt involved I cannot even compile two simple projects, one
targeting a shared library containing a simple QObject inherited class, and
the other targeting an executable linking againts this library. Problem is
that not even the library fails at linking with unresolved externals. I have
built projects with both qmake before and the VS-plugin, but something is
missing here. It seems as if the generated MOC files would not contain the
required symbols or if cmake would not add them to the sources when building
the target.

(I have removed some comments to make post shorter)

Source code

CMakefiles

nmake output

Naturally problems arise when USE_QT5 is set. All help is greatly
appreciated.

--
View this message in context:
http://cmake.3232098.n2.nabble.com/Cmake-2-8-10-with-Qt-5-0-1-under-Win8-with-VS2012-undefined-external-symbol-tp7583205.html
Sent from the CMake mailing list archive at Nabble.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

[CMake] VS7 Generator, empty source_group (Bug: #0003474)

2013-02-13 Thread Anton Helwart

Hi,

I wrote a small patch for the VS7 generator to fix bug #0003474

http://www.cmake.org/Bug/view.php?id=3474

I attached the patch in the bug report. Maybe someone could take a look at
it.
It would be great to have the bug fixed in some release in the future.
It doesn't stop the solution from building, but gets really annoying if you
have
a lot of source groups :-)

Regards, Anton
--

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] Dependencies of generated files

Re: [CMake] Parellel Visual Studio builds of targets in the same CMakeLists.txt sometimes fail

Re: [CMake] Dynamic library RPATH on OSX

[CMake] Dependencies of generated files

[CMake] Dynamic library RPATH on OSX

[CMake] Cmake 2.8.10 with Qt 5.0.1 under Win8 with VS2012: undefined external symbol

[CMake] VS7 Generator, empty source_group (Bug: #0003474)

7 matches

Site Navigation

Mail list logo

Footer information