[CMake] IAR IDE Generator Support
Hello, Does someone know about any initiative to add IAR WorkBench IDE to the list of supported generators. I cannot find a Mantis issue about that. This would not be a Makefile based generator but a native one like XCode or VisualStudio. Regards, Gregoire -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
Hello, I use astyle in my projects but it is not related to build (not a target). I have a cmake script that I launch using cmake -P so I don't have to write too much .bat or .sh scripts. This script has the following options (using -D command line parameters): - folder where to recursively find the sources to be beautified - whether or not to run the tool inplace or copy files to another directory first so I can do a diff between before and after Regards, Gregoire -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of ? ? Sent: vendredi 31 janvier 2014 16:54 To: Leif Walsh Cc: cmake@cmake.org Subject: Re: [CMake] AStyle or similar code beautifier 2014-01-31 Leif Walsh leif.wa...@gmail.com: What would be a good way to run a tool like this just before compiling? I'd prefer running such a tool *after* compiling. If you have a syntax error, your sources can be ruinned. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Read memory tests results with jenkins
Hello Bogdan, I know there is a valgrind plugin for Jenkins but I do not know if it integrates well with CTest outputs. https://wiki.jenkins-ci.org/display/JENKINS/Valgrind+Plugin Regards, Gregoire -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Bogdan Cristea Sent: mardi 12 novembre 2013 12:37 To: cmake Subject: [CMake] Read memory tests results with jenkins Hi I am running memory leak tests using ctest as follows ctest -D ExperimentalMemCheck I have already in place a jenkins server for continuous build and I am wondering if it is possible to read the memory check report from Jenkins. I am aware of the existence of a Jenkins plugin for Valgrind, but I don't know how to use this one with ctest. regards Bogdan -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 3.0?
Perfect, thanks. Gregoire -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Matthew Woehlke Sent: lundi 21 octobre 2013 21:17 To: cmake@cmake.org Subject: Re: [CMake] CMake 3.0? On 2013-10-21 04:12, Gregoire Aujay wrote: I have seen that CMake 2.8.13 has been removed from the Mantis Roadmap. Instead there is a new 3.0 version Can you tell us more about it? See http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/8207. -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake 3.0?
Hello, I have seen that CMake 2.8.13 has been removed from the Mantis Roadmap. Instead there is a new 3.0 version Can you tell us more about it? Does that mean that we are to expect great new stuff ? I guess it will break backward compatibility since you change major, what is going to be broken/dropped? Regards, Gregoire -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Ninja CMake 2.8.12: source generated with configure_file
Hello, Since I upgraded to CMake 2.8.12 I have this message for some of my configure_file generated sources: ninja: warning: multiple rules generate _cmakeRelease\tests\GeneratedSources\versioninfo.rc. builds involving this target will not be correct; continuing anyway Any idea how I could fix that ? Thanks, Gregoire -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install(EXPORT ...) behavior for multi-configuration generators
Hello,
Can someone help me with this issue, see description below.
I had to disable install(EXPORT ...) when using multi-configuration generators.
This leads to errors for people using one of them.
Issue is that I cannot export targets that are installed in different locations
(one for debug, another one for release) with multi-conf generators.
Regards,
Gregoire
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Gregoire Aujay
Sent: lundi 7 janvier 2013 18:57
To: cmake@cmake.org
Subject: [CMake] install(EXPORT ...) behavior for multi-configuration generators
Hello,
I am using CMake 2.8.10.2, on windows.
I am trying to use install(TARGETS ) and install(EXPORT ) both with NMake
makefiles and with the multi-configuration generator Visual studio.
I cannot get the same behavior when I want my binaries to be installed in a
subfolder that depends on the configuration, e.g. :
- Debug/bin/myLib.dll
- Release/bin/myLib.dll
If I do that :
#start
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION \${CMAKE_INSTALL_CONFIG_NAME}/lib
LIBRARY DESTINATION\${CMAKE_INSTALL_CONFIG_NAME}/lib
RUNTIME DESTINATION \${CMAKE_INSTALL_CONFIG_NAME}/bin
)
install(EXPORT myTargets DESTINATION cmake)
#end
This works find for NMake and Visual for install rules because
${CMAKE_INSTALL_CONFIG_NAME} will be evaluated at install time.
But in my myTargets-debug.cmake import files, ${CMAKE_INSTALL_CONFIG_NAME} will
not be evaluated correctly.
Now If I do that:
#start
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION Debug/lib
LIBRARY DESTINATIONDebug/lib
RUNTIME DESTINATION Debug/bin
CONFIGURATIONS Debug
)
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION Release/lib
LIBRARY DESTINATIONRelease/lib
RUNTIME DESTINATION Release/bin
CONFIGURATIONS Release
)
install(EXPORT myTargets DESTINATION cmake)
# end
CMake will complain that:
CMake Error: INSTALL(EXPORT myTargets ...) includes target myLib more
than once in the export set.
Is this a bug that CMake complains about a target being exported twice but with
different configurations?
Does anyone have a workaround?
Regards,
Gregoire
--
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] Jenkins CTest xml output
Hello, The maintener of Jenkins' xUnit plugin has added the support of CTest xml output format. It uses rpavlik xslt file to transform CTest xml format to JUnit's. https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin https://github.com/rpavlik/jenkins-ctest-plugin Regards, Gregoire -- 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] cmake --build . and colors
Hello, Ok tell me if I am wrong but what you're saying is that it is possible to enable a pass-thru mode for cmake --build but currently it is not implementer? Meanwhile I finally found a workaround using the build_command Command that I did not see before: http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:build_command During CMake phase I can output all the build commands I want: - one with all target - the other one with @_target_@ so I configure it later Then I use these files to build my .bat / .sh that I can launch. I seems to work fine, I have my colors and my compact ninja output. But now with MSVC_IDE the output is disabled, I can live with that for now :) Regards, Gregoire -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Brad King Sent: vendredi 17 mai 2013 17:43 To: Leif Walsh Cc: cmake@cmake.org; Andreas Mohr Subject: Re: [CMake] cmake --build . and colors On 05/04/2013 08:12 AM, Leif Walsh wrote: I think the colors and carriage returns (without line feeds) are lost because the build tool sees its controlling terminal is cmake, not a real terminal program capable of showing color or redrawing, so it doesn't output them. Cmake may be logging this stuff too (to send to cdash for example) so this is kind of a responsible choice. This is correct, but it doesn't have to be so. In the case of a direct cmake --build ... invocation from a terminal CMake is not doing any special logging so it should be able to share its host terminal such that isatty() returns true for the underlying tools. The cmake --build ... implementation ultimately runs through the cmSystemTools::RunSingleCommand code path: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSystemTools.cxx;hb=v2.8.11#l615 in order to invoke the native build command. One could add an option to that code path to share the output pipes with the cmake process just like ctest --launch does in pass-thru mode: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CTest/cmCTestLaunch.cxx;hb=v2.8.11#l221 cmsysProcess_SetPipeShared(cp, cmsysProcess_Pipe_STDOUT, 1); cmsysProcess_SetPipeShared(cp, cmsysProcess_Pipe_STDERR, 1); One could then activate that from the cmake --build call site by passing the option through all the intermediate levels of the call stack (cmake::Build and cmGlobalGenerator::Build IIRC). -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 -- 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] cmake --build . and colors
Hello, I am still trying to find a solution to get those colors displayed. Especially when I read that :) http://www.phoronix.com/scan.php?page=news_itempx=MTM2MzI I came to the conclusion that the only way to do so is to run the native build tool directly from the command line. So I thougth of a solution: an option could be added to cmake command line to output the native command corresponding to the cmake --build. Then I could write that output to a script and run it. cmake --build . --target foo -- -j3 Would output something like that when using Ninja generator: path_to_ninja foo -j3 What do you think? Regards, Gregoire -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Andreas Mohr Sent: samedi 4 mai 2013 14:48 To: Leif Walsh Cc: cmake@cmake.org; Andreas Mohr Subject: Re: [CMake] cmake --build . and colors On Sat, May 04, 2013 at 05:12:14AM -0700, Leif Walsh wrote: cmake --build . -- -jN Extra args after -- are passed through to the build tool. Doesn't work if the tool expects something different though. Ah, cool (took note to improve my script). While -- is some pretty standard mechanism, CMake usage screen (dito man page! Likely same info source...) does not explicitly document it, though (will add docs, currently doing that anyway). It's of course somewhat bitter to have a nice tool-abstracted --build mechanism yet then still having to know tool-specific parameters in a script. Talk about incomplete abstraction. I think the colors and carriage returns (without line feeds) are lost because the build tool sees its controlling terminal is cmake, not a real terminal program capable of showing color or redrawing, so it doesn't output them. Cmake may be logging this stuff too (to send to cdash for example) so this is kind of a responsible choice. Indeed, that possibly gets decided via the controlling terminal's features. Andreas Mohr -- 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] cmake --build . and colors
Hello, I am wondering if there is any trick to enable colors when running this command: cmake --build . The only way I manage to get the colors is to directly use the make program, e.g.: mingw32-make all The issue is that I am trying to use a script that runs cmake to build instead of the make program that may change (ninja, mingw-make, make, msvc, etc). Regards, Gregoire -- 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] cmake --build . and colors
Hello, I also found that using cmake --build . with ninja outputs all lines but if I directly use ninja to build it only outputs one line which is very cool (it clears current line before printing the new one if there is no warning/error). Regards, Gregoire From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Gregoire Aujay Sent: vendredi 3 mai 2013 16:39 To: cmake@cmake.org Subject: [CMake] cmake --build . and colors Hello, I am wondering if there is any trick to enable colors when running this command: cmake --build . The only way I manage to get the colors is to directly use the make program, e.g.: mingw32-make all The issue is that I am trying to use a script that runs cmake to build instead of the make program that may change (ninja, mingw-make, make, msvc, etc). Regards, Gregoire -- 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] MINGW and strip .dll.a files
Hello,
I filed a bug for this issue, to prevent cmake from stripping .dll.a files:
http://public.kitware.com/Bug/view.php?id=14123
Regards,
Gregoire
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Gregoire Aujay
Sent: jeudi 25 avril 2013 14:14
To: cmake@cmake.org
Subject: Re: [CMake] MINGW and strip .dll.a files
Hello,
I am just forwarding our discussion to the mailing list. We did not use reply
to all.
Highligth:
So, I see no point in striping the .dll.a file. But, of course, I might be
wrong. Please, anybody can check this?
Regards,
Gregoire
From: Daniel Franzini [mailto:daniel.franz...@gmail.com]
Sent: jeudi 25 avril 2013 13:30
To: Gregoire Aujay
Subject: Re: [CMake] MINGW and strip .dll.a files
The strip program just removes unused symbols from any object code.
This is Win32/Mingw specific stuff (MSVC have the same stuff but they use their
own object format).
When you compile a DLL, you have two options:
1.) hand write your own LoadLibrary/FreeLibrary code and just distribute the
DLL with your
exe (or other DLL)
2.) static-link your exe against the dll.a file which is generated by the
linker and is win32 specific magic code that have stubs to the functions it
will call from the DLL.
Either way you have to distribute the DLL with your exe.
The .dll.a (called import library) file is generated by the linker with
appropriate options and it is reported to be buggy in the past. I'm not sure
nowadays.
So, I see no point in striping the .dll.a file. But, of course, I might be
wrong. Please, anybody can check this?
On Thu, Apr 25, 2013 at 4:42 AM, Gregoire Aujay
gau...@movea.commailto:gau...@movea.com wrote:
Hello ;
So you agree that CMake should not strip .dll.a files.
Currently that is what is done in the cmake_install.cmake files, e.g. I get
(CMake 2.8.10.2):
IF(NOT CMAKE_INSTALL_COMPONENT OR ${CMAKE_INSTALL_COMPONENT} STREQUAL
Unspecified)
FILE(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/release/lib TYPE
STATIC_LIBRARY OPTIONAL FILES XX/release/lib/libmyLib.dll.a)
IF(EXISTS $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/release/lib/ libmyLib.dll.a
AND
NOT IS_SYMLINK $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/release/lib/
libmyLib.dll.a)
IF(CMAKE_INSTALL_DO_STRIP)
EXECUTE_PROCESS(COMMAND YY/bin/strip.exe
$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/release/lib/ libmyLib.dll.a)
ENDIF(CMAKE_INSTALL_DO_STRIP)
ENDIF()
ENDIF(NOT CMAKE_INSTALL_COMPONENT OR ${CMAKE_INSTALL_COMPONENT} STREQUAL
Unspecified)
Unless someone tells me it is done intentionally I will file a bug.
Regards,
Gregoire
From: Daniel Franzini
[mailto:daniel.franz...@gmail.commailto:daniel.franz...@gmail.com]
Sent: mercredi 24 avril 2013 19:52
To: Gregoire Aujay
Subject: Re: [CMake] MINGW and strip .dll.a files
AFAIK, the dll.a file is a import library
It contains code that magically calls the DLL functions without having you to
write LoadLibrary/FreeLibrary code.
Why are you stripping it anyway? The import libray should be linked as-is with
your binary and them strip the binary.
NOTE: it does not contain the actual DLL code. It only have stubs that calls
DLL functions.
On Wed, Apr 24, 2013 at 10:58 AM, Gregoire Aujay
gau...@movea.commailto:gau...@movea.com wrote:
Hello,
I am trying to package a stripped library built with MINGW.
When I activate strip during install or pack, I get link error (unresolved
symbols) when using this library.
When I strip using -s option, everything is fine.
The difference is that my .dll.a is smaller when I use CMake strip feature. Gcc
does not seem to strip the .dll.a file.
Is it a good approach to strip the .dll.a file ?
Regards,
Gregoire
--
Powered by www.kitware.comhttp://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
--
Daniel
Let us change our traditional attitude to the construction of programs.
Instead of imagining that our main task is to instruct a computer what to do,
let us concentrate rather on explaining to human beings what we want a computer
to do. (Donald Knuth)
Yes, technogeeks can be funny, even if only to each other.
(http://www.boogieonline.com/revolution/science/humor/)
Man is driven to create; I know I really love to create things. And while I'm
not good at painting, drawing, or music, I can write software. (Yukihiro
Matsumoto, a.k.a. ``Matz'')
--
Daniel
Let us change our traditional attitude to the construction of programs.
Instead of imagining that our main task is to instruct a computer what to do,
let us concentrate rather on explaining to human beings what we want a computer
to do. (Donald Knuth)
Yes, technogeeks can be funny, even if only to each other.
(http://www.boogieonline.com/revolution/science/humor/)
Man is driven
Re: [CMake] MINGW and strip .dll.a files
Hello,
I am just forwarding our discussion to the mailing list. We did not use reply
to all.
Highligth:
So, I see no point in striping the .dll.a file. But, of course, I might be
wrong. Please, anybody can check this?
Regards,
Gregoire
From: Daniel Franzini [mailto:daniel.franz...@gmail.com]
Sent: jeudi 25 avril 2013 13:30
To: Gregoire Aujay
Subject: Re: [CMake] MINGW and strip .dll.a files
The strip program just removes unused symbols from any object code.
This is Win32/Mingw specific stuff (MSVC have the same stuff but they use their
own object format).
When you compile a DLL, you have two options:
1.) hand write your own LoadLibrary/FreeLibrary code and just distribute the
DLL with your
exe (or other DLL)
2.) static-link your exe against the dll.a file which is generated by the
linker and is win32 specific magic code that have stubs to the functions it
will call from the DLL.
Either way you have to distribute the DLL with your exe.
The .dll.a (called import library) file is generated by the linker with
appropriate options and it is reported to be buggy in the past. I'm not sure
nowadays.
So, I see no point in striping the .dll.a file. But, of course, I might be
wrong. Please, anybody can check this?
On Thu, Apr 25, 2013 at 4:42 AM, Gregoire Aujay
gau...@movea.commailto:gau...@movea.com wrote:
Hello ;
So you agree that CMake should not strip .dll.a files.
Currently that is what is done in the cmake_install.cmake files, e.g. I get
(CMake 2.8.10.2):
IF(NOT CMAKE_INSTALL_COMPONENT OR ${CMAKE_INSTALL_COMPONENT} STREQUAL
Unspecified)
FILE(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/release/lib TYPE
STATIC_LIBRARY OPTIONAL FILES XX/release/lib/libmyLib.dll.a)
IF(EXISTS $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/release/lib/ libmyLib.dll.a
AND
NOT IS_SYMLINK $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/release/lib/
libmyLib.dll.a)
IF(CMAKE_INSTALL_DO_STRIP)
EXECUTE_PROCESS(COMMAND YY/bin/strip.exe
$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/release/lib/ libmyLib.dll.a)
ENDIF(CMAKE_INSTALL_DO_STRIP)
ENDIF()
ENDIF(NOT CMAKE_INSTALL_COMPONENT OR ${CMAKE_INSTALL_COMPONENT} STREQUAL
Unspecified)
Unless someone tells me it is done intentionally I will file a bug.
Regards,
Gregoire
From: Daniel Franzini
[mailto:daniel.franz...@gmail.commailto:daniel.franz...@gmail.com]
Sent: mercredi 24 avril 2013 19:52
To: Gregoire Aujay
Subject: Re: [CMake] MINGW and strip .dll.a files
AFAIK, the dll.a file is a import library
It contains code that magically calls the DLL functions without having you to
write LoadLibrary/FreeLibrary code.
Why are you stripping it anyway? The import libray should be linked as-is with
your binary and them strip the binary.
NOTE: it does not contain the actual DLL code. It only have stubs that calls
DLL functions.
On Wed, Apr 24, 2013 at 10:58 AM, Gregoire Aujay
gau...@movea.commailto:gau...@movea.com wrote:
Hello,
I am trying to package a stripped library built with MINGW.
When I activate strip during install or pack, I get link error (unresolved
symbols) when using this library.
When I strip using -s option, everything is fine.
The difference is that my .dll.a is smaller when I use CMake strip feature. Gcc
does not seem to strip the .dll.a file.
Is it a good approach to strip the .dll.a file ?
Regards,
Gregoire
--
Powered by www.kitware.comhttp://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
--
Daniel
Let us change our traditional attitude to the construction of programs.
Instead of imagining that our main task is to instruct a computer what to do,
let us concentrate rather on explaining to human beings what we want a computer
to do. (Donald Knuth)
Yes, technogeeks can be funny, even if only to each other.
(http://www.boogieonline.com/revolution/science/humor/)
Man is driven to create; I know I really love to create things. And while I'm
not good at painting, drawing, or music, I can write software. (Yukihiro
Matsumoto, a.k.a. ``Matz'')
--
Daniel
Let us change our traditional attitude to the construction of programs.
Instead of imagining that our main task is to instruct a computer what to do,
let us concentrate rather on explaining to human beings what we want a computer
to do. (Donald Knuth)
Yes, technogeeks can be funny, even if only to each other.
(http://www.boogieonline.com/revolution/science/humor/)
Man is driven to create; I know I really love to create things. And while I'm
not good at painting, drawing, or music, I can write software. (Yukihiro
Matsumoto, a.k.a. ``Matz'')
--
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
Re: [CMake] cmake script profiler
Hello,
Are you using cmake with a Makefiles generator on Windows ?
From my experiments here are my observations:
- Makefiles on Windows: slow
- Visual ide generator : fast
- Makefiles on linux: fast
I found that when there are many targets in a project, cmake has to write many
small files on the HD which seems to be very slow on windows.
Regards,
Gregoire
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Volo Zyko
Sent: mardi 23 avril 2013 21:51
To: cmake@cmake.org
Subject: [CMake] cmake script profiler
Hi all,
We have a rather big project and use cmake for building it. At some point our
cmake scripts became very slow (around 4 minutes for single cmake run). We are
thinking now how to speed up it. Searching the web and this list didn't give
any results. It looks like there is no such thing as profiler for cmake
scripts. Am I right?
What about adding such capability to cmake? It looks like cmake's trace
provides enough info for time profiling, the only thing that it lacks is a time
stamp. Below is a small patch that adds time stamp and nesting level (to
simplify building a stack trace) to each trace line. Would it be possible to
integrate this change to the main line or are there better options for time
profiling of cmake?
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 25ccbc7..0e6725c 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -361,6 +361,8 @@ bool cmMakefile::GetBacktrace(cmListFileBacktrace
backtrace) const
void cmMakefile::PrintCommandTrace(const cmListFileFunction lff)
{
cmOStringStream msg;
+ msg ( std::fixed cmSystemTools::GetTime();
+ msg ) ( this-CallStack.size() ) ;
msg lff.FilePath ( lff.Line ): ;
msg lff.Name (;
for(std::vectorcmListFileArgument::const_iterator i =
--
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] MINGW and strip .dll.a files
Hello, I am trying to package a stripped library built with MINGW. When I activate strip during install or pack, I get link error (unresolved symbols) when using this library. When I strip using -s option, everything is fine. The difference is that my .dll.a is smaller when I use CMake strip feature. Gcc does not seem to strip the .dll.a file. Is it a good approach to strip the .dll.a file ? Regards, Gregoire -- 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] Why does Project(name NONE) requires CMAKE_MAKE_PROGRAM?
Hello, It seems that the Projetct(name NONE) macro requires the CMAKE_MAKE_PROGRAM to be defined. This CMakelists will trigger a CMAKE_MAKE_PROGRAM not found, when trying to cross-compile with code sourcery toolchain which is using a non-trivial make program name: cmake_minimum_required(VERSION 2.8) Project(Foo NONE) # Init my stuff set(CMAKE_MAKE_PROGRAM cs-make.exe CACHE STRING make program FORCE) enable_language( C ) # declare targets add_library(foo STATIC bar.c) Thanks, Gregoire I am using cmake 2.8.10 on win7 64 -- 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] Disabling Argument Parsing in CMake -P Scripts
Hello,
I would be interested in the '--' to disable command line argument parsing by
CMake.
Has someone opened an issue on mantis for this one ?
Regards,
Gregoire
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
David Cole
Sent: samedi 3 novembre 2012 00:05
To: Eskandar Ensafi
Cc: cmake
Subject: Re: [CMake] Disabling Argument Parsing in CMake -P Scripts
On Fri, Nov 2, 2012 at 5:44 PM, Eskandar Ensafi ens...@spacecomputer.com
wrote:
I'm not sure if I'm qualified to propose a patch, but I will look at the
source code to see what I can come up with. I have additional concerns about
the way the CMAKE_ARGVn variables are initialized, and this might be a good
time to address these concerns.
I don't know if this was a design choice, but with some exceptions,
CMake seems to first parse the entire command-line, and then it runs
each -P script in order, with CMAKE_ARGC/ARGVn initialized to the
entire command-line, not just the arguments following the appropriate
-P script. When the command-line is parsed, some recognized options
are removed (e.g. -L[A][H], -N) with no ill effect, others are removed
but interfere with the initialization of CMAKE_ARGC/ARGVn (e.g.
--help, --version, and all variants), and some are parsed but NOT
removed (e.g. -D name:type=value, -G generator, contrary to comments
in my previous e-mail). A more robust treatment of these command-line
arguments would be to fail with an error if incompatible combinations
of options are detected, and if any options are recognized and parsed
by CMake, they should be removed from the command-line. Parsing
errors should cause to CMake to exit with an error, but this is not
consistent (-G fails given a bog
us generator, but -D with a badly formed argument allows CMake to continue).
To demonstrate, take the following simple example:
# MyScript.cmake
MESSAGE( BEGIN SCRIPT )
IF (DEFINED MyVar)
MESSAGE(MyVar = ${MyVar})
ENDIF()
MESSAGE(CMAKE_ARGC = ${CMAKE_ARGC})
MATH(EXPR ARGC ${CMAKE_ARGC} - 1)
FOREACH(I RANGE 0 ${ARGC})
MESSAGE(CMAKE_ARGV${I} = ${CMAKE_ARGV${I}})
ENDFOREACH()
MESSAGE( END SCRIPT )
Then run it as follows:
cmake -P MyScript.cmake testing -DMyVar=Test one two three -P
MyScript.cmake four five six
BEGIN SCRIPT
CMAKE_ARGC = 13
CMAKE_ARGV0 = cmake
CMAKE_ARGV1 = -P
CMAKE_ARGV2 = MyScript.cmake
CMAKE_ARGV3 = testing
CMAKE_ARGV4 = -DMyVar=Test
CMAKE_ARGV5 = one
CMAKE_ARGV6 = two
CMAKE_ARGV7 = three
CMAKE_ARGV8 = -P
CMAKE_ARGV9 = MyScript.cmake
CMAKE_ARGV10 = four
CMAKE_ARGV11 = five
CMAKE_ARGV12 = six
END SCRIPT
BEGIN SCRIPT
MyVar = Test
CMAKE_ARGC = 13
CMAKE_ARGV0 = cmake
CMAKE_ARGV1 = -P
CMAKE_ARGV2 = MyScript.cmake
CMAKE_ARGV3 = testing
CMAKE_ARGV4 = -DMyVar=Test
CMAKE_ARGV5 = one
CMAKE_ARGV6 = two
CMAKE_ARGV7 = three
CMAKE_ARGV8 = -P
CMAKE_ARGV9 = MyScript.cmake
CMAKE_ARGV10 = four
CMAKE_ARGV11 = five
CMAKE_ARGV12 = six
END SCRIPT
Notice how the entire command-line, including intervening -P options and the
parsed -D option, is made available to both scripts (i.e. they are both
executed with the same CMAKE_ARGC/ARGVn even though CMAKE_ARGV7 was the last
argument for the first script, and CMAKE_ARGV10 to CMAKE_ARGV12 were the
arguments for the second script). This may or may not be useful, but to
avoid breaking compatibility, I propose defining something like
CMAKE_ARGC_FIRST and CMAKE_ARGC_LAST in each -P script invocation so that we
can determine the range of options specific to the script being executed.
Now, if we deliberately introduce an error in the -D flag as follows:
cmake -P MyScript.cmake testing -DMyVar one two three -P
MyScript.cmake four five six
Then CMake will run the first script, and it will exit with an error when it
tries to parse -DMyVar (missing value).
Since implementing a -- option will require some changes to CMake's
command-line parsing logic, I suggest that we fix the aforementioned issues
as part of this effort. Again, I am not the best person to undertake this
effort due to my lack of familiarity with the CMake code base, but if someone
with more experience would like to collaborate with me, I would be more than
happy to help.
Best,
Eskandar
On Nov 2, 2012, at 2:45 AM, David Cole wrote:
-- for script mode is a good idea. (Actually, if we had this for
non-script mode even, it would then make sense to expose the command
line arguments in similar variables even when configuring a
CMakeLists file. Presently, the CMAKE_ARGVn vars are only available
in script
mode.)
Can you propose a patch?
If so, open a feature request in the bug tracker, and attach a git
format-patch -1 file.
Thanks,
David
On Fri, Nov 2, 2012 at 12:21 AM, Eskandar Ensafi
ens...@spacecomputer.com wrote:
Hello,
I often find it very useful to run CMake scripts of the form cmake -P
script-name arg1 arg2 ... as a
Re: [CMake] Build several targets using cmake --build dir
Hello, Thanks for your replies. I understand that I can only 'cmake --build' one target at a time. I think that the solutions you propose do not benefit from tools, like ninja, that have parallel build capabilities. I'll file a feature request. Regards, Greg -Original Message- From: Nick Overdijk [mailto:n...@astrant.net] Sent: jeudi 14 mars 2013 19:10 To: John Drescher Cc: Gregoire Aujay; cmake@cmake.org Subject: Re: [CMake] Build several targets using cmake --build dir You can only 'cmake' a single-target. If you want to have more targets, create more directories: for each target one. On 2013-14-03, at 19:07:36 , John Drescher wrote: I use cmake 2.8.10 on windows. I would like to build several targets with cmake --build dir so the underlying build tool to do parallel jobs. Currently it only seems to be possible to build one target at a time, using --target . (http://www.cmake.org/cmake/help/v2.8.10/cmake.html#opt:--builddir) Can someone tell me how I could achieve that with current cmake version? I execute more than 1 cmake --build at the same time on windows. I actually do this in a program called runjobs http://www.codeproject.com/Articles/25810/Run-All-Jobs-at-Once-Utility John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.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] Build several targets using cmake --build dir
Hello,
Thanks again.
In my case I cannot use your script. I have the constraint to be 'outside
cmake' so I do not know any of internal values like CMAKE_MAKE_PROGRAM. I can
only call 'cmake --build' to build stuff.
I filed a feature request : http://www.cmake.org/Bug/view.php?id=14014
Regards,
Gregoire
From: J Decker [mailto:d3c...@gmail.com]
Sent: vendredi 15 mars 2013 12:45
To: Gregoire Aujay
Cc: Nick Overdijk; John Drescher; cmake@cmake.org
Subject: Re: [CMake] Build several targets using cmake --build dir
My ugly macro looks like... Build project macro creates targets
'build${PROJECT}' which can be depended on each other...
It writes to a output batch file, and then calls that batch. The batch file
contains a cmake execution for that target, and then ${CMAKE_MAKE_PROGRAM}
command.
---
macro( BuildProject PROJECT SOLUTION PROJECT_SOURCE INSTALL_RESULT )
set( LAST_TARGET Build${PROJECT} )
if( CMAKE_BINARY_DIR MATCHES ${CMAKE_BUILD_TYPE}_solution\$ )
set( INSTALL ${CMAKE_BINARY_DIR}/../${CMAKE_BUILD_TYPE}_out/${PROJECT} )
set( BUILD ${CMAKE_BINARY_DIR}/../${CMAKE_BUILD_TYPE}_solution/${PROJECT} )
else()
set( INSTALL ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}_out/${PROJECT} )
set( BUILD ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}_solution/${PROJECT} )
endif( CMAKE_BINARY_DIR MATCHES ${CMAKE_BUILD_TYPE}_solution\$ )
set( ${INSTALL_RESULT} ${INSTALL} )
FILE( MAKE_DIRECTORY ${BUILD} )
if( MSVC )
if( NOT EXISTS ${BUILD}/${SOLUTION}.sln )
FILE( WRITE ${BUILD}/${SOLUTION}.sln )
endif()
if( ${CMAKE_MAKE_PROGRAM} MATCHES .*[Mm][Ss][Bb]uild.* )
build_command( BUILD_COMMAND CONFIGURATION ${CMAKE_BUILD_TYPE}
PROJECT_NAME ${SOLUTION} TARGET INSTALL )
SET( MORE_ARGS /m:4 /v:m )
else()
build_command( BUILD_COMMAND CONFIGURATION ${CMAKE_BUILD_TYPE}
PROJECT_NAME ${SOLUTION} TARGET INSTALL.vcxproj )
endif()
SEPARATE_ARGUMENTS( BUILD_COMMAND WINDOWS_COMMAND ${BUILD_COMMAND} )
SET( BUILD_COMMAND ${BUILD_COMMAND} ${MORE_ARGS} )
SET( ADD_SOURCES SOURCES ${BUILD}/${SOLUTION}.sln )
else( MSVC )
build_command( BUILD_COMMAND CONFIGURATION ${CMAKE_BUILD_TYPE} PROJECT_NAME
${SOLUTION} TARGET install )
SEPARATE_ARGUMENTS( BUILD_COMMAND UNIX_COMMAND ${BUILD_COMMAND} )
endif( MSVC )
if( CMAKE_TOOLCHAIN_FILE )
set( TOOLCHAIN -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} )
endif( CMAKE_TOOLCHAIN_FILE )
set( FAKE_ARGN1 ${ARGN})
string (REPLACE ; FAKE_ARGN2 ${FAKE_ARGN1})
FILE( WRITE ${BUILD}/makeit.bat \${CMAKE_COMMAND}\ -G
\${CMAKE_GENERATOR}\ ${TOOLCHAIN} \${PROJECT_SOURCE}\
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${INSTALL}
${FAKE_ARGN2}\n )
string (REPLACE ; FAKE_BUILD_COMMAND ${BUILD_COMMAND})
FILE( APPEND ${BUILD}/makeit.bat ${FAKE_BUILD_COMMAND} )
add_custom_target( Build${PROJECT} ALL
COMMAND makeit.bat
WORKING_DIRECTORY ${BUILD}
${ADD_SOURCES}
)
endmacro( BuildProject )
-
usage is something like
set( PROJECT intershell )
set( EXTRA_FLAGS -DSACK_SDK_ROOT_PATH=${SACK_SDK_ROOT_PATH} )
BuildProject( ${PROJECT} ${PROJECT} ${CMAKE_CURRENT_LIST_DIR}/../src/InterShell
INTERSHELL_SDK_ROOT_PATH ${EXTRA_FLAGS} )
Add_custom_command( TARGET Build${PROJECT}
COMMAND
${INTERSHELL_SDK_ROOT_PATH}/intershell_deploy${CMAKE_EXECUTABLE_SUFFIX} -nr
WORKING_DIRECTORY ${INTERSHELL_SDK_ROOT_PATH}
)
add_dependencies( ${LAST_TARGET} Buildcore )
-
Above sourced from
https://code.google.com/p/c-system-abstraction-component-gui/source/browse/cmake_all/CMakeLists.txt
and
https://code.google.com/p/c-system-abstraction-component-gui/source/browse/cmake_all/CMakeBuild.txt
On Fri, Mar 15, 2013 at 4:37 AM, J Decker
d3c...@gmail.commailto:d3c...@gmail.com wrote:
If the dependencies are already satisfied, and the cmake_make_program can run
mutliple in parallel, then it works great.
I have a cmake script that builds other cmake top level projects; and this ends
up building in parallel on visual studio.
can't do it with any other compiler I use for windows (make can be aliased on
linux to include a /j4).
On Fri, Mar 15, 2013 at 1:37 AM, Gregoire Aujay
gau...@movea.commailto:gau...@movea.com wrote:
Hello,
Thanks for your replies. I understand that I can only 'cmake --build' one
target at a time.
I think that the solutions you propose do not benefit from tools, like ninja,
that have parallel build capabilities.
I'll file a feature request.
Regards,
Greg
-Original Message-
From: Nick Overdijk [mailto:n...@astrant.netmailto:n...@astrant.net]
Sent: jeudi 14 mars 2013 19:10
To: John Drescher
Cc: Gregoire Aujay; cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] Build several targets using cmake --build dir
You can only 'cmake' a single-target. If you want to have more targets, create
more directories
[CMake] Build several targets using cmake --build dir
Hello, I use cmake 2.8.10 on windows. I would like to build several targets with cmake --build dir so the underlying build tool to do parallel jobs. Currently it only seems to be possible to build one target at a time, using --target . (http://www.cmake.org/cmake/help/v2.8.10/cmake.html#opt:--builddir) Can someone tell me how I could achieve that with current cmake version? Regards, Greg -- 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] LINK_PRIVATE and install(EXPORT behavior
Hello, I am using cmake 2.8.10.2 on windows. I want a library A to link to a 3rdParty library B. I thought that using LINK_PRIVATE version of the target_link_libraries function should avoid B to be in the link interface of A. But if I export A, B's full path is in IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG. I know that if I declare B as an imported library I will not have B's full path in IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG but only B which might be ok. But still I think that the PRIVATE_LINK should totally remove B from A's link interface. Is this the correct behavior? Regards, Gregoire -- 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] install(EXPORT ...) behavior for multi-configuration generators
Hello,
I am using CMake 2.8.10.2, on windows.
I am trying to use install(TARGETS ) and install(EXPORT ) both with NMake
makefiles and with the multi-configuration generator Visual studio.
I cannot get the same behavior when I want my binaries to be installed in a
subfolder that depends on the configuration, e.g. :
- Debug/bin/myLib.dll
- Release/bin/myLib.dll
If I do that :
#start
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION \${CMAKE_INSTALL_CONFIG_NAME}/lib
LIBRARY DESTINATION\${CMAKE_INSTALL_CONFIG_NAME}/lib
RUNTIME DESTINATION \${CMAKE_INSTALL_CONFIG_NAME}/bin
)
install(EXPORT myTargets DESTINATION cmake)
#end
This works find for NMake and Visual for install rules because
${CMAKE_INSTALL_CONFIG_NAME} will be evaluated at install time.
But in my myTargets-debug.cmake import files, ${CMAKE_INSTALL_CONFIG_NAME} will
not be evaluated correctly.
Now If I do that:
#start
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION Debug/lib
LIBRARY DESTINATIONDebug/lib
RUNTIME DESTINATION Debug/bin
CONFIGURATIONS Debug
)
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION Release/lib
LIBRARY DESTINATIONRelease/lib
RUNTIME DESTINATION Release/bin
CONFIGURATIONS Release
)
install(EXPORT myTargets DESTINATION cmake)
# end
CMake will complain that:
CMake Error: INSTALL(EXPORT myTargets ...) includes target myLib more
than once in the export set.
Is this a bug that CMake complains about a target being exported twice but with
different configurations?
Does anyone have a workaround?
Regards,
Gregoire
--
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] Bug fix requests for the *next* release of CMake...
http://www.cmake.org/Bug/view.php?id=13643 Fix is included in the issue but I do not know we could easily add a test. Regards, Gregoire -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of David Cole Sent: mercredi 7 novembre 2012 20:41 To: cmake; CMake Developers Subject: [CMake] Bug fix requests for the *next* release of CMake... Hi all, Replies requested. Short replies only. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Example one-line reply: http://public.kitware.com/Bug/view.php?id=13571 Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. We are aiming for approximately quarterly releases from now on, scheduling them every 3 to 4 months. The next release of CMake will likely be version 2.8.11, scheduled to have an rc1 release candidate on Wed. January 9, 2013 -- just 9 weeks from today. If you have a particular issue that you think should be fixed for inclusion in 2.8.11, please bring it up within the next two weeks. Ideally, each issue will be discussed as needed on the mailing list to come to any consensus about what should be done to fix it, and then an entry in the bug tracker may be used to keep it on the radar screen, and to track activity related to it. You can see what's already on the roadmap for this release here: http://public.kitware.com/Bug/roadmap_page.php?version_id=103 Patches are always welcome. Patches that include testing of any new features, or tests that prove a bug is really fixed on the dashboards, (basically any patch with testing) is preferred over a patch with no testing. Also, if you are *adding* code, then you also probably need to add *tests* of that code, so that the coverage percentage stays as is or rises. Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur in the near future. Thanks, David Cole Kitware, Inc. P.S. - as a nice summary of what we accomplished in the CMake 2.8.10 release, see here: http://public.kitware.com/Bug/changelog_page.php?version_id=100 -- it currently lists 58 issues that we resolved: nice job, everybody! (Many of those were specifically addressed because somebody asked for it right here on the mailing list... Don't be shy!) -- 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] GenerateExportHeader for module library
Hello,
I filed a bug: http://www.cmake.org/Bug/view.php?id=13643
Regards,
Gregoire
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Clinton Stimpson
Sent: jeudi 1 novembre 2012 15:05
To: Stephen Kelly
Cc: cmake@cmake.org
Subject: Re: [CMake] GenerateExportHeader for module library
On Nov 1, 2012, at 8:01 AM, Stephen Kelly wrote:
Gregoire Aujay wrote:
Hello,
I am doing my tests with visual 2008 and mingw.
As far as I understand a module is like a shared library that cannot
be linked. Instead it is dynamically loaded and then we find and use
symbols in it. It is like doing the linker's job manually at runtime.
If nothing is exported from my module then I do cannot find any
symbol in it. Or at least I do not know how to do so.
I modified the GenerateExportHeader module to be able to export
symbols from my MODULE:
# if(${type} STREQUAL MODULE)
# message(WARNING This macro should not be used with libraries of
# type MODULE) return()
# endif()
if(NOT ${type} STREQUAL STATIC_LIBRARY AND NOT ${type} STREQUAL
SHARED_LIBRARY AND NOT ${type} STREQUAL MODULE_LIBRARY)
message(WARNING This macro can only be used with libraries)
return()
endif()
Regards,
Gregoire
Please file a bug report so that this is not forgotten.
Ideally also provide some code to test it. I'm not familiar with how
plugins should be loaded in a cross-platform way (without Qt, that is).
Perhaps the BundleUtilities test can be modified to use GenerateExportHeader if
you need some coverage.
It also loads plugins at runtime (without Qt).
Clint
--
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] GenerateExportHeader for module library
Hello, I want to create a module with two symbols exported with visual: startPlugin stopPlugin I wish I could use the convenient GENERATE_EXPORT_HEADER function to do so. Is there any reason why the GENERATE_EXPORT_HEADER function is disabled for the MODULE library type ? Thanks, Gregoire -- 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] GenerateExportHeader for module library
Hello,
I am doing my tests with visual 2008 and mingw.
As far as I understand a module is like a shared library that cannot be linked.
Instead it is dynamically loaded and then we find and use symbols in it. It is
like doing the linker's job manually at runtime.
If nothing is exported from my module then I do cannot find any symbol in it.
Or at least I do not know how to do so.
I modified the GenerateExportHeader module to be able to export symbols from my
MODULE:
# if(${type} STREQUAL MODULE)
# message(WARNING This macro should not be used with libraries of type
MODULE)
# return()
# endif()
if(NOT ${type} STREQUAL STATIC_LIBRARY AND NOT ${type} STREQUAL
SHARED_LIBRARY AND NOT ${type} STREQUAL MODULE_LIBRARY)
message(WARNING This macro can only be used with libraries)
return()
endif()
Regards,
Gregoire
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Stephen Kelly
Sent: vendredi 26 octobre 2012 17:45
To: cmake@cmake.org
Subject: Re: [CMake] GenerateExportHeader for module library
Gregoire Aujay wrote:
Hello,
I want to create a module with two symbols exported with visual:
startPlugin
stopPlugin
I wish I could use the convenient GENERATE_EXPORT_HEADER function to
do so. Is there any reason why the GENERATE_EXPORT_HEADER function is
disabled for the MODULE library type ?
When I wrote GenerateExportHeader, I didn't know of any reason to link to a
MODULE. I thought MODULEs were always plugins to be loaded at runtime?
What does 'two symbols exported with visual' mean?
Thanks,
Steve.
--
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
