Re: [CMake] Can't open module file *.mod

[Juan E. Sanchez]

It has been several months since I looked at this.  I seem to remember 
setting dependencies between libraries containing modules, using 
something like target_link_libraries.  I think that cmake was capable of 
detecting dependencies between files in the same library.  I think it 
relied on the use of the USE statement.


I think

Regards,

Juan


On 2/5/19 8:29 PM, Petr Penzin wrote:
When I ran into the same issue, my workaround was to use file properties 
to set dependencies between files, but I don't think it is very robust 
solution. Would be curious to hear if there is a better way to do it.


Best,

Petr


On 2/5/19 2:55 PM, Guido Giuntoli wrote:

Hi I have a Fortran project with the following order

src/module_1.f90 (Fortran Modules)
src/module_2.f90
src/... (more files)

file(GLOB SOURCES src/*.f90)
add_executable(MyExec SOURCES)

module_1 depends on module_2 and when is compiling module_1.f90 I get 
the dependency error :


Fatal Error: Can't open module file ‘module_2.mod’ :for reading at 
(1):  No existe el fichero o el directorio (*The file does not exist*).


Thanks, Guido.






--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Can't open module file *.mod

[Petr Penzin]

When I ran into the same issue, my workaround was to use file properties 
to set dependencies between files, but I don't think it is very robust 
solution. Would be curious to hear if there is a better way to do it.


Best,

Petr


On 2/5/19 2:55 PM, Guido Giuntoli wrote:

Hi I have a Fortran project with the following order

src/module_1.f90 (Fortran Modules)
src/module_2.f90
src/... (more files)

file(GLOB SOURCES src/*.f90)
add_executable(MyExec SOURCES)

module_1 depends on module_2 and when is compiling module_1.f90 I get 
the dependency error :


Fatal Error: Can't open module file ‘module_2.mod’ :for reading at 
(1):  No existe el fichero o el directorio (*The file does not exist*).


Thanks, Guido.


-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Can't open module file *.mod

[Guido Giuntoli]

Hi I have a Fortran project with the following order

src/module_1.f90 (Fortran Modules)
src/module_2.f90
src/... (more files)

file(GLOB SOURCES src/*.f90)
add_executable(MyExec SOURCES)

module_1 depends on module_2 and when is compiling module_1.f90 I get the
dependency error :

Fatal Error: Can't open module file ‘module_2.mod’ :for reading at (1):  No
existe el fichero o el directorio (*The file does not exist*).

Thanks, Guido.
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

[Juan Sanchez]

Hello,

Are you able to use BUILD_WITH_INSTALL_RPATH:
https://cmake.org/cmake/help/v3.13/prop_tgt/BUILD_WITH_INSTALL_RPATH.html
https://cmake.org/cmake/help/v3.13/prop_tgt/INSTALL_RPATH.html#prop_tgt:INSTALL_RPATH

Regards,

Juan


On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake 
wrote:

> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when
> installing/packaging, and our packages continue to work fine on OS X 10.12.
> My question is about what to do with executables before packaging, while
> they are still just in the build tree. We need them to work for purposes of
> testing via CTest.
>
> Adam
>
>
> On 2/5/19, 2:56 PM, "Robert Maynard"  wrote:
>
> My general approach for the second problem is to run a tool such as
> install_name_tool to change the library names to have @rpath when
> constructing the package.
>
> On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>  wrote:
> >
> > Hello,
> >
> >
> >
> > The project I work on links to several shared boost libraries. After
> our organization disallowed use of OS X 10.11 and we upgraded our
> built/test slave to 10.12, we encountered a problem with our testing.
> Executables in the build tree that were built as part of our project now
> fail to run with the error that boost libraries can’t be found.
> >
> >
> >
> > Superficially, the problem is that (I think) Apple strengthened the
> SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any
> effect – previously the linker was able to locate the boost libs for our
> build tree executables that way.
> >
> >
> >
> > The deeper problem is twofold: First, the build tree executables
> don’t include the boost lib folder in their RPATHs. Second, the install
> names embedded in boost libs themselves are just the bare filenames with no
> @rpath. (My understanding is, the boost project does that deliberately
> because they can’t know what users of their libraries will want.)
> >
> >
> >
> > Recent versions of CMake (3.8+) have the property BUILD_RPATH that
> we could use to embed the path to the boost libs into the build tree
> executables. That doesn’t solve the second part of the problem, though.
> Without embedding install names that look like @rpath/libboost_foo.dylib in
> the build tree executables, I think the linker will still be unable to find
> them.
> >
> >
> >
> > What is the best (or least bad) way to fix this?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Adam
> >
> >
> >
> > --
> >
> > J. Adam Stephens, Ph.D.
> >
> > Dakota Support Analyst
> >
> > https://dakota.sandia.gov/
> >
> > Optimization and UQ
> >
> > Sandia National Laboratories
> >
> > Albuquerque, NM
> >
> >
> >
> > --
> >
> > 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:
> > https://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:
> https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

[Craig Scott]

I don't know if it is an option in your case, but you could build boost
yourself as static libraries. Then the whole build/install rpath situation
goes away. In case it is helpful, I recently gave an example of how I'm
currently doing this with a FetchContent-based solution. It won't suit
everyone, but the approach might be relevant for your particular case.

https://gitlab.kitware.com/cmake/cmake/issues/18831#note_509194


On Wed, Feb 6, 2019 at 9:00 AM Stephens, J. Adam via CMake 
wrote:

> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when
> installing/packaging, and our packages continue to work fine on OS X 10.12.
> My question is about what to do with executables before packaging, while
> they are still just in the build tree. We need them to work for purposes of
> testing via CTest.
>
> Adam
>
>
> On 2/5/19, 2:56 PM, "Robert Maynard"  wrote:
>
> My general approach for the second problem is to run a tool such as
> install_name_tool to change the library names to have @rpath when
> constructing the package.
>
> On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>  wrote:
> >
> > Hello,
> >
> >
> >
> > The project I work on links to several shared boost libraries. After
> our organization disallowed use of OS X 10.11 and we upgraded our
> built/test slave to 10.12, we encountered a problem with our testing.
> Executables in the build tree that were built as part of our project now
> fail to run with the error that boost libraries can’t be found.
> >
> >
> >
> > Superficially, the problem is that (I think) Apple strengthened the
> SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any
> effect – previously the linker was able to locate the boost libs for our
> build tree executables that way.
> >
> >
> >
> > The deeper problem is twofold: First, the build tree executables
> don’t include the boost lib folder in their RPATHs. Second, the install
> names embedded in boost libs themselves are just the bare filenames with no
> @rpath. (My understanding is, the boost project does that deliberately
> because they can’t know what users of their libraries will want.)
> >
> >
> >
> > Recent versions of CMake (3.8+) have the property BUILD_RPATH that
> we could use to embed the path to the boost libs into the build tree
> executables. That doesn’t solve the second part of the problem, though.
> Without embedding install names that look like @rpath/libboost_foo.dylib in
> the build tree executables, I think the linker will still be unable to find
> them.
> >
> >
> >
> > What is the best (or least bad) way to fix this?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Adam
> >
> >
> >
> > --
> >
> > J. Adam Stephens, Ph.D.
> >
> > Dakota Support Analyst
> >
> > https://dakota.sandia.gov/
> >
> > Optimization and UQ
> >
> > Sandia National Laboratories
> >
> > Albuquerque, NM
>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake with vscode

[Robert Maynard via CMake]

CMAKE_FIND_ROOT_PATH isn't meant to be used like that, you should use
CMAKE_PREFIX_PATH I expect.

ROOT_PATH represents the root of a new file-system/OS basically and is
meant for cross-compilation. While what you want is extra directories
to start searching from which is what CMAKE_PREFIX_PATH is designed
for.

On Tue, Jan 22, 2019 at 8:51 AM Stéphane Ancelot
 wrote:
>
> Hi,
>
> I have got some problems finding packages under windows platform.
>
> I made a toolchain for VSCode and cmake 3.13 , but I don't understand why it 
> fails to find almost all of my packages dependencies
>
> It is not able to find packages in the CMAKE_FIND_ROOT_PATH itself.
>
> If I try setting xx_LIBRARY and xx_INCLUDE_DIRS, if finds libs,  but this 
> does not sound the right Way .
>
>
> Here is my toolchain :
>
> # the name of the target operating system
> SET(CMAKE_SYSTEM_NAME Windows)
>
> message(STATUS "bin dir ${CMAKE_BINARY_DIR}")
>
> # here is the target environment located
> SET(CMAKE_FIND_ROOT_PATH
> 
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\xerces\\xerces-c-3.1.1-bin
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\JPEGLIB\\jpegsrc-9c
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\zlib-1.2.3-lib
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\libpng-1.2.37-lib
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\freetype-dev_2.4.2-1
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\iconv-1.9.2.1
> ${CMAKE_BINARY_DIR}\\WIN32DEPS\\Python26
> E:\\Qt\\5.9.5
> )
>
> # cmake 3.13
> set(FREETYPE_LIBRARY E:\\freetype-windows-binaries-master\\lib)
> set(FREETYPE_INCLUDE_DIRS E:\\freetype-windows-binaries-master\\include)
>
> set(FTGL_LIBRARY ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary\\lib)
> set(FTGL_INCLUDE_DIRS ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary\\include)
>
>
>
> --
>
> 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:
> https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] [SPAM] Re: resource installation

[Robert Maynard via CMake]

If you add 'OUTPUT_VARIABLE' and 'ERROR_VARIABLE' information to the
execute_process call you should be able to dump the information using
'message' and see if the execute_process is running.


On Tue, Jan 29, 2019 at 3:04 PM Rob Boehne  wrote:
>
> I’m still not getting this script executed.  I can copy the “message” output 
> and run it – and it does what I want, and I see it in cmake_install.cmake – 
> the message() and execute_process() calls are inside of identical 
> conditionals, but there’s no indication that it is executing, or that there 
> was any sort of problem.
>
> How do I get it to actually execute?
>
>
>
> In cmake_install.cmake:
>
>
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT 
> CMAKE_INSTALL_COMPONENT)
>
>   message("running 
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 
> Release")
>
> endif()
>
>
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT 
> CMAKE_INSTALL_COMPONENT)
>
>   execute_process(COMMAND 
> "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 
> Release")
>
> endif()
>
>
>
>
>
> From: CMake  on behalf of Rob Boehne 
> 
> Date: Thursday, January 24, 2019 at 9:49 AM
> To: "cmake@cmake.org" 
> Subject: [SPAM] Re: [CMake] resource installation
>
>
>
> Maybe because I misspelled it?  Yes.  Because I misspelled the script name.
>
>
>
> From: CMake  on behalf of Rob Boehne 
> 
> Date: Thursday, January 24, 2019 at 9:40 AM
> To: "cmake@cmake.org" 
> Subject: [SPAM] [CMake] resource installation
>
>
>
> All,
>
>
>
> I’m attempting to install resource files (Fonts, etc.) into my product.  To 
> that end, I have added this chunk of code to run a batch file that will copy 
> resources into the tree:
>
>
>
> if(WIN32)
>
> #
>
> # run the script to install the resources
>
> #
>
> install(CODE "message(\"running 
> ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} 
> ${CMAKE_BUILD_TYPE}\")")
>
> install(CODE "execute_process(COMMAND 
> \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} 
> ${CMAKE_BUILD_TYPE}\")")
>
> endif()
>
>
>
> I see the output of the first line when I run the INSTALL target in VS 2013, 
> but it seems as though the script isn’t run.
>
> 1>  -- Install configuration: "RelWithDebInfo"
>
> 1>  running 
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 
> Release
>
> 1>  -- Installing: 
> C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib
>
>
>
> So the message is there, but the script isn’t run.
>
>
>
> I’m I missing a dependency, or formatting the string incorrectly?  How do I 
> debug this?
>
>
>
> Thanks,
>
>
>
> Rob
>
>
>
>
>
> Rob Boehne
>
> Senior Software Architect | Datalogics, Inc.
>
> +1.312.853.8351 | r...@datalogics.com
>
> datalogics.com | blogs.datalogics.com
>
> Connect with us: Facebook | Twitter | LinkedIn | YouTube
>
>
>
>
>
> --
>
> 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:
> https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

[Robert Maynard via CMake]

The version of the libraries that you load from your build directory
would need to be fixed up to.

On Tue, Feb 5, 2019 at 5:00 PM Stephens, J. Adam  wrote:
>
> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when 
> installing/packaging, and our packages continue to work fine on OS X 10.12. 
> My question is about what to do with executables before packaging, while they 
> are still just in the build tree. We need them to work for purposes of 
> testing via CTest.
>
> Adam
>
>
> On 2/5/19, 2:56 PM, "Robert Maynard"  wrote:
>
> My general approach for the second problem is to run a tool such as
> install_name_tool to change the library names to have @rpath when
> constructing the package.
>
> On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>  wrote:
> >
> > Hello,
> >
> >
> >
> > The project I work on links to several shared boost libraries. After 
> our organization disallowed use of OS X 10.11 and we upgraded our built/test 
> slave to 10.12, we encountered a problem with our testing. Executables in the 
> build tree that were built as part of our project now fail to run with the 
> error that boost libraries can’t be found.
> >
> >
> >
> > Superficially, the problem is that (I think) Apple strengthened the SIP 
> between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect – 
> previously the linker was able to locate the boost libs for our build tree 
> executables that way.
> >
> >
> >
> > The deeper problem is twofold: First, the build tree executables don’t 
> include the boost lib folder in their RPATHs. Second, the install names 
> embedded in boost libs themselves are just the bare filenames with no @rpath. 
> (My understanding is, the boost project does that deliberately because they 
> can’t know what users of their libraries will want.)
> >
> >
> >
> > Recent versions of CMake (3.8+) have the property BUILD_RPATH that we 
> could use to embed the path to the boost libs into the build tree 
> executables. That doesn’t solve the second part of the problem, though. 
> Without embedding install names that look like @rpath/libboost_foo.dylib in 
> the build tree executables, I think the linker will still be unable to find 
> them.
> >
> >
> >
> > What is the best (or least bad) way to fix this?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Adam
> >
> >
> >
> > --
> >
> > J. Adam Stephens, Ph.D.
> >
> > Dakota Support Analyst
> >
> > https://dakota.sandia.gov/
> >
> > Optimization and UQ
> >
> > Sandia National Laboratories
> >
> > Albuquerque, NM
> >
> >
> >
> > --
> >
> > 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:
> > https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

[Stephens, J. Adam via CMake]

Hi Robert,

Thanks for your reply. We do use install_name_tool and the like when 
installing/packaging, and our packages continue to work fine on OS X 10.12. My 
question is about what to do with executables before packaging, while they are 
still just in the build tree. We need them to work for purposes of testing via 
CTest.

Adam
 

On 2/5/19, 2:56 PM, "Robert Maynard"  wrote:

My general approach for the second problem is to run a tool such as
install_name_tool to change the library names to have @rpath when
constructing the package.

On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
 wrote:
>
> Hello,
>
>
>
> The project I work on links to several shared boost libraries. After our 
organization disallowed use of OS X 10.11 and we upgraded our built/test slave 
to 10.12, we encountered a problem with our testing. Executables in the build 
tree that were built as part of our project now fail to run with the error that 
boost libraries can’t be found.
>
>
>
> Superficially, the problem is that (I think) Apple strengthened the SIP 
between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect – 
previously the linker was able to locate the boost libs for our build tree 
executables that way.
>
>
>
> The deeper problem is twofold: First, the build tree executables don’t 
include the boost lib folder in their RPATHs. Second, the install names 
embedded in boost libs themselves are just the bare filenames with no @rpath. 
(My understanding is, the boost project does that deliberately because they 
can’t know what users of their libraries will want.)
>
>
>
> Recent versions of CMake (3.8+) have the property BUILD_RPATH that we 
could use to embed the path to the boost libs into the build tree executables. 
That doesn’t solve the second part of the problem, though. Without embedding 
install names that look like @rpath/libboost_foo.dylib in the build tree 
executables, I think the linker will still be unable to find them.
>
>
>
> What is the best (or least bad) way to fix this?
>
>
>
> Thanks!
>
>
>
> Adam
>
>
>
> --
>
> J. Adam Stephens, Ph.D.
>
> Dakota Support Analyst
>
> https://dakota.sandia.gov/
>
> Optimization and UQ
>
> Sandia National Laboratories
>
> Albuquerque, NM
>
>
>
> --
>
> 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:
> https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking to boost on OS X 10.12

[Robert Maynard via CMake]

My general approach for the second problem is to run a tool such as
install_name_tool to change the library names to have @rpath when
constructing the package.

On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
 wrote:
>
> Hello,
>
>
>
> The project I work on links to several shared boost libraries. After our 
> organization disallowed use of OS X 10.11 and we upgraded our built/test 
> slave to 10.12, we encountered a problem with our testing. Executables in the 
> build tree that were built as part of our project now fail to run with the 
> error that boost libraries can’t be found.
>
>
>
> Superficially, the problem is that (I think) Apple strengthened the SIP 
> between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect – 
> previously the linker was able to locate the boost libs for our build tree 
> executables that way.
>
>
>
> The deeper problem is twofold: First, the build tree executables don’t 
> include the boost lib folder in their RPATHs. Second, the install names 
> embedded in boost libs themselves are just the bare filenames with no @rpath. 
> (My understanding is, the boost project does that deliberately because they 
> can’t know what users of their libraries will want.)
>
>
>
> Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could 
> use to embed the path to the boost libs into the build tree executables. That 
> doesn’t solve the second part of the problem, though. Without embedding 
> install names that look like @rpath/libboost_foo.dylib in the build tree 
> executables, I think the linker will still be unable to find them.
>
>
>
> What is the best (or least bad) way to fix this?
>
>
>
> Thanks!
>
>
>
> Adam
>
>
>
> --
>
> J. Adam Stephens, Ph.D.
>
> Dakota Support Analyst
>
> https://dakota.sandia.gov/
>
> Optimization and UQ
>
> Sandia National Laboratories
>
> Albuquerque, NM
>
>
>
> --
>
> 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:
> https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] patches for MirOS

[Robert Maynard via CMake]

As a general policy CMake doesn't offer patch releases of older
versions, and instead recommends updating to the latest CMake version.


On Sun, Feb 3, 2019 at 10:21 PM Andrew Pennebaker
 wrote:
>
> Hiya!
>
> I got cmake to build in MirOS (also known as MirBSD) v10 this weekend, 
> painting over gaps in POSIX support. Here's my patchset:
>
> https://github.com/mcandre/vagrant-miros-cmake/tree/master/i386
>
> Virtual machines are included for testing the patched build, and for testing 
> the final cmake binary.
>
> Note, this patchset targets cmake v3.9.0-. That's the first version I 
> happened to snag that doesn't depend on C++11 support. Evidently MirOS's 
> standard compiler, mgcc, has not offered C++11 support since it was released 
> way back during the 2008 financial crisis (!)
>
> Could we add these fixes to the 3.9 series so that MirOS users get better 
> access to cmake?
>
> --
> Cheers,
> Andrew
> --
>
> 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:
> https://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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Linking to boost on OS X 10.12

[Stephens, J. Adam via CMake]

Hello,

The project I work on links to several shared boost libraries. After our 
organization disallowed use of OS X 10.11 and we upgraded our built/test slave 
to 10.12, we encountered a problem with our testing. Executables in the build 
tree that were built as part of our project now fail to run with the error that 
boost libraries can’t be found.

Superficially, the problem is that (I think) Apple strengthened the SIP between 
10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect – 
previously the linker was able to locate the boost libs for our build tree 
executables that way.

The deeper problem is twofold: First, the build tree executables don’t include 
the boost lib folder in their RPATHs. Second, the install names embedded in 
boost libs themselves are just the bare filenames with no @rpath. (My 
understanding is, the boost project does that deliberately because they can’t 
know what users of their libraries will want.)

Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could use 
to embed the path to the boost libs into the build tree executables. That 
doesn’t solve the second part of the problem, though. Without embedding install 
names that look like @rpath/libboost_foo.dylib in the build tree executables, I 
think the linker will still be unable to find them.

What is the best (or least bad) way to fix this?

Thanks!

Adam

--
J. Adam Stephens, Ph.D.
Dakota Support Analyst
https://dakota.sandia.gov/
Optimization and UQ
Sandia National Laboratories
Albuquerque, NM

-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] --warn-uninitialized works in only first configuration

[frodak17]

When you run `cmake --build Build` it doesn't run cmake with the
--warn-uninitialized
if the build files need to be regenerated.  Therefore you don't get the
warnings.

On Tue, Feb 5, 2019 at 12:15 PM Ramold, Felix  wrote:

> It is not a cache variable. Here is an example:
>
> cmake_minimum_required(VERSION 3.10)
> project(TEST_UNINITIALIZED)
>
> file(WRITE dummy.cpp "")
> add_library(dummy dummy.cpp ${UNINITIALIZED})
>
> Also UNINITIALIZED is not added to CMakeCache.txt.
> Calling cmake twice (even without a change to the list) also shows this
> warning.
>
> -Ursprüngliche Nachricht-
> Von: Robert Maynard [mailto:robert.mayn...@kitware.com]
> Gesendet: Montag, 4. Februar 2019 18:16
> An: Ramold, Felix
> Cc: cmake@cmake.org
> Betreff: Re: [CMake] --warn-uninitialized works in only first configuration
>
> This generally occurs with CACHE variables as for non first runs they
> exist in the cache and therefore are initialized.
>
> On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix 
> wrote:
> >
> > Hi,
> >
> >
> >
> > I configure a project with --warn-uninitialized and get a lot of
> warnings. I successfully run the build.
> >
> > Then I change any CMakeLists.txt file. I run the build again. CMake
> checks its dependencies and reconfigures before the actual build.
> >
> > Those warnings (or at least those in the edited file) don’t appear again.
> >
> > Is this the standard behavior?
> >
> >
> >
> > Thanks,
> >
> > Felix
> >
> > --
> >
> > 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:
> > https://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:
> https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] --warn-uninitialized works in only first configuration

[Robert Maynard via CMake]

Okay now I understand.

Yes this is the intended behavior of `--warn-uninitialized`.

It is designed so that it will only generate warnings for the explicit
invocation of cmake that includes the flag. Subsequent calls to
`cmake` without `--warn-uninitialized` will generate no warnings.

On Tue, Feb 5, 2019 at 12:08 PM Ramold, Felix  wrote:
>
> It is not a cache variable. Here is an example:
>
> cmake_minimum_required(VERSION 3.10)
> project(TEST_UNINITIALIZED)
>
> file(WRITE dummy.cpp "")
> add_library(dummy dummy.cpp ${UNINITIALIZED})
>
> Also UNINITIALIZED is not added to CMakeCache.txt.
> Calling cmake twice (even without a change to the list) also shows this 
> warning.
>
> -Ursprüngliche Nachricht-
> Von: Robert Maynard [mailto:robert.mayn...@kitware.com]
> Gesendet: Montag, 4. Februar 2019 18:16
> An: Ramold, Felix
> Cc: cmake@cmake.org
> Betreff: Re: [CMake] --warn-uninitialized works in only first configuration
>
> This generally occurs with CACHE variables as for non first runs they
> exist in the cache and therefore are initialized.
>
> On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix  wrote:
> >
> > Hi,
> >
> >
> >
> > I configure a project with --warn-uninitialized and get a lot of warnings. 
> > I successfully run the build.
> >
> > Then I change any CMakeLists.txt file. I run the build again. CMake checks 
> > its dependencies and reconfigures before the actual build.
> >
> > Those warnings (or at least those in the edited file) don’t appear again.
> >
> > Is this the standard behavior?
> >
> >
> >
> > Thanks,
> >
> > Felix
> >
> > --
> >
> > 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:
> > https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] --warn-uninitialized works in only first configuration

[Ramold, Felix]

It is not a cache variable. Here is an example:

cmake_minimum_required(VERSION 3.10)
project(TEST_UNINITIALIZED)

file(WRITE dummy.cpp "")
add_library(dummy dummy.cpp ${UNINITIALIZED})

Also UNINITIALIZED is not added to CMakeCache.txt.
Calling cmake twice (even without a change to the list) also shows this warning.

-Ursprüngliche Nachricht-
Von: Robert Maynard [mailto:robert.mayn...@kitware.com] 
Gesendet: Montag, 4. Februar 2019 18:16
An: Ramold, Felix
Cc: cmake@cmake.org
Betreff: Re: [CMake] --warn-uninitialized works in only first configuration

This generally occurs with CACHE variables as for non first runs they
exist in the cache and therefore are initialized.

On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix  wrote:
>
> Hi,
>
>
>
> I configure a project with --warn-uninitialized and get a lot of warnings. I 
> successfully run the build.
>
> Then I change any CMakeLists.txt file. I run the build again. CMake checks 
> its dependencies and reconfigures before the actual build.
>
> Those warnings (or at least those in the edited file) don’t appear again.
>
> Is this the standard behavior?
>
>
>
> Thanks,
>
> Felix
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
D:\CMake>cmake . -BBuild --warn-uninitialized
Warn about uninitialized values.
-- Building for: Visual Studio 14 2015
-- The C compiler identification is MSVC 19.0.23918.0
-- The CXX compiler identification is MSVC 19.0.23918.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning (dev) at CMakeLists.txt:5 (add_library):
  uninitialized variable 'UNINITIALIZED'
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
-- Generating done
-- Build files have been written to: D:/CMake/Build

D:\CMake>cmake . -BBuild --warn-uninitialized
Warn about uninitialized values.
CMake Warning (dev) at CMakeLists.txt:5 (add_library):
  uninitialized variable 'UNINITIALIZED'
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
-- Generating done
-- Build files have been written to: D:/CMake/Build

D:\CMake>cmake --build Build
Microsoft (R)-Buildmodul, Version 14.0.25123.0
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

Der Buildvorgang wurde am 05.02.2019 18:03:39 gestartet.
Projekt "D:\CMake\Build\ALL_BUILD.vcxproj" auf Knoten "1" (Standardziele).
Das Projekt "D:\CMake\Build\ALL_BUILD.vcxproj" (1) erstellt 
"D:\CMake\Build\ZERO_CHECK.vcxproj" (2) auf Knoten "1" (Standardziele).
PrepareForBuild:
  Das Verzeichnis "Win32\Debug\ZERO_CHECK\" wird erstellt.
  Das Verzeichnis "D:\CMake\Build\Debug\" wird erstellt.
  Das Verzeichnis "Win32\Debug\ZERO_CHECK\ZERO_CHECK.tlog\" wird erstellt.
InitializeBuildStatus:
  "Win32\Debug\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild" wird erstellt, da 
"AlwaysCreate" angegeben wurde.
CustomBuild:
  Checking Build System
  CMake does not need to re-run because 
D:/CMake/Build/CMakeFiles/generate.stamp is up-to-date.
FinalizeBuildStatus:
  Die Datei "Win32\Debug\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild" wird 
gelöscht.
  Aktualisieren des Timestamps von 
"Win32\Debug\ZERO_CHECK\ZERO_CHECK.tlog\ZERO_CHECK.lastbuildstate".
Die Erstellung von Projekt "D:\CMake\Build\ZERO_CHECK.vcxproj" ist 
abgeschlossen (Standardziele).

Das Projekt "D:\CMake\Build\ALL_BUILD.vcxproj" (1) erstellt 
"D:\CMake\Build\dummy.vcxproj" (3) auf Knoten "1" (Standardziele).
PrepareForBuild:
  Das Verzeichnis "dummy.dir\Debug\" wird erstellt.
  Das Verzeichnis "dummy.dir\Debug\dummy.tlog\" wird erstellt.
InitializeBuildStatus:
  "dummy.dir\Debug\dummy.tlog\unsuccessfulbuild" wird erstellt, da 
"AlwaysCreate" angegeben wurde.
CustomBuild:
  Building Custom Rule D:/CMake/CMakeLists.txt
  CMake does not need to re-run because 
D:/CMake/Build/CMakeFiles/generate.stamp is up-to-date.
ClC

[CMake] manipulating tests that are defined in a subdir

[Paul Seyfert]

Dear all,
(essentially asking what I already posted on SO
https://stackoverflow.com/questions/54447765)

I have a my_project/CMakeLists.txt file under my control. In its directory
there is also a git submodule (say 'my_project/sub' for now), and I add the
git-submodule on the cmake level though add_subdirectory(sub). The
submodule is not under my control (well, I can fork it of cause, but we'd
prefer not to have diverging branches, and the other way around, we don't
want to pollute the submodule with my-project specific stuff).
Because of my (admittedly strange) production platform, the tests from sub
fail in my project.

I can fix that by changing properties of the tests with
`set_tests_properties(test_in_sub PROPERTIES ...)`.

However since the tests are defined in my_project/sub/CMakeLists.txt and I
don't want to have my_project specific bodges in sub, I would like to call
set_tests_properties from my_project/CMakeLists.txt.

When trying to do so, cmake reports that the test I'm trying to manipulate
wouldn't exist. Things work when I call `add_test` and
`set_tests_properties` from the same CMakeLists.txt file.

My question thus is: Is it possible to call `set_tests_properties` for a
test that is `add_test`ed in a different CMakeLists.txt file, and if so
how? (Well, and if not, I'm happy for other suggestions)

Thanks in advance,
Paul
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Building a repo with multiple applications and install process

[David Jobet]

Hello,

at work, we have a mono-repo with multiple applications/libs (dozens).
The build phase is ok, but I'm not sure about the release process.

When we release, we release one application at a time.
(CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is true)
In order to speed up releases, we always perform an incremental build.

Unfortunately, we don't have one unique release process :
process 1 :
- a Jenkins pipeline executes some automatic tests then release the
binary to production. This Jenkins pipeline only builds this single
application, then executes the install step, then packages the binary
with some auxiliary files for deployment in prod.
process 2 :
- the whole source tree is built regularly through Jenkins, then, from
another Jenkins pipeline, an install step will be performed in the
last built directory to deploy only the required application

Both process 1 and process 2 are built in our CMakeLists.txt.

Process 1 just uses regular install directives + ninja install
Pros : simple
Cons : install step can be costly

Install step can be costly because, as the build directory is not
emptied, the install step will install every single binaries left over
from a previous build that have an install rule.
Also, we have install directives for non binary files (python files
for example) which will be installed unconditionally every time.

Process 2 is not triggered through the install step but as a regular
build target. Under the hood, the build step will add a POST_BUILD
step attached to the target that will invoke "cmake -P
${CMAKE_BINARY_DIR}/cmake_install.cmake -DCOMPONENT=${component}"
Pros : more "chirurgical", only install what's required
Cons : - if an application depends on several components, we need to
describe this in cmake (dependencies are described twice : once for
the build, once for the install)
   - need to maintain an extra "non standard" layer (albeit a small layer)

At this point, I'd like to ask if you see simple steps we could take
to stay as simple and standard as possible without paying the cons
(lenghty install step, double description of dependencies, extra layer
to maintain).

I have a proposal of my own, I'm just not sure this is technically
feasible. I will definitively run a POC sometime, but I thought I
would run it by you first to get your advice/experience.

So maybe the problem is we have one monolithic CMake system where all
apps are described.
What if every single application had its own independent CMake system
(while still being able to depend on common libs, that needs to be
built only once) ?
One app would describe its dependencies, the install step would then
stay simple, and only the reachable install directives would be
triggered in a per-app build.

Is it something which is feasible ? How would you implement it ? (I
thought about ExternalProject_Add but have no experience with it and
I'm not sure it would work in that case ?)

Also, we would still need to be able to build all applications in one
single command.
Do you think creating a "meta" cmake, equivalent to what we have right
now, but on top of those independent, per-app cmake, is feasible ?
(Again, I guess using ExternalProject_Add) ?

Thanks very much for your help

David
-- 

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:
https://cmake.org/mailman/listinfo/cmake