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

[Cmake-commits] CMake branch, master, updated. v3.13.4-1292-g3a2387b

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  3a2387bce79a6c8ea79f64e80079accbbd8696b2 (commit)
  from  f47d980f73a065485bb7090a850f2ac4044c2dfd (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a2387bce79a6c8ea79f64e80079accbbd8696b2
commit 3a2387bce79a6c8ea79f64e80079accbbd8696b2
Author: Kitware Robot 
AuthorDate: Wed Feb 6 00:01:07 2019 -0500
Commit: Kitware Robot 
CommitDate: Wed Feb 6 00:01:07 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 39a5b3d..324d825 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 13)
-set(CMake_VERSION_PATCH 20190205)
+set(CMake_VERSION_PATCH 20190206)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

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

Re: [cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

[Timothy Wrona]

Is there an easy way to clean the user package registry (with a CMake
command or something similar) instead of manually making edits to the
Windows registry?

After moving this package around a few times I've realized I have a bunch
of junk entries in the user package registry.

On Tue, Feb 5, 2019 at 3:15 PM Timothy Wrona  wrote:

> Thank you! I didn't know it would make a registry entry, that was the
> missing link!
>
> On Tue, Feb 5, 2019 at 2:46 PM Brad King  wrote:
>
>> On 2/5/19 2:37 PM, Timothy Wrona wrote:
>> > Can anyone explain to me how "find_package" is able to find the Eigen
>> libraries
>> > even though they are just pasted into some arbitrary location that I
>> never told
>> > the example project about?
>>
>> Eigen uses the CMake package registry feature:
>>
>>
>> https://bitbucket.org/eigen/eigen/src/a3be57987f/CMakeLists.txt?at=default=file-view-default#CMakeLists.txt-602:604
>>
>> See docs here:
>>
>>
>> https://cmake.org/cmake/help/v3.13/manual/cmake-packages.7.html#package-registry
>>
>> and step 6 of the find_package search procedure:
>>
>>
>> https://cmake.org/cmake/help/v3.13/command/find_package.html#search-procedure
>>
>> -Brad
>>
>
-- 

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-developers

Re: [cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

[Timothy Wrona]

Thank you! I didn't know it would make a registry entry, that was the
missing link!

On Tue, Feb 5, 2019 at 2:46 PM Brad King  wrote:

> On 2/5/19 2:37 PM, Timothy Wrona wrote:
> > Can anyone explain to me how "find_package" is able to find the Eigen
> libraries
> > even though they are just pasted into some arbitrary location that I
> never told
> > the example project about?
>
> Eigen uses the CMake package registry feature:
>
>
> https://bitbucket.org/eigen/eigen/src/a3be57987f/CMakeLists.txt?at=default=file-view-default#CMakeLists.txt-602:604
>
> See docs here:
>
>
> https://cmake.org/cmake/help/v3.13/manual/cmake-packages.7.html#package-registry
>
> and step 6 of the find_package search procedure:
>
>
> https://cmake.org/cmake/help/v3.13/command/find_package.html#search-procedure
>
> -Brad
>
-- 

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-developers

Re: [cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

[Brad King via cmake-developers]

On 2/5/19 2:37 PM, Timothy Wrona wrote:
> Can anyone explain to me how "find_package" is able to find the Eigen 
> libraries
> even though they are just pasted into some arbitrary location that I never 
> told
> the example project about?

Eigen uses the CMake package registry feature:

  
https://bitbucket.org/eigen/eigen/src/a3be57987f/CMakeLists.txt?at=default=file-view-default#CMakeLists.txt-602:604

See docs here:

  
https://cmake.org/cmake/help/v3.13/manual/cmake-packages.7.html#package-registry

and step 6 of the find_package search procedure:

  https://cmake.org/cmake/help/v3.13/command/find_package.html#search-procedure

-Brad
-- 

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-developers

[cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

[Timothy Wrona]

I am working my way through the "CMake Cookbook" by Radovan Bast and
Roberto Di Remigio and got to an example that required the Eigen C++
libraries. (chapter-02/recipe-06)

I downloaded the ".zip" for the Eigen libraries and unzipped it to an
arbitrary location. Then I ran CMake on it (but I did not build or install
it). After doing this, magically the example code was able to find it and
the example built successfully even though I never told it where to look
for the Eigen libraries.

A detailed description of my experience is in this stack overflow post:
https://stackoverflow.com/questions/54541261/cmake-find-package-command-on-a-package-that-was-not-installed-is-unexpectedly?noredirect=1#comment95884208_54541261

Can anyone explain to me how "find_package" is able to find the Eigen
libraries even though they are just pasted into some arbitrary location
that I never told the example project about?

As far as I can tell from the documentation on "find_package" it should not
work.

Thanks,
Tim
-- 

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-developers

[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.

[Cmake-commits] CMake branch, master, updated. v3.13.4-1291-gf47d980

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  f47d980f73a065485bb7090a850f2ac4044c2dfd (commit)
   via  ab01ce91eee2ff8b00d56a5044a54404d4d3f49c (commit)
   via  9ddbf4c6e65b17b76dd6ccca72c5b3a0b7cbb1ad (commit)
   via  8372c054729984a76e3e619b4c28865006d905d0 (commit)
   via  b6cf08626785fc6401220928be8ab37b89bc669c (commit)
   via  ed0fa784ebb2b7e4d6db8b40d16f84f34692890a (commit)
  from  c6d679f0d904b19b3be411b399b5904a5da7ea78 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f47d980f73a065485bb7090a850f2ac4044c2dfd
commit f47d980f73a065485bb7090a850f2ac4044c2dfd
Merge: ab01ce9 9ddbf4c
Author: Brad King 
AuthorDate: Tue Feb 5 12:47:29 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 5 07:49:07 2019 -0500

Merge topic 'update-kwsys'

9ddbf4c6e6 Merge branch 'upstream-KWSys' into update-kwsys
8372c05472 KWSys 2019-02-05 (65802a20)

Acked-by: Kitware Robot 
Merge-request: !2918


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab01ce91eee2ff8b00d56a5044a54404d4d3f49c
commit ab01ce91eee2ff8b00d56a5044a54404d4d3f49c
Merge: c6d679f b6cf086
Author: Brad King 
AuthorDate: Tue Feb 5 12:46:51 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 5 07:47:14 2019 -0500

Merge topic 'autogen_single_all_sources_iteration'

b6cf086267 Autogen: Iterate over makefile sources only once
ed0fa784eb cmSystemTools: Let `GetFileFormat` accept a `std::stding const&`

Acked-by: Kitware Robot 
Merge-request: !2909


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ddbf4c6e65b17b76dd6ccca72c5b3a0b7cbb1ad
commit 9ddbf4c6e65b17b76dd6ccca72c5b3a0b7cbb1ad
Merge: 762a41f 8372c05
Author: Brad King 
AuthorDate: Tue Feb 5 07:20:34 2019 -0500
Commit: Brad King 
CommitDate: Tue Feb 5 07:20:34 2019 -0500

Merge branch 'upstream-KWSys' into update-kwsys

* upstream-KWSys:
  KWSys 2019-02-05 (65802a20)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8372c054729984a76e3e619b4c28865006d905d0
commit 8372c054729984a76e3e619b4c28865006d905d0
Author: KWSys Upstream 
AuthorDate: Tue Feb 5 07:19:44 2019 -0500
Commit: Brad King 
CommitDate: Tue Feb 5 07:20:29 2019 -0500

KWSys 2019-02-05 (65802a20)

Code extracted from:

https://gitlab.kitware.com/utils/kwsys.git

at commit 65802a20ec4b9a774518151c3f8772e082163601 (master).

Upstream Shortlog
-

Nicolae Vartolomei (1):
  d1536b02 macOS: Better approximation for AvailablePhysicalMemory

diff --git a/SystemInformation.cxx b/SystemInformation.cxx
index 6c12355..f323efc 100644
--- a/SystemInformation.cxx
+++ b/SystemInformation.cxx
@@ -4424,7 +4424,8 @@ bool SystemInformationImplementation::ParseSysCtl()
   ) == KERN_SUCCESS) {
 len = sizeof(value);
 err = sysctlbyname("hw.pagesize", , , KWSYS_NULLPTR, 0);
-int64_t available_memory = vmstat.free_count * value;
+int64_t available_memory =
+  (vmstat.free_count + vmstat.inactive_count) * value;
 this->AvailablePhysicalMemory =
   static_cast(available_memory / 1048576);
   }

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b6cf08626785fc6401220928be8ab37b89bc669c
commit b6cf08626785fc6401220928be8ab37b89bc669c
Author: Sebastian Holtermann 
AuthorDate: Sat Feb 2 12:44:05 2019 +0100
Commit: Sebastian Holtermann 
CommitDate: Sat Feb 2 18:42:08 2019 +0100

Autogen: Iterate over makefile sources only once

In QtAutoGen we used to iterate over all makefile source two times to
extract file parameters for moc and uic respectively.  This patch merges 
both
iterations into one loop. This makes the code easier to understand and 
likely
faster to execute as well.

diff --git a/Source/cmQtAutoGenInitializer.cxx 
b/Source/cmQtAutoGenInitializer.cxx
index 1d64247..a96d574 100644
--- a/Source/cmQtAutoGenInitializer.cxx
+++ b/Source/cmQtAutoGenInitializer.cxx
@@ -616,40 +616,6 @@ bool cmQtAutoGenInitializer::InitUic()
   }
 }
   }
-  // .ui files skip and options
-  {
-std::string const uiExt = "ui";
-std::string pathError;
-for (cmSourceFile* sf : makefile->GetSourceFiles()) {
-  // sf->GetExtension() is only valid after sf->GetFullPath() ...
-  // Since we're iterating over source files that might be not in the
-  // target we need to check for path errors (not existing files).
-  std::string const& fPath = sf->GetFullPath();
-  if (!pathError.empty()) {
-pathError.clear();
-continue;
-  }
-  if 

[Cmake-commits] CMake branch, master, updated. v3.13.4-1285-gc6d679f

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  c6d679f0d904b19b3be411b399b5904a5da7ea78 (commit)
   via  c03072f2f7a08c6ddf0cec58dfc8ea2b83f4c1a9 (commit)
   via  d3d2c3cd497e09281a8f237b5a4cd35d8cd298f0 (commit)
   via  e8ee8cab97bdb084d4555ee3e76eb33303e3bc85 (commit)
   via  11da882a1293b39ddd054342b1e6f2f3bd1bc934 (commit)
   via  36cf44a7a3a8931c97790db6df61439d4dd86ea3 (commit)
  from  25e616862dac08aae7c4a3ad01839acfe7342ec7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c6d679f0d904b19b3be411b399b5904a5da7ea78
commit c6d679f0d904b19b3be411b399b5904a5da7ea78
Merge: c03072f d3d2c3c
Author: Brad King 
AuthorDate: Tue Feb 5 12:30:55 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 5 07:36:36 2019 -0500

Merge topic 'vs-fortran-target-check'

d3d2c3cd49 VS: Fix Fortran target type selection when linking C++ targets

Acked-by: Kitware Robot 
Merge-request: !2913


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c03072f2f7a08c6ddf0cec58dfc8ea2b83f4c1a9
commit c03072f2f7a08c6ddf0cec58dfc8ea2b83f4c1a9
Merge: 25e6168 e8ee8ca
Author: Brad King 
AuthorDate: Tue Feb 5 12:30:19 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 5 07:33:04 2019 -0500

Merge topic '17870-iphone-friendly-cmake'

e8ee8cab97 Xcode: Completely disable code signing for compiler id detection
11da882a12 Apple: Introduce separate system name for iOS, tvOS, and watchOS
36cf44a7a3 Tests: Isolate RunCMake.XcodeProject per-device cases from host 
arch

Acked-by: Kitware Robot 
Merge-request: !2392


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3d2c3cd497e09281a8f237b5a4cd35d8cd298f0
commit d3d2c3cd497e09281a8f237b5a4cd35d8cd298f0
Author: Brad King 
AuthorDate: Mon Feb 4 09:41:57 2019 -0500
Commit: Brad King 
CommitDate: Mon Feb 4 14:13:46 2019 -0500

VS: Fix Fortran target type selection when linking C++ targets

Since commit 2c9f35789d (VS: Decide project type by linker lang as
fallback, 2017-03-30, v3.9.0-rc1~340^2) we consider the linker language
when detecting whether to generate a `.vfproj` or `.vcxproj` file.
However, this could cause C-only projects to become `.vfproj` files if
they link to Fortran projects.  Instead we should consider only the
`LINKER_LANGUAGE` property on the target itself.  This approach is
already used for CSharp.  It allows project code to specify the project
file type for a target with no sources but does not allow linked targets
to affect it.

Fixes: #18687

diff --git a/Source/cmGlobalVisualStudioGenerator.cxx 
b/Source/cmGlobalVisualStudioGenerator.cxx
index 77be592..1922906 100644
--- a/Source/cmGlobalVisualStudioGenerator.cxx
+++ b/Source/cmGlobalVisualStudioGenerator.cxx
@@ -813,7 +813,6 @@ bool cmGlobalVisualStudioGenerator::TargetIsFortranOnly(
   cmGeneratorTarget const* gt)
 {
   // check to see if this is a fortran build
-  std::set languages;
   {
 // Issue diagnostic if the source files depend on the config.
 std::vector sources;
@@ -821,27 +820,21 @@ bool cmGlobalVisualStudioGenerator::TargetIsFortranOnly(
   return false;
 }
   }
+
   // If there's only one source language, Fortran has to be used
   // in order for the sources to compile.
-  // Note: Via linker propagation, LINKER_LANGUAGE could become CXX in
-  // this situation and mismatch from the actual language of the linker.
+  std::set languages;
   gt->GetLanguages(languages, "");
-  if (languages.size() == 1) {
-if (*languages.begin() == "Fortran") {
-  return true;
-}
-  }
-
-  // In the case of mixed object files or sources mixed with objects,
-  // decide the language based on the value of LINKER_LANGUAGE.
-  // This will not make it possible to mix source files of different
-  // languages, but object libraries will be linked together in the
-  // same fashion as other generators do.
-  if (gt->GetLinkerLanguage("") == "Fortran") {
-return true;
-  }
-
-  return false;
+  // Consider an explicit linker language property, but *not* the
+  // computed linker language that may depend on linked targets.
+  // This allows the project to control the language choice in
+  // a target with none of its own sources, e.g. when also using
+  // object libraries.
+  const char* linkLang = gt->GetProperty("LINKER_LANGUAGE");
+  if (linkLang && *linkLang) {
+languages.insert(linkLang);
+  }
+  return languages.size() == 1 && *languages.begin() == "Fortran";
 }
 
 bool cmGlobalVisualStudioGenerator::TargetCompare::operator()(
diff --git 

[Cmake-commits] CMake branch, master, updated. v3.13.4-1279-g25e6168

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  25e616862dac08aae7c4a3ad01839acfe7342ec7 (commit)
   via  96dece6dc11627d0e7b5588f63f2578b581cfb77 (commit)
  from  762a41fd19dff29de41009bfe7bcf69917e5ffb0 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25e616862dac08aae7c4a3ad01839acfe7342ec7
commit 25e616862dac08aae7c4a3ad01839acfe7342ec7
Merge: 762a41f 96dece6
Author: Brad King 
AuthorDate: Tue Feb 5 12:29:36 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 5 07:29:59 2019 -0500

Merge topic 'swift-xcode-10.2'

96dece6dc1 Xcode: Update default Swift language version for Xcode 10.2

Acked-by: Kitware Robot 
Merge-request: !2912


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96dece6dc11627d0e7b5588f63f2578b581cfb77
commit 96dece6dc11627d0e7b5588f63f2578b581cfb77
Author: Brad King 
AuthorDate: Mon Feb 4 12:05:08 2019 -0500
Commit: Brad King 
CommitDate: Mon Feb 4 13:26:10 2019 -0500

Xcode: Update default Swift language version for Xcode 10.2

Xcode 10.2 no longer supports Swift language versions before 4.0.

Fixes: #18871

diff --git a/Help/variable/CMAKE_Swift_LANGUAGE_VERSION.rst 
b/Help/variable/CMAKE_Swift_LANGUAGE_VERSION.rst
index 50121e2..b4a74eb 100644
--- a/Help/variable/CMAKE_Swift_LANGUAGE_VERSION.rst
+++ b/Help/variable/CMAKE_Swift_LANGUAGE_VERSION.rst
@@ -1,5 +1,9 @@
 CMAKE_Swift_LANGUAGE_VERSION
 
 
-Set to the Swift language version number.  If not set, the legacy "2.3"
-version is assumed.
+Set to the Swift language version number.  If not set, the oldest legacy
+version known to be available in the host Xcode version is assumed:
+
+* Swift ``4.0`` for Xcode 10.2 and above.
+* Swift ``3.0`` for Xcode 8.3 and above.
+* Swift ``2.3`` for Xcode 8.2 and below.
diff --git a/Modules/CMakeDetermineCompilerId.cmake 
b/Modules/CMakeDetermineCompilerId.cmake
index 2a0dbd3..cdbaea6 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -332,6 +332,8 @@ Id flags: ${testflags} 
${CMAKE_${lang}_COMPILER_ID_FLAGS_ALWAYS}
 if("${lang}" STREQUAL "Swift")
   if(CMAKE_Swift_LANGUAGE_VERSION)
 set(id_lang_version "SWIFT_VERSION = ${CMAKE_Swift_LANGUAGE_VERSION};")
+  elseif(XCODE_VERSION VERSION_GREATER_EQUAL 10.2)
+set(id_lang_version "SWIFT_VERSION = 4.0;")
   elseif(XCODE_VERSION VERSION_GREATER_EQUAL 8.3)
 set(id_lang_version "SWIFT_VERSION = 3.0;")
   else()
diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index b428ae1..16f8a0e 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -3142,6 +3142,8 @@ bool cmGlobalXCodeGenerator::CreateXCodeObjects(
 if (const char* vers = this->CurrentMakefile->GetDefinition(
   "CMAKE_Swift_LANGUAGE_VERSION")) {
   swiftVersion = vers;
+} else if (this->XcodeVersion >= 102) {
+  swiftVersion = "4.0";
 } else if (this->XcodeVersion >= 83) {
   swiftVersion = "3.0";
 } else {
diff --git a/Tests/SwiftOnly/CMakeLists.txt b/Tests/SwiftOnly/CMakeLists.txt
index cf4463c..e5f8588 100644
--- a/Tests/SwiftOnly/CMakeLists.txt
+++ b/Tests/SwiftOnly/CMakeLists.txt
@@ -1,7 +1,9 @@
 cmake_minimum_required(VERSION 3.3)
 project(SwiftOnly Swift)
 
-if(NOT XCODE_VERSION VERSION_LESS 8.0)
+if(NOT XCODE_VERSION VERSION_LESS 10.2)
+  set(CMAKE_Swift_LANGUAGE_VERSION 5.0)
+elseif(NOT XCODE_VERSION VERSION_LESS 8.0)
   set(CMAKE_Swift_LANGUAGE_VERSION 3.0)
 endif()
 

---

Summary of changes:
 Help/variable/CMAKE_Swift_LANGUAGE_VERSION.rst | 8 ++--
 Modules/CMakeDetermineCompilerId.cmake | 2 ++
 Source/cmGlobalXCodeGenerator.cxx  | 2 ++
 Tests/SwiftOnly/CMakeLists.txt | 4 +++-
 4 files changed, 13 insertions(+), 3 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[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