Re: [CMake] CPack and fixup_bundle
It's a little obtuse but you need to use \${CMAKE_INSTALL_PREFIX} in that
first argument to fixup_bundle(). If you don't, ${CMAKE_INSTALL_PREFIX} will
be evaluated at CMake-time and therefore point to your build-time install
directory. You want to delay evaluation of that variable until CPack time,
when it will evaluate to the install directory that CPack uses.
If it makes you feel any better, it took me and another developer quite a
while to figure this out in our own project :).
Take a look at the ${CMAKE_BINARY_DIR}/cmake_install.cmake generated for
your project to see what I mean.
hth,
tyler
On Thu, Mar 17, 2011 at 2:14 PM, Simon Drouin wrote:
> I'm trying to use CPack to create a .tar.gz package on linux. I use
> fixup_bundle from the bundle utility to copy and fix Qt libraries to the
> bundle.
>
> When I use simple 'make install', everything is installed properly in
> directory specified by CMAKE_INSTALL_PREFIX. When I use CPack, the Qt
> libraries are still copied to the CMAKE_INSTALL_PREFIX directory and not the
> package's directory. Here's the code:
>
> # install executable(s)
>
> install( TARGETS ${exec_name} DESTINATION . )
>
>
> # fixup the bundle
>
> set( APPS ${CMAKE_INSTALL_PREFIX}/${exec_name} )
>
> list( APPEND libSearchDirs ${QT_LIBRARY_DIR})
>
> set( additionalLib ${qtsvgiconplugin} )
>
> INSTALL(CODE "include(BundleUtilities)
>
> fixup_bundle(\"${APPS}\" \"${additionalLib}\" \"${libSearchDirs}\")"
> COMPONENT Runtime)
>
>
> #
>
> # Packaging
>
> #
>
> set( CPACK_PACKAGE_DESCRIPTION_SUMMARY "My test package")
>
> set( CPACK_PACKAGE_NAME ${exec_name} )
>
> set( CPACK_PACKAGE_CONTACT "John Smith")
>
> set( CPACK_PACKAGE_VENDOR "Company inc.")
>
> set( CPACK_PACKAGE_VERSION_MAJOR ${PROG_MAJOR_VERSION})
>
> set( CPACK_PACKAGE_VERSION_MINOR ${PROG_MINOR_VERSION})
>
> set( CPACK_PACKAGE_VERSION_PATCH ${PROG_PATCH_VERSION})
>
> set( CPACK_GENERATOR "TGZ")
>
> set( CPACK_PACKAGE_FILE_NAME
> "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}-${CMAKE_SYSTEM_PROCESSOR}")
>
> include(CPack)
>
>
> Am I missing something?
>
>
> s.
>
>
> ___
> 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] Adding new language.
On 03/15/2011 06:30 PM, arrowdodger wrote: > On Tue, Mar 15, 2011 at 12:20 PM, Michael Wild wrote: > >> Just one warning: AFAIK these rule variables are only used for >> Makefile-based generators, *NOT* for Xcode and VisualStudio and the >> like. I'd prefer the route via add_custom_command/add_custom_target... >> >> Michael >> > > Oh, great, then i should abandon what i've written. So, since adding new > language involves creating rule variables, this too works only with > Makefile's? Yes, probably; I've just tried with Visual Studio 8, and it's actually not impressed by a modified CMAKE_C_COMPILE_OBJECT rule variable. BTW, this should be mentioned in the documentation and the Wiki. Anyway, perhaps, there is another alternative for your concern: If you achieve to sufficiently isolate your project's bytecode-related part - logically w.r.t. target interdependencies and organisationally w.r.t. to the directory structure - you might configure that part as an external project for a Makefile generator explicitly. In this way, you could use a non-Makefile generator for your overall project while the bytecode part is built by Make, so you've CMAKE_C_COMPILE_OBJECT, the RULE_LAUNCH properties etc. available. If the bytecode part comprises more than a few files, possibly with non-trivial relations among one another, this may be more appropriate than trying "by hand" with custom commands and custom 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] FindHDF5.cmake patch
Sure thing, it's attached.
Thanks,
Tim
- Original Message -
From: "Rolf Eike Beer"
To: cmake@cmake.org
Sent: Thursday, March 17, 2011 5:18:44 PM
Subject: Re: [CMake] FindHDF5.cmake patch
Am Donnerstag 17 März 2011, 21:55:11 schrieb Tim Gallagher:
> Hi,
>
> Our project uses HDF5 and Fortran, and while I was looking through the
> comments in the FindHDF5.cmake file, I saw that it doesn't support finding
> the Fortran bindings. So, I modified it to make it work to find the
> Fortran bindings.
>
> Below is the diff output. Let me know if there's a more useful format.
"diff -au" gives much more readable results. The best would probably doing a
git clone of CMake master, making a local commit with proper message of your
changes and then sending in the output of "git format-patch HEAD^.."
Eike
___
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/cmakeFrom cd3fc24b6c5e9b8c0c7831bb0e075d77663d2088 Mon Sep 17 00:00:00 2001
From: Tim Gallagher
Date: Thu, 17 Mar 2011 17:27:27 -0400
Subject: [PATCH] Modified the FindHDF5.cmake file to locate the Fortran bindings for the
library in addition to the C and CXX bindings.
---
Modules/FindHDF5.cmake | 32 +---
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 90849a1..abcab9b 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -9,10 +9,9 @@
# The module will optionally accept the COMPONENTS argument. If no COMPONENTS
# are specified, then the find module will default to finding only the HDF5 C
# library. If one or more COMPONENTS are specified, the module will attempt to
-# find the language bindings for the specified components. Currently, the only
-# valid components are C and CXX. The module does not yet support finding the
-# Fortran bindings. If the COMPONENTS argument is not given, the module will
-# attempt to find only the C bindings.
+# find the language bindings for the specified components. The only valid
+# components are C, CXX, and Fortran. If the COMPONENTS argument is not
+# given, the module will attempt to find only the C bindings.
#
# On UNIX systems, this module will read the variable HDF5_USE_STATIC_LIBRARIES
# to determine whether or not to prefer a static link to a dynamic link for HDF5
@@ -33,12 +32,14 @@
# HDF5_DEFINITIONS - Required compiler definitions for HDF5
# HDF5_C_LIBRARIES - Required libraries for the HDF5 C bindings.
# HDF5_CXX_LIBRARIES - Required libraries for the HDF5 C++ bindings
+# HDF5_Fortran_LIBRARIES - Required libraries for the HDF5 Fortran bindings
# HDF5_LIBRARIES - Required libraries for all requested bindings
# HDF5_FOUND - true if HDF5 was found on the system
# HDF5_LIBRARY_DIRS - the full set of library directories
# HDF5_IS_PARALLEL - Whether or not HDF5 was found with parallel IO support
# HDF5_C_COMPILER_EXECUTABLE - the path to the HDF5 C wrapper compiler
# HDF5_CXX_COMPILER_EXECUTABLE - the path to the HDF5 C++ wrapper compiler
+# HDF5_Fortran_COMPILER_EXECUTABLE - the path to the HDF5 Fortran wrapper compiler
# HDF5_DIFF_EXECUTABLE - the path to the HDF5 dataset comparison tool
#=
@@ -57,12 +58,13 @@
# This module is maintained by Will Dicharry .
include(SelectLibraryConfigurations)
-include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
+include(FindPackageHandleStandardArgs)
# List of the valid HDF5 components
set( HDF5_VALID_COMPONENTS
C
CXX
+Fortran
)
# try to find the HDF5 wrapper compilers
@@ -80,6 +82,13 @@ find_program( HDF5_CXX_COMPILER_EXECUTABLE
DOC "HDF5 C++ Wrapper compiler. Used only to detect HDF5 compile flags." )
mark_as_advanced( HDF5_CXX_COMPILER_EXECUTABLE )
+find_program( HDF5_Fortran_COMPILER_EXECUTABLE
+NAMES h5fc h5pfc
+HINTS ENV HDF5_ROOT
+PATH_SUFFIXES bin Bin
+DOC "HDF5 Fortran Wrapper compiler. Used only to detect HDF5 compile flags." )
+mark_as_advanced( HDF5_Fortran_COMPILER_EXECUTABLE )
+
find_program( HDF5_DIFF_EXECUTABLE
NAMES h5diff
HINTS ENV HDF5_ROOT
@@ -158,6 +167,7 @@ if( HDF5_INCLUDE_DIRS AND HDF5_LIBRARIES )
else()
_HDF5_invoke_compiler( C HDF5_C_COMPILE_LINE HDF5_C_RETURN_VALUE )
_HDF5_invoke_compiler( CXX HDF5_CXX_COMPILE_LINE HDF5_CXX_RETURN_VALUE )
+_HDF5_invoke_compiler( Fortran HDF5_Fortran_COMPILE_LINE HDF5_Fortran_RETURN_VALUE )
if( NOT HDF5_FIND_COMPONENTS )
set( HDF5_LANGUAGE_BINDINGS "C" )
@@ -177,6 +187,7 @@ else()
# seed the initial lists of libraries to find with items we know we need
set( HDF5_C_LIBRARY_NAME
Re: [CMake] FindHDF5.cmake patch
Am Donnerstag 17 März 2011, 21:55:11 schrieb Tim Gallagher: > Hi, > > Our project uses HDF5 and Fortran, and while I was looking through the > comments in the FindHDF5.cmake file, I saw that it doesn't support finding > the Fortran bindings. So, I modified it to make it work to find the > Fortran bindings. > > Below is the diff output. Let me know if there's a more useful format. "diff -au" gives much more readable results. The best would probably doing a git clone of CMake master, making a local commit with proper message of your changes and then sending in the output of "git format-patch HEAD^.." Eike signature.asc Description: This is a digitally signed message part. ___ 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] CPack and fixup_bundle
I'm trying to use CPack to create a .tar.gz package on linux. I use
fixup_bundle from the bundle utility to copy and fix Qt libraries to the
bundle.
When I use simple 'make install', everything is installed properly in
directory specified by CMAKE_INSTALL_PREFIX. When I use CPack, the Qt
libraries are still copied to the CMAKE_INSTALL_PREFIX directory and not the
package's directory. Here's the code:
# install executable(s)
install( TARGETS ${exec_name} DESTINATION . )
# fixup the bundle
set( APPS ${CMAKE_INSTALL_PREFIX}/${exec_name} )
list( APPEND libSearchDirs ${QT_LIBRARY_DIR})
set( additionalLib ${qtsvgiconplugin} )
INSTALL(CODE "include(BundleUtilities)
fixup_bundle(\"${APPS}\" \"${additionalLib}\"
\"${libSearchDirs}\")" COMPONENT Runtime)
#
# Packaging
#
set( CPACK_PACKAGE_DESCRIPTION_SUMMARY "My test package")
set( CPACK_PACKAGE_NAME ${exec_name} )
set( CPACK_PACKAGE_CONTACT "John Smith")
set( CPACK_PACKAGE_VENDOR "Company inc.")
set( CPACK_PACKAGE_VERSION_MAJOR ${PROG_MAJOR_VERSION})
set( CPACK_PACKAGE_VERSION_MINOR ${PROG_MINOR_VERSION})
set( CPACK_PACKAGE_VERSION_PATCH ${PROG_PATCH_VERSION})
set( CPACK_GENERATOR "TGZ")
set( CPACK_PACKAGE_FILE_NAME
"${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}-${CMAKE_SYSTEM_PROCESSOR}")
include(CPack)
Am I missing something?
s.
___
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] FindHDF5.cmake patch
Hi,
Our project uses HDF5 and Fortran, and while I was looking through the comments
in the FindHDF5.cmake file, I saw that it doesn't support finding the Fortran
bindings. So, I modified it to make it work to find the Fortran bindings.
Below is the diff output. Let me know if there's a more useful format. This
works on the RHEL 5 and openSUSE 11.4 distributions I have access to (although,
openSUSE 11.4 messed up the HDF5 build in the repo -- h5fc says the mod file is
in /usr/include when it's really in /usr/lib64/gfortran/modules).
I updated the comments in the file also, and I'm CC'ing the maintainer just in
case he misses it on the list.
Thanks,
Tim
tpgLaptop:/usr/share/cmake/Modules # diff FindHDF5.cmake FindHDF5.cmake_orig
12,14c12,15
< # find the language bindings for the specified components. The only valid
< # components are C, CXX, and Fortran. If the COMPONENTS argument is not
< # given, the module will attempt to find only the C bindings.
---
> # find the language bindings for the specified components. Currently, the
> only
> # valid components are C and CXX. The module does not yet support finding the
> # Fortran bindings. If the COMPONENTS argument is not given, the module will
> # attempt to find only the C bindings.
35d35
< # HDF5_Fortran_LIBRARIES - Required libraries for the HDF5 Fortran bindings
42d41
< # HDF5_Fortran_COMPILER_EXECUTABLE - the path to the HDF5 Fortran wrapper
compiler
67d65
< Fortran
85,91d82
< find_program( HDF5_Fortran_COMPILER_EXECUTABLE
< NAMES h5fc h5pfc
< HINTS ENV HDF5_ROOT
< PATH_SUFFIXES bin Bin
< DOC "HDF5 Fortran Wrapper compiler. Used only to detect HDF5 compile
flags." )
< mark_as_advanced( HDF5_Fortran_COMPILER_EXECUTABLE )
<
170d160
< _HDF5_invoke_compiler( Fortran HDF5_Fortran_COMPILE_LINE
HDF5_Fortran_RETURN_VALUE )
190d179
< set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran
${HDF5_C_LIBRARY_NAMES_INIT} )
212,218c201
< if(${LANGUAGE} STREQUAL "Fortran")
< set(HDF5_INCLUDE_FILENAME hdf5.mod)
< else()
< set(HDF5_INCLUDE_FILENAME hdf5.h)
< endif()
<
< find_path( HDF5_${LANGUAGE}_INCLUDE_DIR ${HDF5_INCLUDE_FILENAME}
---
> find_path( HDF5_${LANGUAGE}_INCLUDE_DIR hdf5.h
340,341c323
< HDF5_CXX_COMPILER_EXECUTABLE
< HDF5_Fortran_COMPILER_EXECUTABLE )
---
> HDF5_CXX_COMPILER_EXECUTABLE )
___
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] Eclipse generator - scanner-discovered include pathsand pre-processor symbols
I am using 2.8.4 (on Fedora Core 13). -Original Message- From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] Sent: Wed 3/16/2011 12:04 PM To: Chatterjee, Shash Cc: cmake@cmake.org Subject: Re: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols On Wednesday 16 March 2011, Chatterjee, Shash wrote: > Hi Alex, > > In my case, I get little yellow icons with a question mark on the editor's > left-hand gutter, with a "unresolved inclusion: ". This happens on > every new import, but also if I make changes to any CMakeLists.txt file > within the project and CMake regenerates the .cproject file. which version of cmake are you actually using ? 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
Re: [CMake] Set Source Property For Specific Target
There is a very old, long-standing open bug (in the "backlog" now)
that outlines many of the issues related to supporting pre-compiled
headers.
http://public.kitware.com/Bug/view.php?id=1260
Doing a "copy and rename" strategy for StdAfx.cpp is a reasonable
work-around until such time as this can be addressed in a general way.
General support for this particular feature does not appear to be on
any short-term horizon as far as I'm aware.
HTH,
David
On Thu, Mar 17, 2011 at 1:53 PM, Kawicki, Ryan H
wrote:
>> > Quick question.
>> >
>> > I am trying to add precompiled headers to a project that
>> has been converted to use Cmake.
>> >
>> > In our library directory, we include all our source and
>> build two targets (one static and one dynamic), but setting
>> multiple source values only affects the source and not the
>> source associated to a particular target. Is there a way to
>> get around this issue or something in the works to correct
>> this, like an optional target command?
>> >
>> > Thanks...
>> >
>> > Code below describing the issue:
>> >
>> > FUNCTION (ADD_MSVC_PRECOMPILED_HEADERS
>> > PrecompiledSource PrecompiledHeader TargetProject)
>> > IF (MSVC)
>> > # define the location of the precompiled header
>> > SET(PrecompiledBinary
>> "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}.pch")
>> > # set the target project to use the precompiled binary
>> > SET_PROPERTY(TARGET ${TargetProject}
>> > APPEND
>> > PROPERTY COMPILE_FLAGS
>> > "/Yu\"${PrecompiledHeader}\"
>> /Fp\"${PrecompiledBinary}\"")
>> > # set the source file to compile out the pch
>> > SET_PROPERTY(SOURCE ${PrecompiledSource}
>> > APPEND
>> > PROPERTY COMPILE_FLAGS
>> > "/Yc\"${PrecompiledHeader}\"
>> /Fp\"${PrecompiledBinary}\"")
>> > ENDIF (MSVC)
>> > ENDFUNCTION (ADD_MSVC_PRECOMPILED_HEADERS)
>> >
>> > ADD_LIBRARY(MyLibDynamic SHARED ${SRC})
>> ADD_LIBRARY(MyLibStatic STATIC
>> > ${SRC})
>> >
>> > ADD_MSVC_PRECOMPILED_HEADERS(StdAfx.cpp StdAfx.h MyLibDynamic)
>> > ADD_MSVC_PRECOMPILED_HEADERS(StdAfx.cpp StdAfx.h MyLibStatic)
>> >
>> > When MyLibDynamic builds, it builds MyLibStatic.pch but
>> tries to find MyLibDynamic.pch.
>> > This is because the second function call to setup
>> precompiled headers
>> > modifies what appears to be a property that is not unique to all
>> > targets added at the same directory level of the CMakeLists.
>> >
>> > Thanks again. . .
>>
>> You might copy or symlink the concerned sources, one per
>> target, and impose the properties on these symlinks, e.g. as follows:
>>
>> ADD_CUSTOM_COMMAND(
>> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/StdAfxDynamic.cpp
>> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/StdAfxStatic.cpp
>> COMMAND ${CMAKE_COMMAND} -E create_symlink
>> ${CMAKE_CURRENT_SOURCE_DIR}/StdAfx.cpp
>> ${CMAKE_CURRENT_BINARY_DIR}/StdAfxDynamic.cpp
>> COMMAND ${CMAKE_COMMAND} -E create_symlink
>> ${CMAKE_CURRENT_SOURCE_DIR}/StdAfx.cpp
>> ${CMAKE_CURRENT_BINARY_DIR}/StdAfxStatic.cpp
>> DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/StdAfx.cpp
>> )
>>
>> ADD_LIBRARY(MyLibDynamic SHARED StdAfxDynamic.cpp ${SRC})
>> ADD_LIBRARY(MyLibStatic STATIC StdAfxStatic.cpp ${SRC})
>>
>> ADD_MSVC_PRECOMPILED_HEADERS(StdAfxDynamic.cpp StdAfx.h
>> MyLibDynamic) ADD_MSVC_PRECOMPILED_HEADERS(StdAfxStatic.cpp
>> StdAfx.h MyLibStatic)
>>
>> Of course, SRC mustn't contain StdAfx.cpp anymore for this to work.
>>
>> 'hope that helps.
>>
>> Regards,
>>
>> Michael
>
> Thanks for the reply. While I haven't tested this solution out,
> I don't think I would prefer this kind of solution, as I would
> hope that CMake would support this option out of the box.
>
> Looks like I'll have to see if there is a ticket for this
> kind of change or search the code to see how hard this
> can be added to CMake.
>
> Thanks,
>
> Ryan
> ___
> 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] Deb Package messages only if deb is available
2011/3/17 Dixon, Shane :
> I want to add some messages at the end of cmake that display all the
> DEB-related variables and what they’re set to. I’d prefer to now shows
> these when building on windows where DEB isn’t available. Is there
> something like
>
>
>
> If(DEBIAN_FOUND)
This is not currently possible because
[un]fortunately CMake is not aware of CPack generator existence :-]
> that I can use to determine if the deb package builder will be used? Should
> I scan CPACK_GENERATORS for ‘DEB”?
You cannot scan that either, because this var is set to a default value by CMake
and it may be overwritten by the user.
> What’s the best way to do this?
You can try the attached cmake script which launch "cpack --help" and collect
available generators from CPack itself, if it is found then
CPACK__FOUND is set to true.
try
include(AvailableCPackGenerators.cmake)
then
if (CPACK_DEB_FOUND)
or
if (CPACK_TGZ_FOUND)
etc...
should.
If you find the feature is worth to be included in CMake mainstream
file a feature request and attach the file (or a modified version if
you can do it in a better way).
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
find_program(CPACK_PROGRAM NAMES cpack)
if (CPACK_PROGRAM)
# Analyze 'cpack --help' output for list of available generators:
#
execute_process(COMMAND ${CPACK_PROGRAM} --help
RESULT_VARIABLE result
OUTPUT_VARIABLE stdout
ERROR_VARIABLE stderr)
string(REPLACE ";" "\\;" stdout "${stdout}")
string(REPLACE "\n" "E;" stdout "${stdout}")
set(collecting 0)
set(generators)
foreach(eline ${stdout})
string(REGEX REPLACE "^(.*)E$" "\\1" line "${eline}")
if(collecting AND NOT line STREQUAL "")
string(REGEX REPLACE "^ ([^ ]+) += (.*)$" "\\1" gen "${line}")
string(REGEX REPLACE "^ ([^ ]+) += (.*)$" "\\2" doc "${line}")
list(APPEND generators ${gen})
endif()
if(line STREQUAL "Generators")
set(collecting 1)
endif()
endforeach()
set(possiblegen "DEB;NSIS;RPM;STGZ;TBZ2;TGZ;TZ;ZIP;DMG;CygwinBinary;CygwinSource;DragNDrop;Bundle;PackageMaker;OSXX11")
foreach(gen ${possiblegen})
list(FIND generators "${gen}" IDX)
if(IDX EQUAL "-1")
set(CPACK_${gen}_FOUND FALSE)
else()
set(CPACK_${gen}_FOUND TRUE)
endif()
endforeach()
endif(CPACK_PROGRAM)___
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] Set Source Property For Specific Target
> > Quick question.
> >
> > I am trying to add precompiled headers to a project that
> has been converted to use Cmake.
> >
> > In our library directory, we include all our source and
> build two targets (one static and one dynamic), but setting
> multiple source values only affects the source and not the
> source associated to a particular target. Is there a way to
> get around this issue or something in the works to correct
> this, like an optional target command?
> >
> > Thanks...
> >
> > Code below describing the issue:
> >
> > FUNCTION (ADD_MSVC_PRECOMPILED_HEADERS
> > PrecompiledSource PrecompiledHeader TargetProject)
> > IF (MSVC)
> > # define the location of the precompiled header
> > SET(PrecompiledBinary
> "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}.pch")
> > # set the target project to use the precompiled binary
> > SET_PROPERTY(TARGET ${TargetProject}
> > APPEND
> > PROPERTY COMPILE_FLAGS
> > "/Yu\"${PrecompiledHeader}\"
> /Fp\"${PrecompiledBinary}\"")
> > # set the source file to compile out the pch
> > SET_PROPERTY(SOURCE ${PrecompiledSource}
> > APPEND
> > PROPERTY COMPILE_FLAGS
> > "/Yc\"${PrecompiledHeader}\"
> /Fp\"${PrecompiledBinary}\"")
> > ENDIF (MSVC)
> > ENDFUNCTION (ADD_MSVC_PRECOMPILED_HEADERS)
> >
> > ADD_LIBRARY(MyLibDynamic SHARED ${SRC})
> ADD_LIBRARY(MyLibStatic STATIC
> > ${SRC})
> >
> > ADD_MSVC_PRECOMPILED_HEADERS(StdAfx.cpp StdAfx.h MyLibDynamic)
> > ADD_MSVC_PRECOMPILED_HEADERS(StdAfx.cpp StdAfx.h MyLibStatic)
> >
> > When MyLibDynamic builds, it builds MyLibStatic.pch but
> tries to find MyLibDynamic.pch.
> > This is because the second function call to setup
> precompiled headers
> > modifies what appears to be a property that is not unique to all
> > targets added at the same directory level of the CMakeLists.
> >
> > Thanks again. . .
>
> You might copy or symlink the concerned sources, one per
> target, and impose the properties on these symlinks, e.g. as follows:
>
> ADD_CUSTOM_COMMAND(
> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/StdAfxDynamic.cpp
> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/StdAfxStatic.cpp
> COMMAND ${CMAKE_COMMAND} -E create_symlink
> ${CMAKE_CURRENT_SOURCE_DIR}/StdAfx.cpp
> ${CMAKE_CURRENT_BINARY_DIR}/StdAfxDynamic.cpp
> COMMAND ${CMAKE_COMMAND} -E create_symlink
> ${CMAKE_CURRENT_SOURCE_DIR}/StdAfx.cpp
> ${CMAKE_CURRENT_BINARY_DIR}/StdAfxStatic.cpp
> DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/StdAfx.cpp
> )
>
> ADD_LIBRARY(MyLibDynamic SHARED StdAfxDynamic.cpp ${SRC})
> ADD_LIBRARY(MyLibStatic STATIC StdAfxStatic.cpp ${SRC})
>
> ADD_MSVC_PRECOMPILED_HEADERS(StdAfxDynamic.cpp StdAfx.h
> MyLibDynamic) ADD_MSVC_PRECOMPILED_HEADERS(StdAfxStatic.cpp
> StdAfx.h MyLibStatic)
>
> Of course, SRC mustn't contain StdAfx.cpp anymore for this to work.
>
> 'hope that helps.
>
> Regards,
>
> Michael
Thanks for the reply. While I haven't tested this solution out,
I don't think I would prefer this kind of solution, as I would
hope that CMake would support this option out of the box.
Looks like I'll have to see if there is a ticket for this
kind of change or search the code to see how hard this
can be added to CMake.
Thanks,
Ryan
___
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] Warning! PATH too long installer unable to modify PATH!
On the contrary: as you can see by the number of bugs related to this one's duplicate [ http://public.kitware.com/Bug/view.php?id=10257 ] and by the number of people participating in those discussions, it is quite common for people to encounter this problem. See all the notes in the bug and its related bugs for more details. The warning you see is a compromise (but safe, even though it doesn't give you the PATH you want) position that we've taken up until such time as we use an NSIS capable of modifying PATH values up to 8192 characters in length. For now, we're stuck where we are, and you'll have to modify your PATH manually. HTH, David On Thu, Mar 17, 2011 at 1:30 PM, Anders Backman wrote: > Noone else experienced this problem? > /A > > On Mon, Mar 14, 2011 at 4:37 PM, Anders Backman wrote: >> >> Im using CPack with CMake 2.8 and when I am installing my app, I get the >> message: >> Warning! PATH too long installer unable to modify PATH! >> Seems that Im not the first: >> http://public.kitware.com/Bug/view.php?id=11931 >> >> Is this an acceptable limitation? Or is there something Im doing wrong? >> I have an "ordinary" path, not very long, and I cannot add my dir to the >> path during install. >> /A >> -- >> > > > > -- > __ > Anders Backman, HPC2N > 90187 Umeå University, Sweden > and...@cs.umu.se http://www.hpc2n.umu.se > Cell: +46-70-392 64 67 > > ___ > 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] Path to current Visual Studio installation
I haven't found a super-easy, completely reliable way to do this for all versions of Visual Studio. But here's some data for you... If it's set, for VS9 and earlier, CMAKE_MAKE_PROGRAM will point to the full path of devenv.com: CMAKE_MAKE_PROGRAM:FILEPATH=C:/PROGRA~2/MICROS~1.0/Common7/IDE/devenv.com But for VS10, that points to MSBuild, which is typically here: CMAKE_MAKE_PROGRAM:FILEPATH=C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe (and doesn't help you say anything one way or another about which/where VS is being used) And for an nmake based build, it is frequently simply "nmake" without any path info, trusting that you'll run it from the proper environment to use the right nmake whenever you do a build in that tree... Basing your code on the environment variables VS90COMNTOOLS and VS100COMNTOOLS (and prior version equivalents if needed) might be one way to do what you want. In fact, I wrote a blog article about a year ago on how to extract the VS root dir from those environment variables here in a batch file context: http://dlrdave.blogspot.com/2010/03/fun-with-batch-files.html Sorry there's not a more direct way to do it. Hope this is helpful, David On Thu, Mar 17, 2011 at 12:56 PM, James Bigler wrote: > I'm wanting to get a path that points me to where vcvarsall.bat might live. > It's usually in the VS installation directory, and I was wondering if there > was a nice convenient CMake variable that could tell me where Visual Studio > is located. > > "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat > > I see from the documentation we have various variables regarding which > version of visual studio we have: > > CMAKE_CL_64 > CMAKE_COMPILER_2005 > MSVC_IDE > MSVC_VERSION > > In my cache the path to cl is simply cl: > CMAKE_C_COMPILER:FILEPATH=cl > > Thanks, > 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 > ___ 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] Warning! PATH too long installer unable to modify PATH!
Noone else experienced this problem? /A On Mon, Mar 14, 2011 at 4:37 PM, Anders Backman wrote: > Im using CPack with CMake 2.8 and when I am installing my app, I get the > message: > > Warning! PATH too long installer unable to modify PATH! > > Seems that Im not the first: > > http://public.kitware.com/Bug/view.php?id=11931 > > Is this an acceptable limitation? Or is there something Im doing wrong? > I have an "ordinary" path, not very long, and I cannot add my dir to the > path during install. > > /A > > -- > > -- __ Anders Backman, HPC2N 90187 Umeå University, Sweden and...@cs.umu.se http://www.hpc2n.umu.se Cell: +46-70-392 64 67 ___ 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] Path to current Visual Studio installation
I'm wanting to get a path that points me to where vcvarsall.bat might live. It's usually in the VS installation directory, and I was wondering if there was a nice convenient CMake variable that could tell me where Visual Studio is located. "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat I see from the documentation we have various variables regarding which version of visual studio we have: ***CMAKE_CL_64 **CMAKE_COMPILER_2005 **MSVC_IDE **MSVC_VERSION *** In my cache the path to cl is simply cl: CMAKE_C_COMPILER:FILEPATH=cl Thanks, 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
[CMake] Deb Package messages only if deb is available
I want to add some messages at the end of cmake that display all the DEB-related variables and what they're set to. I'd prefer to now shows these when building on windows where DEB isn't available. Is there something like If(DEBIAN_FOUND) that I can use to determine if the deb package builder will be used? Should I scan CPACK_GENERATORS for 'DEB"? What's the best way to do this? --- Shane Dixon Linux Engineer / Atmel Corporation Tel: (+1)(719)540-1123 shane.di...@atmel.com / www.atmel.com The information contained in this email message may be privileged, confidential and/or protected from unauthorized disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. Please immediately notify the sender by reply if you received this email in error. Thank you for your cooperation. ___ 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] INSTALL CODE using EXEC_PROGRAM with spaces in path
When you are running an install "SCRIPT" it is simply included in the
context of the file cmake_install.cmake. So you can reference
variables that are in use in the including file inside your install
SCRIPT file. Read through the contents of a typical
cmake_install.cmake to get more ideas about what's possible in this
context.
For this case, I would reference the CMAKE_INSTALL_CONFIG_NAME
variable, something like this:
if(CMAKE_INSTALL_CONFIG_NAME STREQUAL "Debug")
set(filename "test_d.dll")
set(dir "C:/Program Files/test/lib")
else()
set(filename "test.dll")
set(dir "C:/Program Files/test/lib")
endif()
EXECUTE_PROCESS(COMMAND cmd /c regsvr32 ${filename}
WORKING_DIRECTORY "${dir}"
OUTPUT_VARIABLE ov RESULT_VARIABLE rv
OUTPUT_STRIP_TRAILING_WHITESPACE
)
HTH,
David
On Thu, Mar 17, 2011 at 12:03 PM, Urbach, Marcel [Rohmann GmbH]
wrote:
> Ok I finally got it to run. I've done it this way:
>
> EXECUTE_PROCESS(COMMAND cmd /c regsvr32 test.dll
> WORKING_DIRECTORY "C:/Program Files/test/lib"
> OUTPUT_VARIABLE ov RESULT_VARIABLE rv
> OUTPUT_STRIP_TRAILING_WHITESPACE
> )
> Works fine, but there is still the problem to get the target build name for
> installing the dll because it differs from debug to release build. When the
> debug configuration was selected the debug dll should be installed and
> registered and vice versa for release.
> Do you have any ideas to solve this?
>
>
> -Ursprüngliche Nachricht-
> Von: David Cole [mailto:david.c...@kitware.com]
> Gesendet: Dienstag, 15. März 2011 17:05
> An: Urbach, Marcel [Rohmann GmbH]
> Cc: cmake@cmake.org
> Betreff: Re: [CMake] INSTALL CODE using EXEC_PROGRAM with spaces in path
>
> Generator expressions (like your "")
> are only valid within the context of an add_custom_command call. Some
> are also available from the newer signature of the add_test command.
>
> See the docs for each of those for specific supported generator expressions.
>
> In the context of a CMake -P script (which an INSTALL(SCRIPT snippet
> is...) those are not interpreted in any way, and so will be passed
> directly as arguments to regsvr.
>
> You could see exactly what's being passed to the called executable by
> using a batch file or writing the tiniest c program possible to figure
> it all out.
>
> Boil it down to the very simplest script you can. Write an install
> script that has a bunch of hard-coded values in it until you have an
> execute_process command line that works. Then gradually generalize it
> from there. I think that approach will show you that execute_process
> works just fine if you pass it reasonable arguments.
>
>
> HTH,
> David
>
>
> On Tue, Mar 15, 2011 at 5:11 AM, Urbach, Marcel [Rohmann GmbH]
> wrote:
>>
>> Hi David
>>
>> Your solution works fine, but i still got the problem with execute_process.
>> Right now I use it this way:
>>
>> #cmakelists.txt
>> ADD_LIBRARY(${project_name} SHARED ${sources} ${headers} ${idls}
>> ${generated} ${resources} )
>> SET(project_out "${INSTALL_LIB_DIR}/${project_name}_d.dll")
>> STRING(REGEX REPLACE "/" "" project_out ${project_out} )
>> register_shared_libraries(${project_name} "${project_out}" )
>>
>> #global.cmake
>> FUNCTION(register_shared_libraries)
>> IF (WIN32)
>> SET(param1 ${ARGV0})
>> SET(param2 ${ARGV1})
>> CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/post_install.cmake.in
>> ${CMAKE_CURRENT_BINARY_DIR}/post_install.cmake @ONLY
>> )
>> INSTALL(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/post_install.cmake")
>> ENDIF()
>> ENDFUNCTION()
>>
>> #post_install.cmake.in
>> SET(file_name "@param2@")
>> MESSAGE(STATUS "file_name: ${file_name}")
>> EXEC_PROGRAM( regsvr32
>> ARGS \"/s\"
>> ARGS \"${file_name}\"
>> OUTPUT_VARIABLE ov RETURN_VALUE rv )
>>
>> MESSAGE("out ${ov}")
>> MESSAGE("res ${rv}")
>>
>> SET(project_name "@param1@")
>> MESSAGE(STATUS "project_name: ${project_name}")
>> EXECUTE_PROCESS(COMMAND regsvr32 #$
>> INPUT_FILE $
>> WORKING_DIRECTORY $
>> OUTPUT_VARIABLE ov RESULT_VARIABLE rv
>> )
>> MESSAGE("out ${ov}")
>> MESSAGE("res ${rv}")
>>
>>
>> The first version using EXEC_PROGRAM works fine, but there is a problem
>> resolving the target name. XXX.dll for release or XXX_d.for debug.
>> The second (EXECUTE_PROCESS) never returns from regsvr32 when using regsvr32
>> #$ or it says wrong syntax for file name or dir
>> name when using regsvr32 INPUT_FILE $
>> WORKING_DIRECTORY $
>>
>>
>>
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: David Cole [mailto:david.c...@kitware.com]
>> Gesendet: Montag, 14. März 2011 17:17
>> An: Urbach, Marcel [Rohmann GmbH]
>> Cc: cmake@cmake.org
>> Betreff: Re: [CMake] INSTALL CODE using EXEC_PROGRAM with spaces in path
>>
>> On Mon, Mar 14, 2011 at 11:17 AM, Urbach, Marcel [Rohmann GmbH]
>> wrote:
>>> I have already tried to use the SCRIPT. But there is a problem to submit
>>> the name of the dll or the project name to th
Re: [CMake] Cmake Dependency Generation with Compiler Specific Plugins
On 28/07/2010 15:34, Brad King wrote: On 07/27/2010 06:48 PM, Russell Harmon wrote: We're looking to use cmake on a project which has some dependencies which are not properly picked up by cmake's dependency scanner. I'm not looking to fix the scanner, because I feel the scanner is fundamentally broken: Yes, it certainly has some limitations. I agree that the solution is not to fix the current scanner. I've considered using the "wave" c++ preprocessor library but it is problematic to locate all the implicit include directories and preprocessor definitions for each compiler. Using the compiler itself to get dependencies is much better. [...] I would have (tried to) made these changes to cmake already, but since this is both a non-trivial change and an architectural change, I felt it necessary to get an ok from you before I changed anything. I'm interested in seeing a solution to this problem. Let's discuss the design here first though. What interface do you propose? Has any progress been made on this? I really need this feature. The Boost C++ libraries use such includes to generate their meta-programmation code. Several hardware abstraction libraries use such systems to include the correct files for the architectures configured. Without correct dependencies, cmake cannot be used reliably without a full clean. This is especially important when you want to deploy cmake for continuous integration solutions. Those compile and run all tests everytime someone does a commit, and there you want to avoid recompiling unnecessary code. In the meantime, is there a way to add those dependencies from a CMakeLists.txt file? OBJECT_DEPENDS doesn't seem to work. ___ 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] INSTALL CODE using EXEC_PROGRAM with spaces in path
Ok I finally got it to run. I've done it this way:
EXECUTE_PROCESS(COMMAND cmd /c regsvr32 test.dll
WORKING_DIRECTORY "C:/Program Files/test/lib"
OUTPUT_VARIABLE ov RESULT_VARIABLE rv
OUTPUT_STRIP_TRAILING_WHITESPACE
)
Works fine, but there is still the problem to get the target build name for
installing the dll because it differs from debug to release build. When the
debug configuration was selected the debug dll should be installed and
registered and vice versa for release.
Do you have any ideas to solve this?
-Ursprüngliche Nachricht-
Von: David Cole [mailto:david.c...@kitware.com]
Gesendet: Dienstag, 15. März 2011 17:05
An: Urbach, Marcel [Rohmann GmbH]
Cc: cmake@cmake.org
Betreff: Re: [CMake] INSTALL CODE using EXEC_PROGRAM with spaces in path
Generator expressions (like your "")
are only valid within the context of an add_custom_command call. Some
are also available from the newer signature of the add_test command.
See the docs for each of those for specific supported generator expressions.
In the context of a CMake -P script (which an INSTALL(SCRIPT snippet
is...) those are not interpreted in any way, and so will be passed
directly as arguments to regsvr.
You could see exactly what's being passed to the called executable by
using a batch file or writing the tiniest c program possible to figure
it all out.
Boil it down to the very simplest script you can. Write an install
script that has a bunch of hard-coded values in it until you have an
execute_process command line that works. Then gradually generalize it
from there. I think that approach will show you that execute_process
works just fine if you pass it reasonable arguments.
HTH,
David
On Tue, Mar 15, 2011 at 5:11 AM, Urbach, Marcel [Rohmann GmbH]
wrote:
>
> Hi David
>
> Your solution works fine, but i still got the problem with execute_process.
> Right now I use it this way:
>
> #cmakelists.txt
> ADD_LIBRARY(${project_name} SHARED ${sources} ${headers} ${idls} ${generated}
> ${resources} )
> SET(project_out "${INSTALL_LIB_DIR}/${project_name}_d.dll")
> STRING(REGEX REPLACE "/" "" project_out ${project_out} )
> register_shared_libraries(${project_name} "${project_out}" )
>
> #global.cmake
> FUNCTION(register_shared_libraries)
> IF (WIN32)
> SET(param1 ${ARGV0})
> SET(param2 ${ARGV1})
> CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/post_install.cmake.in
> ${CMAKE_CURRENT_BINARY_DIR}/post_install.cmake @ONLY
> )
> INSTALL(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/post_install.cmake")
> ENDIF()
> ENDFUNCTION()
>
> #post_install.cmake.in
> SET(file_name "@param2@")
> MESSAGE(STATUS "file_name: ${file_name}")
> EXEC_PROGRAM( regsvr32
> ARGS \"/s\"
> ARGS \"${file_name}\"
> OUTPUT_VARIABLE ov RETURN_VALUE rv )
>
> MESSAGE("out ${ov}")
> MESSAGE("res ${rv}")
>
> SET(project_name "@param1@")
> MESSAGE(STATUS "project_name: ${project_name}")
> EXECUTE_PROCESS(COMMAND regsvr32 #$
> INPUT_FILE $
> WORKING_DIRECTORY $
> OUTPUT_VARIABLE ov RESULT_VARIABLE rv
> )
> MESSAGE("out ${ov}")
> MESSAGE("res ${rv}")
>
>
> The first version using EXEC_PROGRAM works fine, but there is a problem
> resolving the target name. XXX.dll for release or XXX_d.for debug.
> The second (EXECUTE_PROCESS) never returns from regsvr32 when using regsvr32
> #$ or it says wrong syntax for file name or dir
> name when using regsvr32 INPUT_FILE $
> WORKING_DIRECTORY $
>
>
>
>
>
> -Ursprüngliche Nachricht-
> Von: David Cole [mailto:david.c...@kitware.com]
> Gesendet: Montag, 14. März 2011 17:17
> An: Urbach, Marcel [Rohmann GmbH]
> Cc: cmake@cmake.org
> Betreff: Re: [CMake] INSTALL CODE using EXEC_PROGRAM with spaces in path
>
> On Mon, Mar 14, 2011 at 11:17 AM, Urbach, Marcel [Rohmann GmbH]
> wrote:
>> I have already tried to use the SCRIPT. But there is a problem to submit the
>> name of the dll or the project name to the extern script. I need something
>> like a parameter and I guess that doesn't exsist. Do you have any ideas to
>> solve this?
>> INSTALL(SCRIPT "PostInst.cmake" PARAMETeR...)
>>
>
> How about something like this?
>
> # File "script.cmake.in"
> set(p1 "@param1@")
> execute_process(COMMAND xyz ${p1} OUTPUT_VARIABLE ov RESULT_VARIABLE rv)
> if(NOT rv STREQUAL "0")
> message(FATAL_ERROR "xyz failed: rv='${rv}'")
> endif()
>
> And then:
>
> # in CMakeLists.txt
> set(param1 "value-of-p1")
> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/script.cmake.in
> ${CMAKE_CURRENT_BINARY_DIR}/script.cmake @ONLY)
> install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/script.cmake")
>
>
> I have written code in the past which calls regsvr32 successfully.
> What are the arguments you are passing that are causing problems? Can
> you call the same regsvr32 from the Windows command prompt
> successfully? Are you using the same regsvr32 in both scenarios?
>
>
>> I also tried to use execute_process, but it didn't work with regsvr32.
>> It ended in a
Re: [CMake] vs2010 MANIFESTUAC not handled correctly
Well I tried looking at the code and found cmVS10LinkFlagTable.h was the
only file to mention MANIFESTUAC. But I can't figure out a simple fix. It
pretty obvious this entry in the table is way to simple:
{"UACUIAccess", "MANIFESTUAC:", "Enable User Account Control (UAC)", "",
cmVS7FlagTable::UserValueRequired}
It seems to just take whatever is after the colon and stuff it in the
UACUIAccess element in the project. But it needs to be smarter than that.
The MSDN page (http://msdn.microsoft.com/en-us/library/bb384691.aspx) says
it could have the form of:
"level=[ asInvoker | highestAvailable | requireAdministrator ] uiAccess=[
true | false ]"
Which isn't a simple "//Bool Properties With Argument". Thoughts?
---
Aaron Wright
cmake-boun...@cmake.org wrote on 03/15/2011 08:23:55 AM:
> From: aaron_wri...@selinc.com
> To: cmake@cmake.org
> Date: 03/15/2011 08:24 AM
> Subject: [CMake] vs2010 MANIFESTUAC not handled correctly
> Sent by: cmake-boun...@cmake.org
>
> I'm trying to use this in my CMake file for a simple executable:
>
> SET_TARGET_PROPERTIES(
> your_executable
> PROPERTIES LINK_FLAGS
"/MANIFESTUAC:\"level='requireAdministrator'
> uiAccess='false'\"")
>
> This worked in vs2008, but not in vs2010. The project contains:
>
> level='requireAdministrator' uiAccess='false'
>
> But needs:
>
> requireAdministrator
> false
>
> Am I using this the correct way, or is there a way to do it to get the
> desired results?
> ---
> Aaron Wright
> ___
> 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
[CMake] Fwd: Setting Build properties for VS 2008
-- Forwarded message -- From: John Drescher Date: Thu, Mar 17, 2011 at 5:43 AM Subject: Re: [CMake] Setting Build properties for VS 2008 To: Dan Furtney On Wed, Mar 16, 2011 at 11:25 PM, Dan Furtney wrote: > Is there a way for cmake to set the active build in a multi-project VS > solution? > Not directly. However you may be able to generate a .user file (xml based user settings file) without too much effort. John -- John M. Drescher ___ 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
