Re: [CMake] Calling find_package(self) for in-project builds

Hello.8:34, 3 june 2016 г., Walter Gray :Interesting idea, that could be possible.Possible, but realy need? It can be alternative. Now we can use ALIASES for build tree configuration - It's work (I check)On Thu, Jun 2, 2016 at 8:45 PM Dan Liew wrote:> What would be the suggested way to handle this

Re: [CMake] Calling find_package(self) for in-project builds

Interesting idea, that could be possible. On Thu, Jun 2, 2016 at 8:45 PM Dan Liew wrote: > > What would be the suggested way to handle this? > > Couldn't you build the examples using CMake's ``ExternalProject`` > module [1] and have that build after the main project has finished > building? > >

Re: [CMake] Calling find_package(self) for in-project builds

> What would be the suggested way to handle this? Couldn't you build the examples using CMake's ``ExternalProject`` module [1] and have that build after the main project has finished building? [1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html -- Powered by www.kitware.com Pleas

Re: [CMake] Calling find_package(self) for in-project builds

That only gets me part way - there's also the issue of the options & extra functions defined in protobuf-config.in. My best guess ATM would be to do something simmilar and create namespaced aliases, then just not include the protobuf-targets.cmake file from protobuf-config.cmake if CMAKE_CURRENT_LI

Re: [CMake] execute short program during cmake configuration ?

On Jun 2, 2016, at 2:56 PM, Alan W. Irwin wrote: > It appears you want the Fortran equivalent of the CHECK_C_SOURCE_RUNS > macro. So I suggest you copy that macro (found in > Modules/CheckCSourceRuns.cmake) to your own source code where your > other home-grown CMake macros are located, rename tha

Re: [CMake] Calling find_package(self) for in-project builds

Although not ideal, you could alias the targets to the names they would have when imported with find_package() by using add_library(ALIAS), and then use if(TARGET) to conditionally call find_package(). This also is a step toward supporting using the library via add_subdirectory(), if that ever beco

[CMake] Calling find_package(self) for in-project builds

I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a bit of a chicken and egg problem. There is an examples directory containing a CMakeLists.txt which we would like to work as both a standalone examples directory and include as a sub directory of the full build. For obvious rea

Re: [CMake] execute short program during cmake configuration ?

On 2016-06-02 20:10- Ilias Miroslav wrote: Greetings, dear experts, we have (two) short Fortran programs (detection of integer*4/8 for math libraries) which we would like to build and execute during project's configuration phase. There is the " CheckFortranSourceCompiles" command to

Re: [CMake] execute short program during cmake configuration ?

It might be overkill for what you want, but this stack overflow question deals with a very similar situation. On Fri, Jun 3, 2016 at 6:10 AM, Ilias Miroslav wrote: > > Greetings, dear experts, > > > we have (two) short Fortran programs (detection of

[CMake] execute short program during cmake configuration ?

Greetings, dear experts, we have (two) short Fortran programs (detection of integer*4/8 for math libraries) which we would like to build and execute during project's configuration phase. There is the " CheckFortranSourceCompiles" command to compile a Fortran source code during project's c

Re: [CMake] add_custom_command, POST_BUILD

On Thu, Jun 2, 2016 at 2:43 PM, Chuck Atkins wrote: > Could you just make the tests run in the post-build of the test? > > add_library(Foo Foo.cxx) > > add_executable(FooTest FooTest.cxx) > target_link_libraries(FooTest Foo) > > add_custom_command(TARGET FooTest POST_BUILD > COMMAND $ $ > ) > >

Re: [CMake] add_custom_command, POST_BUILD

Could you just make the tests run in the post-build of the test? add_library(Foo Foo.cxx) add_executable(FooTest FooTest.cxx) target_link_libraries(FooTest Foo) add_custom_command(TARGET FooTest POST_BUILD COMMAND $ $ ) That way the the test is run as part of it's build. - Chuck On Wed, Ju

Re: [CMake] add_custom_command, POST_BUILD

Hi. The reason is to make build to fail as soon as possible if core library doesn't work properly. In C++ world that could be critical as hell because building process can last hours even on 32 cores. And it will make CMake more ecological tool as it will reduce the energy wasted. :) On Jun 1

Re: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

On 06/01/2016 04:54 PM, Chuck Atkins wrote: > Wow, so this is actually a pretty obscure find. You've definitely stumbled > across a bug. It has nothing to do with debug symbols and everything to do > with compiler identification. It seems that our binary strings parsing is > broken when "[anythi

Re: [CMake] MSYS Makefiles generator problem with install/strip

Cheers Hendrik, I'll try to use that approach. Thanx! Regards /R Skickat från min LG-Mobil -- Ursprungligt meddelande-- Från: Hendrik Sattler Datum: tors, 2 jun 2016 20:32 Till: Robert Bielik;cmake@cmake.org; Ämne:Re: [CMake] MSYS Makefiles generator problem with install/

Re: [CMake] MSYS Makefiles generator problem with install/strip

Hi, Am 2. Juni 2016 19:23:26 MESZ, schrieb Robert Bielik : >Hi Hendrik, > > > >I think I do, yes. Would this not be a normal use case, specifically on >Linux, where the bin library would be /usr/bin? How would that work >with relative paths? Installation is always relative to CMAKE_INSTALL_PREFIX

Re: [CMake] MSYS Makefiles generator problem with install/strip

Hi Hendrik, I think I do, yes. Would this not be a normal use case, specifically on Linux, where the bin library would be /usr/bin? How would that work with relative paths? I think it would be a bug if install cannot handle arbitrary paths. I'll try though to see if I can work around thi

Re: [CMake] MSYS Makefiles generator problem with install/strip

Hi, Are you using absolute paths in your install() commands? You better don't. HS Am 2. Juni 2016 16:25:33 MESZ, schrieb Robert Bielik : >Hi, > >I have a problem with the install/strip target not working when using >the MSYS Makefiles generator. I get the following result in >cmake_install.cmak

Re: [CMake] CPack with BZIP2 is a lot slower than GNU tar

On 6/2/2016 5:29 AM, Alessio wrote: I'm comparing the following two things: 1. cpack TBZ2 generator 2. "tar cjf" the same files as with cpack. (j option = BZIP2 compression) I cannot avoid CPack. It takes care of way too many little details of the packaging. Obviously we use it via lots of i

[CMake] MSYS Makefiles generator problem with install/strip

Hi, I have a problem with the install/strip target not working when using the MSYS Makefiles generator. I get the following result in cmake_install.cmake: file(INSTALL DESTINATION "c:/Dev/appAndroid/idrclib/src/main/jniLibs/armeabi-v7a" TYPE SHARED_LIBRARY FILES "C:/Dev/jniAndroid/libapi_nativ

Re: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

Renaming the folder did indeed fix it here. I tested with g++ and Clang, both work fine. This is on a different machine than I was posting from before, but it's also running Manjaro. I will test this on my main machine once I'm home, which will be be in six hours or so, and I'll let you know the

Re: [CMake] CPack with BZIP2 is a lot slower than GNU tar

I'm comparing the following two things: 1. cpack TBZ2 generator 2. "tar cjf" the same files as with cpack. (j option = BZIP2 compression) I cannot avoid CPack. It takes care of way too many little details of the packaging. Obviously we use it via lots of install() statements in our CMakeLists.