Re: [CMake] Shared library from sources in several subdirectories

On 12/07/2015 11:51 PM, Bruce Stephens wrote: On Mon, Dec 7, 2015 at 9:08 AM, Nils Gladitz > wrote: I would avoid creating these single use, per directory libraries entirely. Well, creating the static libraries is obviously just

[CMake] CPack Uninstalling locked files

Hi, In CPack NSIS template I came across a variable CPACK_NSIS_DELETE_FILES. When the NSIS script is generated, this variable is expanded to "nsis delete commands" for all the cmake install commands. The proble with this is, if the file is locked it will not be deleted. To overcome this NSIS has

Re: [cmake-developers] Static Bootstrap: CCMake & GPM

Hello Axel, On 08/12/15 01:53, Huebl, Axel wrote: My problem: I found that in the last step of linking ccmake against a static (pre-compiled, ubuntu 12.04) ncurses library leads to linker errors such as: /usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function `_nc_mouse_event':

[cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree

Dear All, In our software infrastructure I now got to the point that in building "high level" packages/projects the CMake build spends a very noticeable amount of time in calculating the dependencies of source files. To give you a feel of the issue, in one example that I was profiling, I build

Re: [CMake] Fixed ProjectGUID

Taking a look at the CMakeCache.txt offers the missing ${target_name}_GUID_CMAKE variable. Thus set_property(CACHE ${target_name}_GUID_CMAKE PROPERTY VALUE ${MY_GUID} ) seems to work. But how do I get the actual GUID set by CMake? This one was stored in CMakeCache.txt before. But right

[CMake] Fixed ProjectGUID

Hello I just installed 3.4.1 and the usage of a hardcoded guid does not seem to work anymore: set_property(CACHE ${target_name}_GUID_CMAKE PROPERTY VALUE ${MY_GUID} ) Is thre another way to set the project GUID? best regards SirAnn Original-Nachricht /Datum: Fri, 7

Re: [CMake] Fixed ProjectGUID

On 12/08/2015 12:06 PM, Dr. Sören Textor wrote: Taking a look at the CMakeCache.txt offers the missing ${target_name}_GUID_CMAKE variable. Thus set_property(CACHE ${target_name}_GUID_CMAKE PROPERTY VALUE ${MY_GUID} ) seems to work. But how do I get the actual GUID set by CMake? This one

Re: [CMake] Fixed ProjectGUID

Yes, it seems that cmake does not store that ID as befere. Thus I just create my own UUID ;-) String( UUID ...) Am 08.12.2015 um 12:28 schrieb Nils Gladitz: On 12/08/2015 12:06 PM, Dr. Sören Textor wrote: Taking a look at the CMakeCache.txt offers the missing ${target_name}_GUID_CMAKE

Re: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree

On Tue, Dec 08, 2015 at 10:09:13 +0100, Attila Krasznahorkay wrote: > In the end I applied the following patch to CMake 3.4.1 locally to > speed it up for my use case very significantly. Of course this is not > a patch that could be applied to CMake for a general audience. But I > do think that if

[CMake] Idea: generic task-driven make-like targets with CMake

The one thing I’ve found I still have to replace with CMake is the ability to specify generic “make” targets that do various tasks, such as a release build using the same build directory, run tests, grab dependencies. For example, with Make I can do: release: mkdir -p build_dir cd

Re: [CMake] Idea: generic task-driven make-like targets with CMake

On 08.12.2015 19:04, Kevin Wojniak wrote: add_task(release COMMAND ${CMAKE_COMMAND} -E make_directory “build_dir” COMMAND ${CMAKE_COMMAND} -E chdir “build_dir” ${CMAKE_COMMAND} “-DCMAKE_BUILD_TYPE=Release”, “..” ) There is add_custom_target(). You can e.g.

Re: [CMake] Idea: generic task-driven make-like targets with CMake

Functionality like add_custom_target combined with script mode is close, but not quite there. add_custom_target already requires a build directory and a generator, so it’s too late. Script mode requires setting variables on the command line, so it’s too verbose. For example: if(“${ACTION}”

Re: [CMake] target_include_directories SYSTEM adds -isystem to Clang, but not GCC

Thank you Gregor! I have tried the Makefile generator, but on OS X -isystem still seems to be missing with GCC. The -isystem flag appears with Clang, however. I have installed CMake 3.4.1 and GCC 5.3.0, both through MacPorts. I can provide a sample project, if that would help. On Fri, Nov 20,

Re: [CMake] Idea: generic task-driven make-like targets with CMake

Kevin, I have a shell script for such tasks, see https://gist.github.com/tamaskenez/d4509f240f4224eb9853. Feel free to use it if that's what you need. It extends the `cmake` command by executing multiple, related `cmake` calls with one command. See docs in gist. Your 'make release' example looks

[cmake-developers] [CMake 0015874]: Add command line flag to force ctest to exit with non-zero code when no tests are run

The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15874 == Reported By:Kevin Wojniak Assigned To:

[Cmake-commits] CMake branch, master, updated. v3.4.1-653-g3a824a9

_VERSION_MINOR 4) -set(CMake_VERSION_PATCH 20151208) +set(CMake_VERSION_PATCH 20151209) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

[CMake] How to set _default_ timeout for the ctest command?

For the lapack CMake-based build and test system, some of the ctests can exceed 1500 seconds (the default limit) for special conditions (e.g, a quadruple-precision build of lapack that can be very slow). To reduce such issues without forcing users to use the ctest --timeout option, the lapack

Re: [cmake-developers] Please comment on ios-universal topic

Hello, On 02/12/15 13:44, Bartosz Kosiorek wrote: > I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS. My thoughts about the property name: I added the necessary functionality to also combine Frameworks and App Bundles. So the _LIBS suffix now got misleading. And I