Re: [CMake] (no subject)
On 06/06/2011 10:32 PM, dfurt...@cox.net wrote:
> Does CMake provide a way to get the list of objects going into a given
> target? I need such a list for a PRE_LINK custom command.
With the Makefile generators, you might use the RULE_LAUNCH_COMPILE
target property combined with a shell script to achieve your goal:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(OBJECTS C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c "void g(void){}\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/h.c "void h(void){}\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c f.c g.c h.c)
SET_TARGET_PROPERTIES(main PROPERTIES
RULE_LAUNCH_COMPILE "sh ${CMAKE_SOURCE_DIR}/objects.sh --")
ADD_CUSTOM_COMMAND(TARGET main PRE_LINK
COMMAND @cat objects.txt COMMENT "Object files of target main:")
# objects.sh:
touch objects.txt
while [ "$1" != "--" ]; do
if ! grep -q "$1" objects.txt; then
echo $1 >> objects.txt
fi
shift
done
shift
exec "$@"
The objects.sh script collects all object files of the main target in
addition to compiling the respective source file, and the PRE_LINK
custom command may retrieve them from the objects.txt file later.
'hope that helps.
Regards,
Michael
PS: Please use a descriptive subject in your postings.
___
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 set a preprocessor define for all build configurations except one ?
On 06/07/2011 07:05 PM, Glenn Coombs wrote:
> I want to have a preprocessor symbol (GEN_OUTFILES) defined for all build
> configurations except one (ReleaseNoOutfiles). Before I added the
> ReleaseNoOutfiles configuration I just had this line in my top level
> CMakeLists.txt:
>
> add_definitions(-DGEN_OUTFILES)
>
> but now I have to have this complicated mess instead:
>
> # Add preprocessor definition for GEN_OUTFILES to all project configurations
> except ReleaseNoOutfiles
> if (CMAKE_CONFIGURATION_TYPES)
> string(TOUPPER "${CMAKE_CONFIGURATION_TYPES}"
> CMAKE_CONFIGURATION_TYPES_UPPER)
> else()
> string(TOUPPER "${CMAKE_BUILD_TYPE}"
> CMAKE_CONFIGURATION_TYPES_UPPER)
> endif()
>
> foreach(config ${CMAKE_CONFIGURATION_TYPES_UPPER})
> if (NOT (${config} MATCHES "RELEASENOOUTFILES"))
> set_property(DIRECTORY APPEND PROPERTY
> COMPILE_DEFINITIONS_${config} GEN_OUTFILES)
> endif()
> endforeach()
>
> Is there a more elegant solution that I am missing ? Ideally something
> like:
>
> add_definitions(CONFIG=Debug;Release;RelWithDebInfo;MinSizeRel
> -DGEN_OUTFILES)
>
> which I know doesn't exist but I really wish it did :-)
AFAIK, there's no other approach to take account of single- and multi-
config generators at the same time for this purpose, but perhaps, you
could design the loop a bit smarter:
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE})
STRING(TOUPPER ${i} j)
IF(NOT j MATCHES "RELEASENOOUTFILES")
SET_PROPERTY(...)
ENDIF()
ENDFOREACH()
Since CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE are mutually
exclusive and an empty list/item doesn't cause an iteration, this
should work as expected.
Alternatively, you might use
SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS GEN_OUTFILES)
SET(CMAKE_C_FLAGS_RELEASENOOUTFILES -UGEN_OUTFILES)
and rely on the assumption that
(1) the FLAGS are mentioned after the COMPILE_DEFINITIONS, and
(2) the last -D/-U argument in the command line will take effect.
At least, GCC guarantees that (2) holds, but I have not found any
explicit assertion in the documentation that CMake guarantees (1),
though it seems to work in this way.
BTW, is an "inverted" logic an option, i.e. a preprocessor definition
NO_GEN_OUTFILES enabled for the RELEASENOOUTFILES configuration only?
This would be much easier and fit that configuration's intent better.
Regards,
Michael
> Initially I didn't have the if (CMAKE_CONFIGURATION_TYPES) check and it
> didn't work on linux. Why is CMAKE_CONFIGURATION_TYPES empty for linux
> targets ? I know that multiple build configs are not supported in the same
> tree like they are under Visual Studio but you can configure multiple build
> directories with CMAKE_BUILD_TYPE set to each value in
> CMAKE_CONFIGURATION_TYPES. The code in CMakeLists.txt files would be more
> platform agnostic and easier to read if one could iterate over
> CMAKE_CONFIGURATION_TYPES on linux to set configuration specific variables
> like COMPILE_DEFINITIONS_XXX.
>
> --
> Glenn
___
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] Release of new Debian Source Package Generator
Hi, Why is this not part of CMake? Creating source .deb packages is much, much more interesting that creating binary packages. On Fri, Apr 22, 2011 at 8:16 PM, Rosen Diankov wrote: > Hi all, > > There was a problem with the previous script on certain versions of > tar. I'm attaching a new file that fixes it. > > rosen, > > 2011/4/22 Rosen Diankov : >> Hi all, >> >> We just finished a new debian source package generator script for cmake: >> >> https://openrave.svn.sourceforge.net/svnroot/openrave/trunk/modules-cmake/DebSourcePPA.cmake >> >> This is based on the initial UploadPPA.cmake file ( >> http://purplekarrot.net/blog/dputCMake.html ) by Daniel Pfeifer, >> except it adds 3 new cool features: >> >> 1. Simultaneous output of multiple debian source packages for each >> distribution. Users can specify them by >> >> set(CPACK_DEBIAN_DISTRIBUTION_RELEASES karmic lucid maverick natty) >> >> and 4 dsc files, 4 changes files, 4 debian.tar.gz files, and one >> src.orig.tar.gz file will be outputted. These can be sent directly to >> launchpad via dput >> >> 2. Automatically generates symbols and run-time dependencies from the >> build dependencies >> >> 3 Custom copy of source directory via CPACK_DEBIAN_PACKAGE_SOURCE_COPY >> >> there's also a lot of small mods here and there. >> >> The usage of this file for generating all the OpenRAVE packages can be >> seen here: >> >> https://launchpad.net/~openrave/+archive/release/+packages >> >> For ubuntu users, you can execute the following line to see the >> generated packages: >> >> sudo add-apt-repository ppa:openrave/release >> >> rosen, >> > > ___ > 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 > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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 set a preprocessor define for all build configurations except one ?
I don't think CMAKE_BUILD_TYPE is used by the Visual Studio generators so
that would only work for Makefile based build systems. I need a solution
that works for both Visual Studio on Windows and Makefiles on Linux.
On 12 June 2011 21:32, Raphael Kubo da Costa wrote:
> Glenn Coombs
> writes:
>
> > Is there a more elegant solution that I am missing ? Ideally something
> > like:
> >
> > add_definitions(CONFIG=Debug;Release;RelWithDebInfo;MinSizeRel
> > -DGEN_OUTFILES)
> >
> > which I know doesn't exist but I really wish it did :-)
>
> Isn't it OK to just do something like:
>
> if (NOT "${CMAKE_BUILD_TYPE}" STREQUAL "ReleaseNoOutFiles")
>add_definitions(-DGEN_OUTFILES)
> endif ()
>
> ___
> 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] How to set a preprocessor define for all build configurations except one ?
Glenn Coombs
writes:
> Is there a more elegant solution that I am missing ? Ideally something
> like:
>
> add_definitions(CONFIG=Debug;Release;RelWithDebInfo;MinSizeRel
> -DGEN_OUTFILES)
>
> which I know doesn't exist but I really wish it did :-)
Isn't it OK to just do something like:
if (NOT "${CMAKE_BUILD_TYPE}" STREQUAL "ReleaseNoOutFiles")
add_definitions(-DGEN_OUTFILES)
endif ()
___
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] Support for Custom LANG in CMAKE (CUDA and general case)
On Tue, Jun 7, 2011 at 12:50 PM, t m wrote: > Hi > > I've two topics related to the support for custom lang in cmake. I > hope you can help me. > > 1) Does anyone knows plan about merge the following feature related to > the CUDA: http://public.kitware.com/Bug/view.php?id=11887 > > I'm in the process of integrating the CUDA Toolkit into our build > environment and I would need to make a decision which way to go very > soon. I must say that I like much more idea presented in this ticket > instead of using wrapping macros (aka FindCUDA.cmake).I think it's > more elegant and I hope it will be merge to the main stream very soon. > I just need to know which direction will be choose as I don't wont to > be far from the main stream. > > Other than the 'more elegant' prospect of being able to just put .cu files into a target, is there anything else deficient about the current FindCUDA macros? All you have to do really is to use cuda_add_executable instead of add_executable. I've iterated with Peter many times about his proposed changes, and one of the issues we were hoping to solve is the ability to target different output formats. CUDA supports generation of not only object files, but PTX and CUBIN files which need to not be treated as an object file. In addition, it wasn't clear how this adaptation would behave along side the existing FindCUDA behavior for which we have to be backward compatible with. James ___ 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] Managed C++/CLI, default build flags and configurations
On 06/07/2011 07:29 PM, David Hunter wrote:
> Hi,
>
> I have a number of projects which contain mostly sub-directories with
> standard C++. I currently build all this stuff on Linux and Windows
> and everything is great. However I have a couple of directories in
> these projects which contain managed C++/CLI code so that I can expose
> the unmanaged C++ functionality to the rest of the Microsoft universe,
> obviously these directories build only on Windows. Currently I include
> the following snippet of CMake code, which I found on another post, to
> "fix" the compiler flags to enable the managed build
>
> # Managed C++ set up
>
> set_target_properties(${TargetName} PROPERTIES COMPILE_FLAGS "/clr")
>
> if(CMAKE_CXX_FLAGS_DEBUG MATCHES "/RTC1")
>string(REPLACE "/RTC1" " " CMAKE_CXX_FLAGS_DEBUG
> "${CMAKE_CXX_FLAGS_DEBUG}")
> endif()
>
> if(CMAKE_CXX_FLAGS MATCHES "/EHsc")
>string(REPLACE "/EHsc" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
> endif()
>
> My question is whether there is a better way to do this as the above
> seems a bit brittle and manual. For instance is it possible to define
> a new build configuration and somehow signal in the CMake input file
> that this directory should use it. In general what I want to be able
> to do is to indicate that a different set of default compile flags
> should be used for a given directory rather than the default.
>
> I am happy to spend time working on this and sharing any results but
> would appreciate any pointers from the CMake experts before I start so
> I don't go off wasting my time.
>
> David
Due to the various origins of compile flags,
- directory/target/source properties (configuration-specific)
- CMake variables (configuration-specific)
- environment variables like CC or CXX
it's notoriously difficult to manage them thoroughly. IMO, tweaking the
flags as in your above-noted example is the best you can do in your use
case if only a few directories are concerned. Alternatively, you might
provide two different sets of flags, e.g. MANAGED_CXX_FLAGS[_]
and UNMANAGED_CXX_FLAGS[_], and enable only one of these sets
in every directory while taking account of the variables' propagation
to subdirectories; of course, the affected flags must be removed from
the general CMAKE_CXX_FLAGS[_] variables. As a last resort,
with a Makefile generator, you could use the RULE_LAUNCH_COMPILE
directory property to perform really last-minute modifications
of the compiler's command lines in the concerned directories.
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
