Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

> An inspection of your CMakeLists.txt file [1] and the outputs > of "make VERBOSE=1" [2,3] reveals the following goings-on: > > In [2], the lines 13 and 16 generate the object files > > CMakeFiles/Tech.dir/src/tech/Pch.cpp.o > CMakeFiles/Tech.dir/src/tech/tech/Atomic.cpp.o > > and obviously, these

Re: [CMake] Fortran dependency scanning

They are listed as dependencies for the target, ie: add_executable(myexe Module1.F90) or add_executable(myexe Module2.F90) depending on whether OPTION1 is defined or not (really, there's an option(USE_OPTION1) etc). The actual project is way more complicated than this -- we store the files

Re: [CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?

Am Dienstag, 29. März 2011, 09:41:36 schrieb Brad King: > On 03/29/2011 05:19 AM, Rolf Eike Beer wrote: > > The basic idea is: any symbols from those private libraries are, well, > > private. The user only ever sees the symbols from the public library. In > > fact he _can't_ even link to the privat

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

On 03/29/2011 04:14 PM, David Doria wrote: >> Most likely coming from here: >> /home/doriad/src/CMake/Modules/UsewxWidgets.cmake(72): SET(CMAKE_CXX_FLAGS >> ${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS} ) > > I added: > message("CMAKE_CXX_FLAGS: ${CMAKE_CXX_FLAGS}") > > and the output is: > > CMAKE_

Re: [CMake] Bug fix requests for the *next* release of CMake...

On Tue, 29 Mar 2011 13:56:03 -0400, David Cole said: >Now that we have released CMake 2.8.4, *now* would be a great time to >prioritize bug fixes for the next release of CMake. -- Sean

Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...

I'll third that. I'd like to see 8438 addressed as well. -Mike On 03/29/2011 02:56 PM, Tyler wrote: > Eric, those all look good, but I'd like to particularly +1 this one: > > http://public.kitware.com/Bug/view.php?id=8438 > > I've hacked around this deficiency in several places and I'm sure > ot

Re: [CMake] Fortran dependency scanning

On 03/29/2011 11:53 AM, Tim Gallagher wrote: > Hi, > > We ran into an issue using CMake with our fortran project. We have > constructions such as: > > ... > #ifdef OPTION1 > USE Module1 > #else > USE Module2 > #endif > ... > > It's not actually finding modules as dependencies. Any thoughts?

Re: [CMake] Bug fix requests for the *next* release of CMake...

On 2011-03-29 13:56-0400 David Cole wrote: Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Please move s

Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...

Eric, those all look good, but I'd like to particularly +1 this one: http://public.kitware.com/Bug/view.php?id=8438 I've hacked around this deficiency in several places and I'm sure other users have as well. It would be nice to replace these hacks with a nice simple solution. Thanks, tyler On T

Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...

2011/3/29 David Cole : > > Please discuss issues here as needed, and add notes to existing issues in > the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will > be looking at the mailing list and activity in the bug tracker to help > prioritize the bug fixes that will occur ove

Re: [CMake] Bug fix requests for the *next* release of CMake...

http://public.kitware.com/Bug/view.php?id=11206 John ___ 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.cma

[CMake] Bug fix requests for the *next* release of CMake...

Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. Please move specific discussions into the bugs themselves o

Re: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols

Hi Alex, Thanks for the change. The version you sent didn't end up working here (with just a CXX project). The line to set the compiler is checking for "CXX" but, at least on my system, "${_lang}" is set to "c++". Once I changed the line to check for "CXX" or "c++", it worked fine. I also n

[CMake] Fortran dependency scanning

Hi, We ran into an issue using CMake with our fortran project. We have constructions such as: ... #ifdef OPTION1 USE Module1 #else USE Module2 #endif ... It's not actually finding modules as dependencies. Any thoughts? I am using version 2.8.1, I can try to upgrade if somebody thinks it is

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

> Most likely coming from here: > /home/doriad/src/CMake/Modules/UsewxWidgets.cmake(72): SET(CMAKE_CXX_FLAGS > ${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS} ) I added: message("CMAKE_CXX_FLAGS: ${CMAKE_CXX_FLAGS}") and the output is: CMAKE_CXX_FLAGS: -pthread -ftemplate-depth-50 -Wall -Wno-depreca

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

On 3/29/2011 9:49 AM, David Doria wrote: You might want to try running cmake --trace and see if something odd is happening when it is run. -Bill Here is the output of the trace: http://pastebin.com/MfTcNHFE It looks like the definitions list is being created and applied to the target, does i

Re: [CMake] builds using mingw with sources on different drive

On 03/29/2011 02:28 AM, J Decker wrote: > This ends up building a command line that looks like > > (On c:) > > cd L:\games\spring\cont\base & make_gamedata_arch.bat ... > > since the current drive is the C drive, this doesn't change the drive, > it only changes the drive on L:, so you'd have

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

> You might want to try running cmake --trace and see if something odd is > happening when it is run. > > -Bill > Here is the output of the trace: http://pastebin.com/MfTcNHFE It looks like the definitions list is being created and applied to the target, does it not? (see the last 10 lines of tha

Re: [CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?

On 03/29/2011 05:19 AM, Rolf Eike Beer wrote: > The basic idea is: any symbols from those private libraries are, well, > private. The user only ever sees the symbols from the public library. In > fact he _can't_ even link to the private libraries on Windows as we never > install the .lib files. And

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

On 3/29/2011 9:22 AM, David Doria wrote: My standalone example works fine: http://pastebin.com/tGjX1AZ8 You can see that the UNIX and DAVID definitions are both passed. Maybe something is "overriding" the definitions in my real example? I see these definitions: D_FILE_OFFSET_BITS=64 -DWXUSIN

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

>> Can you create a standalone example of this to make it easier to debug? > > add_executable(foo foo.cxx) > ... > Bill, My standalone example works fine: http://pastebin.com/tGjX1AZ8 You can see that the UNIX and DAVID definitions are both passed. Maybe something is "overriding" the definition

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

On 3/29/2011 8:59 AM, David Doria wrote: Did you do a make VERBOSE=1 to see what was being passed to the compiler? Yes, none of the definitions are being passed: http://pastebin.com/X0t0L4Jv David Can you create a standalone example of this to make it ea

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

> > Did you do a make VERBOSE=1 to see what was being passed to the compiler? > Yes, none of the definitions are being passed: http://pastebin.com/X0t0L4Jv David ___ Powered by www.kitware.com Visit other Kitware open-sou

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

On 3/29/2011 8:25 AM, David Doria wrote: (with and without quotes around ${my_definitions} in the set_target_properties line) The message command seems to be fine: my definitions: UNIX;USE_ITK;USE_FLOAT_PIXELS;PIXEL_DIMENSION=1 but the #if defined(UNIX) still fails in the code! Did you do a

Re: [CMake] set_target_properties not setting COMPILE_DEFINITIONS?

On Tue, Mar 29, 2011 at 1:58 AM, Michael Hertling wrote: > On 03/29/2011 07:47 AM, Michael Hertling wrote: > > On 03/28/2011 08:23 PM, David Doria wrote: > >> I have setup a list of definitions: > >> > >> SET(MAIN_BUILD_DEFINITIONS "${MAIN_BUILD_DEFINITIONS} UNIX;") > >> SET(MAIN_BUILD_DEFINITIONS

Re: [CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?

> On 03/28/2011 02:51 PM, Rolf Eike Beer wrote: >> I try to do an INSTALL(EXPORT) to allow others to link against one of my >> libraries. That libraries is linked against some other internal >> libraries >> the target's don't need to link to as everything in them is purely >> internal. >> >> I trie

Re: [CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?

On 03/28/2011 02:51 PM, Rolf Eike Beer wrote: > I try to do an INSTALL(EXPORT) to allow others to link against one of my > libraries. That libraries is linked against some other internal libraries > the target's don't need to link to as everything in them is purely > internal. > > I tried somethin