Re: [CMake] CXX flags applied to C source
Glad to hear.
I don't think that add_definitions() understands -U, so it won't
translate it for you, but pass it verbatim to the compiler. This means,
that -DFOO will become /DFOO for MSVC, you'll have to do the same
transformation yourself for -U. Nevertheless, personally I would choose
add_definitions(), as it IMHO is more semantically correct. The effect
is pretty much the same.
However, -U won't be able to undefine a #define'd symbol.
I was just asking about __x86__ and __linux__ because they are usually
defined by your compiler.
Michael
On 07/25/2011 11:19 PM, Kelly Burkhart wrote:
> Thanks, that seems to work. I'm getting around to testing the windows
> version of this, we have a command line arg: "-UUNICODE" which
> explicitly removes a manifest constant. I assume that should be in a
> set(...) rather than an add_definitions(...) correct?
>
> The defines for __x86__ and __linux__ are required for the omnithread
> library which we use, and the gcc -W option is the old name for
> -Wextra.
>
> Thanks,
>
> -Kelly
>
> On Mon, Jul 25, 2011 at 8:40 AM, Michael Wild wrote:
>> On 07/25/2011 03:20 PM, Kelly Burkhart wrote:
>>> Hi, I have a bunch of compiler flags specified with add_definitions as so:
>>>
>>> if(LINUX)
>>> tb_compiler_version(TB_GCC_VERSION)
>>> add_definitions(${CMAKE_CXX_FLAGS} "-g")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-DBOOST_SIGNALS_NAMESPACE=tb_signals")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-D__x86__")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-D__linux__")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-D__OSVERSION__=2")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-D_REENTRANT")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-Wall")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-unused")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-comment")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-sign-compare")
>>>
>>> if("${TB_GCC_VERSION}" VERSION_GREATER "4.2")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-fno-strict-aliasing")
>>> endif()
>>>
>>> if("${TB_GCC_VERSION}" VERSION_GREATER "4.3")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-ignored-qualifiers")
>>> add_definitions(${CMAKE_CXX_FLAGS} "-Wnon-virtual-dtor")
>>> endif()
>>>
>>> add_definitions(${CMAKE_CXX_FLAGS} "-W")
>>> else()
>>> ...
>>>
>>> The CXX flags are applied to C compiles which is mostly what I want,
>>> but there are some options (-Wnon-virtual-dtor for instance) that only
>>> apply to C++. How can I specifiy an option should only be applied to
>>> C++ but not to C?
>>>
>>> Thanks,
>>>
>>> -Kelly
>>
>> For one, your are completely misusing add_definitions(). You should only
>> use it for -D flags, nothing else, and only if the definitions apply to
>> *all* files in that directory. If
>>
>> 1) the definitions should only be applied to some source files or some
>> targets, use the COMPILE_DEFINITIONS source/target property. See the
>> set_source_files_properties() and the set_target_properties() commands.
>>
>> 2) you want to set other compile flags, either append to the
>> CMAKE_CXX_FLAGS *variable* using the set() command, e.g.
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall") if you want this flag to
>> be applied to everything that follows (including sub-directories), or
>> use the COMPILE_FLAGS source file or target property (see point 1).
>>
>>
>> Also, it doesn't make sense to pass the CMAKE_CXX_FLAGS variable to
>> add_definitions(). Lastly, you can pass definitions using a single call,
>> e.g. add_definitions(-DFOO -DBAR -DBAZ).
>>
>> So, your code might look something like the following:
>>
>> if(LINUX)
>> tb_compiler_version(TB_GCC_VERSION)
>> # TB_C_FLAGS will be also used for C++
>> set(TB_C_FLAGS "-g -Wall -Wno-unused")
>> set(TB_C_FLAGS "${TB_C_FLAGS} -Wno-comment -Wno-sign-compare")
>> add_definitions(
>>-DBOOST_SIGNALS_NAMESPACE=tb_signals# Doesn't hurt in C files
>>-D__x86__ # ARE YOU SURE?!
>>-D__linux__ # ARE YOU SURE?!
>>-D__OSVERSION__=2
>>-D_REENTRANT
>>)
>>
>> if("${TB_GCC_VERSION}" VERSION_GREATER "4.2")
>>set(TB_C_FLAGS "${TB_C_FLAGS} -fno-strict-aliasing")
>> endif()
>>
>> if("${TB_GCC_VERSION}" VERSION_GREATER "4.3")
>>set(TB_C_FLAGS "${TB_C_FLAGS} -Wno-ignored-qualifiers")
>>set(TB_CXX_FLAGS "${TB_CXX_FLAGS} -Wnon-virtual-dtor")
>> endif()
>>
>> # What's this?
>> # add_definitions(${CMAKE_CXX_FLAGS} "-W")
>>
>> # now, assign TB__FLAGS to CMAKE__FLAGS
>> set(CMAKE_C_FLAGS "${TB_C_FLAGS}")
>> set(CMAKE_CXX_FLAGS "${TB_C_FLAGS} ${TB_CXX_FLAGS}")
>> else()
>> ___
>> 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] [ryppl-dev] Re: $<> expressions in include_directories command
On 07/25/2011 02:17 PM, Daniel Pfeifer wrote: > Does it also handle circular dependencies? Since we were doing the module breakdown ourselves we could define modules to avoid circular dependencies. We separated implementation dependencies from test dependencies so that library and test modules could be built separately. That helped break many circular dependencies. So you want to have modules A -> B -> C -> A each build using all three include directories? This is still possible to do in pure CMake code by loading a dependency declaration file from all modules ahead of time as was previously done to get the inputs to the topo sort. -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] [ryppl-dev] Re: $<> expressions in include_directories command
On 07/25/2011 03:11 PM, Dave Abrahams wrote: >> Yes, CMake does support response file generation in a few cases. >> It uses them to pass long object file lists to linkers. Since >> CMake 2.8.5 it also uses them for include directory lists with >> GNU tools on Windows. > > That makes it sound like it's not going to help us with long include > directory lists with non-GNU tools. Is that right? When generating VS IDE project files we put the include dir list in their project format and the IDE generates the command line. There is no way to tell the IDE to use response files. It might or might not do so under the hood. However, with ITK we have not hit any limit of the IDE yet, but we did have to add the CMake 2.8.5 feature to support MinGW tools. -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
[CMake] Xcode and Cmake ReRun
Hi guys, I noticed that each XCode target has an associated CMake ReRun script phase. Is there a specific reason for this (in difference to having one target that all others depend on that does the ReRun check?) It causes a fair few issues, it fails when you are parallelcompiling targets (It'll start copies of cmake at the same time), secondly it adds quite some time to the build if you have many targets /Johan ___ 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] CXX flags applied to C source
Thanks, that seems to work. I'm getting around to testing the windows
version of this, we have a command line arg: "-UUNICODE" which
explicitly removes a manifest constant. I assume that should be in a
set(...) rather than an add_definitions(...) correct?
The defines for __x86__ and __linux__ are required for the omnithread
library which we use, and the gcc -W option is the old name for
-Wextra.
Thanks,
-Kelly
On Mon, Jul 25, 2011 at 8:40 AM, Michael Wild wrote:
> On 07/25/2011 03:20 PM, Kelly Burkhart wrote:
>> Hi, I have a bunch of compiler flags specified with add_definitions as so:
>>
>> if(LINUX)
>> tb_compiler_version(TB_GCC_VERSION)
>> add_definitions(${CMAKE_CXX_FLAGS} "-g")
>> add_definitions(${CMAKE_CXX_FLAGS} "-DBOOST_SIGNALS_NAMESPACE=tb_signals")
>> add_definitions(${CMAKE_CXX_FLAGS} "-D__x86__")
>> add_definitions(${CMAKE_CXX_FLAGS} "-D__linux__")
>> add_definitions(${CMAKE_CXX_FLAGS} "-D__OSVERSION__=2")
>> add_definitions(${CMAKE_CXX_FLAGS} "-D_REENTRANT")
>> add_definitions(${CMAKE_CXX_FLAGS} "-Wall")
>> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-unused")
>> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-comment")
>> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-sign-compare")
>>
>> if("${TB_GCC_VERSION}" VERSION_GREATER "4.2")
>> add_definitions(${CMAKE_CXX_FLAGS} "-fno-strict-aliasing")
>> endif()
>>
>> if("${TB_GCC_VERSION}" VERSION_GREATER "4.3")
>> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-ignored-qualifiers")
>> add_definitions(${CMAKE_CXX_FLAGS} "-Wnon-virtual-dtor")
>> endif()
>>
>> add_definitions(${CMAKE_CXX_FLAGS} "-W")
>> else()
>> ...
>>
>> The CXX flags are applied to C compiles which is mostly what I want,
>> but there are some options (-Wnon-virtual-dtor for instance) that only
>> apply to C++. How can I specifiy an option should only be applied to
>> C++ but not to C?
>>
>> Thanks,
>>
>> -Kelly
>
> For one, your are completely misusing add_definitions(). You should only
> use it for -D flags, nothing else, and only if the definitions apply to
> *all* files in that directory. If
>
> 1) the definitions should only be applied to some source files or some
> targets, use the COMPILE_DEFINITIONS source/target property. See the
> set_source_files_properties() and the set_target_properties() commands.
>
> 2) you want to set other compile flags, either append to the
> CMAKE_CXX_FLAGS *variable* using the set() command, e.g.
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall") if you want this flag to
> be applied to everything that follows (including sub-directories), or
> use the COMPILE_FLAGS source file or target property (see point 1).
>
>
> Also, it doesn't make sense to pass the CMAKE_CXX_FLAGS variable to
> add_definitions(). Lastly, you can pass definitions using a single call,
> e.g. add_definitions(-DFOO -DBAR -DBAZ).
>
> So, your code might look something like the following:
>
> if(LINUX)
> tb_compiler_version(TB_GCC_VERSION)
> # TB_C_FLAGS will be also used for C++
> set(TB_C_FLAGS "-g -Wall -Wno-unused")
> set(TB_C_FLAGS "${TB_C_FLAGS} -Wno-comment -Wno-sign-compare")
> add_definitions(
> -DBOOST_SIGNALS_NAMESPACE=tb_signals # Doesn't hurt in C files
> -D__x86__ # ARE YOU SURE?!
> -D__linux__ # ARE YOU SURE?!
> -D__OSVERSION__=2
> -D_REENTRANT
> )
>
> if("${TB_GCC_VERSION}" VERSION_GREATER "4.2")
> set(TB_C_FLAGS "${TB_C_FLAGS} -fno-strict-aliasing")
> endif()
>
> if("${TB_GCC_VERSION}" VERSION_GREATER "4.3")
> set(TB_C_FLAGS "${TB_C_FLAGS} -Wno-ignored-qualifiers")
> set(TB_CXX_FLAGS "${TB_CXX_FLAGS} -Wnon-virtual-dtor")
> endif()
>
> # What's this?
> # add_definitions(${CMAKE_CXX_FLAGS} "-W")
>
> # now, assign TB__FLAGS to CMAKE__FLAGS
> set(CMAKE_C_FLAGS "${TB_C_FLAGS}")
> set(CMAKE_CXX_FLAGS "${TB_C_FLAGS} ${TB_CXX_FLAGS}")
> else()
> ___
> 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] FindQt4 errors out when locating QtUITools under CMake 2.8.5
Clinton Stimpson wrote: > > Thanks for finding. Its been fixed in git. > > 702538e Qt4: Fix reference of undefined variable when detecting frameworks > on > Mac OS X > I can confirm that that patch fixes the problem. Thanks a bunch! -Charlie -- View this message in context: http://cmake.3232098.n2.nabble.com/FindQt4-errors-out-when-locating-QtUITools-under-CMake-2-8-5-tp6619091p6619700.html Sent from the CMake mailing list archive at Nabble.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
Re: [CMake] FindQt4 errors out when locating QtUITools under CMake 2.8.5
On Monday, July 25, 2011 10:55:58 am Charlie Sharpsteen wrote: > I ran into an issue after upgrading from CMake 2.8.4 to 2.8.5---the > following no longer works: > > FIND_PACKAGE(Qt4 COMPONENTS QtUiTools REQUIRED) > > I traced the problem down to a hunk in commit > e7f05d9759ec5bc393760daee91bb7223f6c56d0: > > diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake > index 108012a..86fce9d 100644 > --- a/Modules/FindQt4.cmake > +++ b/Modules/FindQt4.cmake > @@ -608,18 +608,6 @@ IF (QT_QMAKE_EXECUTABLE AND QTVERSION) > > If I `patch -R` this hunk before building and installing CMake 2.8.5 then > FIND_PACKAGE can successfully locate QtUiTools. > > More details on GitHub: > > https://github.com/Kitware/CMake/issues/7 > Thanks for finding. Its been fixed in git. 702538e Qt4: Fix reference of undefined variable when detecting frameworks on Mac OS X -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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
Re: [CMake] [ryppl-dev] Re: $<> expressions in include_directories command
2011/7/25 Brad King : > On 07/25/2011 12:00 PM, Daniel Pfeifer wrote: >> what is your opinion on the $<> syntax I originally proposed? >> This would not require creating virtual targets for header only libraries. > > The proposed solution is to use delayed evaluation to work around > lack of dependency-sorted ordering. The topological sort already > used by the Boost CMake solves this problem in a better way. The topological sort function is not used anymore in Boost.CMake. Since we have circular dependencies, there is no chance in sorting the modules in dependency-sorted order. > The > ITK project already does CMake-time module dependency detection > and sorting using a similar approach. It correctly handles the > generation of include directories for each module. It also handles > header-only modules. Does it also handle circular dependencies? cheers, Daniel ___ 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] [ryppl-dev] Re: $<> expressions in include_directories command
2011/7/25 Jean-Christophe Fillion-Robin : > Relaying on small executable named DGraph built at configure time, we manage > to obtain the topological order of CTK plugins, apps and libraries. The tool > also check for cycle and output a human readable message if there are any > cycle. That sounds like circular dependencies are treated as errors? The header only libraries of Boost have many circular dependencies. There is no topological order. I decided to implement delayed variable evaluation, because dependency-sorted ordering is simply not possible. cheers, Daniel ___ 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] [ryppl-dev] Re: $<> expressions in include_directories command
We used also a similar approach in CTK. See http://www.commontk.org/index.php/Documentation/BuildSystem_Descriptionand also [1] and [2] Relaying on small executable named DGraph built at configure time, we manage to obtain the topological order of CTK plugins, apps and libraries. The tool also check for cycle and output a human readable message if there are any cycle. Note also that each library, plugins and app has access to only the include directories it should. If I remember properly, Sasha from the German Cancer Research Center (DKFZ)did some work factorizing out the CMake code so that it could easily be re-used. Sasha> Could you comment ? Thanks Jc [1] http://www.commontk.org/docs/html/group__CMakeAPI.html [2] http://www.commontk.org/docs/html/group__CMakeUtilities.html On Mon, Jul 25, 2011 at 1:16 PM, Brad King wrote: > On 07/25/2011 12:00 PM, Daniel Pfeifer wrote: > > what is your opinion on the $<> syntax I originally proposed? > > This would not require creating virtual targets for header only > libraries. > > The implementation is just doing delayed variable evaluation and > is not a true generator expression in the same sense as is used > by add_test and add_custom_command. The latter support only > generator-defined specific expressions with very specific syntax > that can be validated. The FinalPass of commands is an ancient > implementation detail which exists only in a few commands for > historical reasons and should not be used in new commands. > > The proposed solution is to use delayed evaluation to work around > lack of dependency-sorted ordering. The topological sort already > used by the Boost CMake solves this problem in a better way. The > ITK project already does CMake-time module dependency detection > and sorting using a similar approach. It correctly handles the > generation of include directories for each module. It also handles > header-only modules. Unfortunately the implementation is embedded > in ITK's CMake code and is not (yet) easily generalizable. > > -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 > -- +1 919 869 8849 ___ 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] Invalid library output directory when VC++ solution is generated
On 2011-07-25 07:59-0700 Alan W. Irwin wrote: One possibility is you are setting CMAKE_LIBRARY_OUTPUT_DIRECTORY after your dll's are built. That was sloppy language. What I meant was after your dll targets are configured by CMake. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] [ryppl-dev] Re: $<> expressions in include_directories command
On 07/25/2011 12:00 PM, Daniel Pfeifer wrote: > what is your opinion on the $<> syntax I originally proposed? > This would not require creating virtual targets for header only libraries. The implementation is just doing delayed variable evaluation and is not a true generator expression in the same sense as is used by add_test and add_custom_command. The latter support only generator-defined specific expressions with very specific syntax that can be validated. The FinalPass of commands is an ancient implementation detail which exists only in a few commands for historical reasons and should not be used in new commands. The proposed solution is to use delayed evaluation to work around lack of dependency-sorted ordering. The topological sort already used by the Boost CMake solves this problem in a better way. The ITK project already does CMake-time module dependency detection and sorting using a similar approach. It correctly handles the generation of include directories for each module. It also handles header-only modules. Unfortunately the implementation is embedded in ITK's CMake code and is not (yet) easily generalizable. -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
[CMake] FindQt4 errors out when locating QtUITools under CMake 2.8.5
I ran into an issue after upgrading from CMake 2.8.4 to 2.8.5---the following no longer works: FIND_PACKAGE(Qt4 COMPONENTS QtUiTools REQUIRED) I traced the problem down to a hunk in commit e7f05d9759ec5bc393760daee91bb7223f6c56d0: diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake index 108012a..86fce9d 100644 --- a/Modules/FindQt4.cmake +++ b/Modules/FindQt4.cmake @@ -608,18 +608,6 @@ IF (QT_QMAKE_EXECUTABLE AND QTVERSION) If I `patch -R` this hunk before building and installing CMake 2.8.5 then FIND_PACKAGE can successfully locate QtUiTools. More details on GitHub: https://github.com/Kitware/CMake/issues/7 -Charlie -- View this message in context: http://cmake.3232098.n2.nabble.com/FindQt4-errors-out-when-locating-QtUITools-under-CMake-2-8-5-tp6619091p6619091.html Sent from the CMake mailing list archive at Nabble.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
Re: [CMake] [ryppl-dev] Re: $<> expressions in include_directories command
2011/7/25 Brad King
>
> On 07/13/2011 12:10 PM, Alexander Neundorf wrote:
> > When I talked last time with Brad such a feature was still on his TODO, and
> > is
> > there since at least 2007 already, but still more or less at the bottom of
> > the
> > list.
>
> It's more of a "wish I had time to do this" ;)
Brad,
what is your opinion on the $<> syntax I originally proposed?
This would not require creating virtual targets for header only libraries.
Furthermore, it is already implemented, including tests.
> include_directories($)
> set(GENERATOR_EXPRESSION $ $)
> if(USE_FULLPATH)
> set(GEN_EXP_1 "${CMAKE_BINARY_DIR}/GenExp1")
> set(GEN_EXP_2 "${CMAKE_BINARY_DIR}/GenExp2" CACHE STRING "" FORCE)
> else()
> set(GEN_EXP_1 GenExp1)
> set(GEN_EXP_2 GenExp2 CACHE STRING "" FORCE)
> endif()
>
> # cyclic dependency must not result in endless loop
> set(GEN_EXP_1 ${GEN_EXP_1} $)
> set(GEN_EXP_2 ${GEN_EXP_2} $ CACHE STRING "" FORCE)
See:
https://github.com/purpleKarrot/CMake/blob/4b75b82a7a07e41024c1534163d4f39b45e6402a/Tests/IncludeDirectories/CMakeLists.txt
cheers, Daniel
___
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] $<> expressions in include_directories command
On 07/13/2011 12:10 PM, Alexander Neundorf wrote:
> When I talked last time with Brad such a feature was still on his TODO, and
> is
> there since at least 2007 already, but still more or less at the bottom of
> the
> list.
It's more of a "wish I had time to do this" ;)
> add_library(foo ${fooSrcs})
> set_target_properties(foo PROPERTIES INCLUDE_DIRS ${...whereever})
>
> This should then also work when exporting/importing targets and with
> different
> configurations.
Yes. This is effectively a "usage requirements" feature.
> You are right that target_link_libraries() could take care of the rest (Brad
> suggested this too), but I wouldn't like that, since it would be a change in
> behaviour and very unobvious.
It's not a change in behavior because currently no projects set any such
properties on their targets since CMake doesn't define any. Perhaps it
is not obvious because we're trying to give target_link_libraries a
meaning beyond just linking. However, it is already a nice place that
lists the dependencies of a target so it is tempting to use it.
> If a user who doesn't know the "new" behaviour of target_link_libraries()
> would see the new code, he would have no chance to find out where the include
> dirs are coming from:
>
>add_executable(hello ${srcs})
>target_link_libraries(hello ${FOO_LIBRARIES})
>
> Actually this would even be a somewhat source incompatible change, since it
> would mean that the same cmake code would suddenly create a different set of
> include dirs.
It is not incompatible because the change is only after updating to a newer
version of FOO which sets the usage requirement properties. The newer
FOO would have to require a sufficiently new version of CMake to support
the feature. No old build would be affected.
>target_use_libraries(hello USE_INCLUDE_DIRS ${FOO_LIBRARIES})
> or
>target_use_bundle(hello USE_INCLUDE_DIRS ${FOO_LIBRARIES})
I'm not opposed to introducing a new command for this. However, I think
USE_INCLUDE_DIRS is too verbose. The command is stating that it wants to
do everything needed to use FOO. Instead we should bring in everything
by default but allow a NO_INCLUDE_DIRS option to drop certain requirements
in obscure cases.
-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] [ryppl-dev] Re: $<> expressions in include_directories command
On 07/25/2011 07:56 AM, Dave Abrahams wrote: > > on Mon Jul 25 2011, Daniel Pfeifer wrote: > >> Hey, >> >> is there an update on this topic? > > Well, I asked > > "Does cmake use response files when generating command-lines for windows > compilers that support them?" > > to which there was no reply. Sorry, I've been traveling for 3 weeks. Yes, CMake does support response file generation in a few cases. It uses them to pass long object file lists to linkers. Since CMake 2.8.5 it also uses them for include directory lists with GNU tools on Windows. -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] Invalid library output directory when VC++ solution is generated
On 2011-07-25 12:19+0100 Laura Autón García wrote:
Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:
SET(LIB_DIR "${PROJECT_SOURCE_DIR}/lib")
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH "Directory
for libraries")
One possibility is you are setting CMAKE_LIBRARY_OUTPUT_DIRECTORY
after your dll's are built.
Just in case that is not the source of the problem, here is
some further discussion.
I cannot spot anything wrong with your command above. However, our
project (PLplot) hasn't tried that recommended variable yet. Instead
we use the deprecated LIBRARY_OUTPUT_PATH variable (mentioned in the
documentation) like the following (because we are a cross-platform
project):
# in windows all created dlls are gathered in the dll directory
# if you add this directory to your PATH all shared libraries are
available
if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
This works on Windows according to others, and I have also
personally verified that it works under Wine.
Although a different variable is used, note the differences with
how that variable is set with your case.
(1) The subdirectory is in the build tree rather than the source
tree.
(2) We don't cache the variable.
I don't think any of these differences should matter in terms of
whether the functionality works or not, but you might want to try them
with CMAKE_LIBRARY_OUTPUT_DIRECTORY just in case that might be the
source of your difficulty. You could also set LIBRARY_OUTPUT_PATH
like we do as a test, but it would be better to figure out how to get
CMAKE_LIBRARY_OUTPUT_DIRECTORY to work correctly since our approach is
deprecated. (It wasn't deprecated when we started using CMake years
ago, and we plan to switch over to the recommended method at some point.)
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
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] list subdirectories from a given folder
file(GLOB sub-dirs-of-dir-name ${dir-name}/*)
should return only files within "${dir-name}" regardless of the
current working directory.
HTH,
David
On Mon, Jul 25, 2011 at 7:50 AM, Julien Dardenne
wrote:
>
> Hi,
>
> is it possible to list the subdirectories from a given folder?
> I use this function but it returns me the file in the current path.
>
> macro(list_subdirectories retval curdir return_relative)
>
>file(GLOB sub-dir RELATIVE ${curdir} *)
>set(list_of_dirs "")
>foreach(dir ${sub-dir})
> if(IS_DIRECTORY ${curdir}/${dir})
>if (${return_relative})
> set(list_of_dirs ${list_of_dirs} ${dir})
>else()
> set(list_of_dirs ${list_of_dirs} ${curdir}/${dir})
>endif()
> endif()
>endforeach()
>set(${retval} ${list_of_dirs})
> endmacro()
>
> I can notuse the FILE() with a different path than the current path.
>
> Thank you for your help
>
> --
> ___
> 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] ADD_CUSTOM_COMMAND and Dependencies
On 07/25/2011 03:24 PM, Micha Renner wrote: > There is following sequence: > > ADD_EXECUTEABLE(generator gen.c) > > ADD_CUSTOM_COMMAND(OUTPUT tlib.h > COMMAND generator > tlib.h) > > ADD_LIBRARY(tlib tlib.c tlib.h) > > The question: Is it sure that ADD_EXECUTEABLE is invoked before the > library is build or is here an ADD_DEPENDENCIES(tlib generator) > necessary? > > Greetings > > Micha > Yes, CMake should recognize that "generator" is a target and create the dependency of tlib.h on "generator" automagically. And since it knows that tlib.h is GENERATED, it will also add a dependency of tlib on tlib.h. If you want to make really sure that CMake understands that "generator" is a target, use generator expressions, like "$", but that works only since 2.8.4. HTH 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
[CMake] ADD_CUSTOM_COMMAND and Dependencies
There is following sequence: ADD_EXECUTEABLE(generator gen.c) ADD_CUSTOM_COMMAND(OUTPUT tlib.h COMMAND generator > tlib.h) ADD_LIBRARY(tlib tlib.c tlib.h) The question: Is it sure that ADD_EXECUTEABLE is invoked before the library is build or is here an ADD_DEPENDENCIES(tlib generator) necessary? Greetings Micha ___ 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] CXX flags applied to C source
On 07/25/2011 03:20 PM, Kelly Burkhart wrote:
> Hi, I have a bunch of compiler flags specified with add_definitions as so:
>
> if(LINUX)
> tb_compiler_version(TB_GCC_VERSION)
> add_definitions(${CMAKE_CXX_FLAGS} "-g")
> add_definitions(${CMAKE_CXX_FLAGS} "-DBOOST_SIGNALS_NAMESPACE=tb_signals")
> add_definitions(${CMAKE_CXX_FLAGS} "-D__x86__")
> add_definitions(${CMAKE_CXX_FLAGS} "-D__linux__")
> add_definitions(${CMAKE_CXX_FLAGS} "-D__OSVERSION__=2")
> add_definitions(${CMAKE_CXX_FLAGS} "-D_REENTRANT")
> add_definitions(${CMAKE_CXX_FLAGS} "-Wall")
> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-unused")
> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-comment")
> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-sign-compare")
>
> if("${TB_GCC_VERSION}" VERSION_GREATER "4.2")
> add_definitions(${CMAKE_CXX_FLAGS} "-fno-strict-aliasing")
> endif()
>
> if("${TB_GCC_VERSION}" VERSION_GREATER "4.3")
> add_definitions(${CMAKE_CXX_FLAGS} "-Wno-ignored-qualifiers")
> add_definitions(${CMAKE_CXX_FLAGS} "-Wnon-virtual-dtor")
> endif()
>
> add_definitions(${CMAKE_CXX_FLAGS} "-W")
> else()
> ...
>
> The CXX flags are applied to C compiles which is mostly what I want,
> but there are some options (-Wnon-virtual-dtor for instance) that only
> apply to C++. How can I specifiy an option should only be applied to
> C++ but not to C?
>
> Thanks,
>
> -Kelly
For one, your are completely misusing add_definitions(). You should only
use it for -D flags, nothing else, and only if the definitions apply to
*all* files in that directory. If
1) the definitions should only be applied to some source files or some
targets, use the COMPILE_DEFINITIONS source/target property. See the
set_source_files_properties() and the set_target_properties() commands.
2) you want to set other compile flags, either append to the
CMAKE_CXX_FLAGS *variable* using the set() command, e.g.
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall") if you want this flag to
be applied to everything that follows (including sub-directories), or
use the COMPILE_FLAGS source file or target property (see point 1).
Also, it doesn't make sense to pass the CMAKE_CXX_FLAGS variable to
add_definitions(). Lastly, you can pass definitions using a single call,
e.g. add_definitions(-DFOO -DBAR -DBAZ).
So, your code might look something like the following:
if(LINUX)
tb_compiler_version(TB_GCC_VERSION)
# TB_C_FLAGS will be also used for C++
set(TB_C_FLAGS "-g -Wall -Wno-unused")
set(TB_C_FLAGS "${TB_C_FLAGS} -Wno-comment -Wno-sign-compare")
add_definitions(
-DBOOST_SIGNALS_NAMESPACE=tb_signals# Doesn't hurt in C files
-D__x86__ # ARE YOU SURE?!
-D__linux__ # ARE YOU SURE?!
-D__OSVERSION__=2
-D_REENTRANT
)
if("${TB_GCC_VERSION}" VERSION_GREATER "4.2")
set(TB_C_FLAGS "${TB_C_FLAGS} -fno-strict-aliasing")
endif()
if("${TB_GCC_VERSION}" VERSION_GREATER "4.3")
set(TB_C_FLAGS "${TB_C_FLAGS} -Wno-ignored-qualifiers")
set(TB_CXX_FLAGS "${TB_CXX_FLAGS} -Wnon-virtual-dtor")
endif()
# What's this?
# add_definitions(${CMAKE_CXX_FLAGS} "-W")
# now, assign TB__FLAGS to CMAKE__FLAGS
set(CMAKE_C_FLAGS "${TB_C_FLAGS}")
set(CMAKE_CXX_FLAGS "${TB_C_FLAGS} ${TB_CXX_FLAGS}")
else()
___
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] CXX flags applied to C source
Hi, I have a bunch of compiler flags specified with add_definitions as so:
if(LINUX)
tb_compiler_version(TB_GCC_VERSION)
add_definitions(${CMAKE_CXX_FLAGS} "-g")
add_definitions(${CMAKE_CXX_FLAGS} "-DBOOST_SIGNALS_NAMESPACE=tb_signals")
add_definitions(${CMAKE_CXX_FLAGS} "-D__x86__")
add_definitions(${CMAKE_CXX_FLAGS} "-D__linux__")
add_definitions(${CMAKE_CXX_FLAGS} "-D__OSVERSION__=2")
add_definitions(${CMAKE_CXX_FLAGS} "-D_REENTRANT")
add_definitions(${CMAKE_CXX_FLAGS} "-Wall")
add_definitions(${CMAKE_CXX_FLAGS} "-Wno-unused")
add_definitions(${CMAKE_CXX_FLAGS} "-Wno-comment")
add_definitions(${CMAKE_CXX_FLAGS} "-Wno-sign-compare")
if("${TB_GCC_VERSION}" VERSION_GREATER "4.2")
add_definitions(${CMAKE_CXX_FLAGS} "-fno-strict-aliasing")
endif()
if("${TB_GCC_VERSION}" VERSION_GREATER "4.3")
add_definitions(${CMAKE_CXX_FLAGS} "-Wno-ignored-qualifiers")
add_definitions(${CMAKE_CXX_FLAGS} "-Wnon-virtual-dtor")
endif()
add_definitions(${CMAKE_CXX_FLAGS} "-W")
else()
...
The CXX flags are applied to C compiles which is mostly what I want,
but there are some options (-Wnon-virtual-dtor for instance) that only
apply to C++. How can I specifiy an option should only be applied to
C++ but not to C?
Thanks,
-Kelly
___
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] list subdirectories from a given folder
Hi,
is it possible to list the subdirectories from a given folder?
I use this function but it returns me the file in the current path.
macro(list_subdirectories retval curdir return_relative)
file(GLOB sub-dir RELATIVE ${curdir} *)
set(list_of_dirs "")
foreach(dir ${sub-dir})
if(IS_DIRECTORY ${curdir}/${dir})
if (${return_relative})
set(list_of_dirs ${list_of_dirs} ${dir})
else()
set(list_of_dirs ${list_of_dirs} ${curdir}/${dir})
endif()
endif()
endforeach()
set(${retval} ${list_of_dirs})
endmacro()
I can notuse the FILE() with a different path than the current path.
Thank you for your help
--
___
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] Invalid library output directory when VC++ solution is generated
Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:
SET(LIB_DIR "${PROJECT_SOURCE_DIR}/lib")
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH "Directory
for libraries")
According to the documentation:
CMAKE_LIBRARY_OUTPUT_DIRECTORY: Where to put all the LIBRARY
targets when built.
This variable is used to initialize the LIBRARY_OUTPUT_DIRECTORY
property on all the targets.
See that target property for additional information.
Also, the documentation regarding LIBRARY_OUTPUT_DIRECTORY shows:
LIBRARY_OUTPUT_DIRECTORY: Output directory in which to build
LIBRARY target files.
This property specifies the directory into which library target
files should be built. There are three
kinds of target files that may be built: archive, library, and
runtime. Executables are always treated
as runtime targets. Static libraries are always treated as archive
targets. Module libraries are always
treated as library targets. For non-DLL platforms shared libraries
are treated as library targets. For
DLL platforms the DLL part of a shared library is treated as a
runtime target and the corresponding
import library is treated as an archive target. All Windows-based
systems including Cygwin are
DLL platforms. This property is initialized by the value of the variable
CMAKE_LIBRARY_OUTPUT_DIRECTORY if it is set when a target is created.
However, when the project is generated, the library output directory
is not the one specified, but the one I mentioned above.
If anyone has any idea why this may be happening, it would be appreciated.
The binaries, on the other hand, as generated in their correct directory.
Thank you in advance.
___
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] CTest/CDash reports lots of false errors for Autotools projects
Hi all, I have a dashboard running for a project that consists of several external packages that are built using the GNU Autotools. I get a lot of false errors in my dashboard. Here are some examples: configure: WARNING: cannot find 'swig' program. You should look at http://www.swig.org ../../lib/autoconf/fortran.m4:255: AC_LANG_COMPILER(Fortran 77) is expanded from... /usr/share/aclocal/libtool.m4:4170: _LT_LINKER_SHLIBS is expanded from... Browsing cmCTestBuildHandler.cxx I noticed that the above messages indeed match one of the regexes in cmCTestErrorMatches. ":[ \\t]cannot find" # matches first line "([^ :]+):([0-9]+): ([^ \\t])" # matches second and third line I know I can create exception regexes, but I'm wondering whether the current set of regexes may be overcomplete? Best regards, Marcel Loose. -- Marcel Loose Senior Software Engineer, Computing Group R&D, Astron, the Netherlands ___ 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] [ryppl-dev] Re: $<> expressions in include_directories command
Hey, is there an update on this topic? cheers, Daniel ___ 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
