[CMake] Linking object libraries into a Windows DLL in 3.12rc1

[Jason Heeris]

 I was very excited to see that CMake 3.12rc1 now has support for linking
object libraries, making usage requirements propagate to top level targets
that use these libraries. However, I'm having trouble putting the concept
into practice to build a DLL on Windows 10 using Visual Studio 2017's
compiler (MSVC 19.x I think).

There's a minimal self-contained example here:

https://gitlab.com/detly/cmake-dll-ex

The point is to make a DLL of "module2" that exports the "module2()"
function. This is the "module2_dll" target in
modules/module2/CMakeLists.txt. If you don't want to pore over that
project, basically I have this structure:

  /
- common
- modules/
  - module1 (depends on "common")
  - module2 (depends on "common" and "module1", exports "module2()")

In common/CMakeLists.txt I have 'add_library(common OBJECT "common.c")'.
Similarly for module1 and module2, and module1 also has
'target_link_libraries(module1 PUBLIC common)' and module2 has
'target_link_libraries(module2 PUBLIC module1 common)'. (I am aware that
some build systems don't like build targets without source files, but
adding "module2.c" doesn't change things.)

Finally there's a DLL target:

add_library(module2_dll SHARED)
target_link_libraries(module2_dll module2)

I build this by doing:

mkdir build
cd build
cmake ..
cmake --build . --target module2_dll

The toolchain information shows:

-- Building for: Visual Studio 15 2017
-- The C compiler identification is MSVC 19.13.26129.0
-- The CXX compiler identification is MSVC 19.13.26129.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.13.26128/bin/Hostx86/x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.13.26128/bin/Hostx86/x86/cl.exe --
works

Now I would expect that building the module2_dll target would build .obj
files for all dependencies and link them all together as a DLL. But it
ultimately fails with:

"C:\Users\heerij\Code\cmake-dll-ex\build\modules\module2\module2_dll.vcxproj"
(default target) (1) ->
(Link target) ->
  module2.obj : error LNK2019: unresolved external symbol _common
referenced in function _module2 [C:\Users\heerij\Code
\cmake-dll-ex\build\modules\module2\module2_dll.vcxproj]
  module2.obj : error LNK2019: unresolved external symbol _module1
referenced in function _module2 [C:\Users\heerij\Cod
e\cmake-dll-ex\build\modules\module2\module2_dll.vcxproj]

C:\Users\heerij\Code\cmake-dll-ex\build\modules\module2\Debug\module2_dll.dll
: fatal error LNK1120: 2 unresolved ext ernals
[C:\Users\heerij\Code\cmake-dll-ex\build\modules\module2\module2_dll.vcxproj]

If I remove the "SHARED" option from 'add_library(module2_dll)', it builds
a .lib file just fine. If I build the module2 target (not module2_dll), it
builds a .lib file as well. But I want a DLL.

I was surprised to see two things:

1. The final link command only runs on module2.obj, not module1.obj or
common.obj. If I were doing it by hand I'd link all three as the final step.

2. The intermediate commands build both .obj and .lib files. Are the .lib
files required? I don't know enough about Windows build mechanics to know.

Example output for #1:

Link:
  C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\HostX86\x86\link.exe
/ERR
  ORREPORT:QUEUE
/OUT:"C:\Users\heerij\Code\cmake-dll-ex\build\modules\module2\Debug\module2_dll.dll"
/INCREMENTAL /NOL
  OGO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.
  lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/manifest:embed /DEBUG /PDB:"C:/Users/heerij/Code/cma
  ke-dll-ex/build/modules/module2/Debug/module2_dll.pdb" /SUBSYSTEM:CONSOLE
/TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:

/Users/heerij/Code/cmake-dll-ex/build/modules/module2/Debug/module2_dll.lib"
/MACHINE:X86 /SAFESEH  /machine:X86 /DLL

 
"C:\Users\heerij\Code\cmake-dll-ex\build\modules\module2\module2.dir\Debug\module2.obj"

Example output for #2:

ClCompile:
  C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\HostX86\x86\CL.exe /c
/I"
  C:\Users\heerij\Code\cmake-dll-ex\modules\module2"
/I"C:\Users\heerij\Code\cmake-dll-ex\common" /I"C:\Users\heerij\Co
  de\cmake-dll-ex\modules\module1" /Zi /nologo /W3 /WX-
/diagnostics:classic /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D "CMA
  KE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t
/Zc:forScope /Zc:inline /Fo"module2.dir\Deb
  ug\\" /Fd"module2.dir\Debug\module2.pdb" /Gd /TC /analyze- /FC
/errorReport:queue "C:\Users\heerij\Code\cmake-dll-ex\
  modules\module2\module2.c"
  module2.c
Lib:
  C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\HostX86\x86\Lib.exe
/OUT:
  "module2.dir\Debug\module2.lib" /NOLOGO  /machine:X86
module2.dir\Debug\module2.obj

[Cmake-commits] CMake branch, master, updated. v3.12.0-rc1-119-gd45d5e2

[Kitware Robot]

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  d45d5e28ec1d662de3602562e033967481cd0c40 (commit)
  from  07cfb18f9d29cfc0588ede928846a03ec5599c48 (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=d45d5e28ec1d662de3602562e033967481cd0c40
commit d45d5e28ec1d662de3602562e033967481cd0c40
Author: Kitware Robot 
AuthorDate: Tue Jun 26 00:01:10 2018 -0400
Commit: Kitware Robot 
CommitDate: Tue Jun 26 00:01:10 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 729816e..123f324 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 12)
-set(CMake_VERSION_PATCH 20180625)
+set(CMake_VERSION_PATCH 20180626)
 #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-developers] CMake Green Hills MULTI build configuration support

[frodak]

I've worked on this in the past but never finalized anything.
It's all in the
https://gitlab.kitware.com/frodak17/cmake/commits/ghs_project.
This contains several different items I was working on at the time.

I took a quick look at what you are working on.
The only real issue that I see is that build configurations that are chosen
are not compatible with existing Integrity installations.
For instance in Integrity IOT for ApolloLake BSPs you must use the build
configurations as provided by the BSP.
If you don't then you'll have to recreate them line by line in you CMAKE
files.

The other problem is that build configurations will clash with the already
existing compile parameters that are defined in the CMake output.
In the build configurations that I've used they setup where libraries and
objects files should be located along with all the proper compiler settings.
But the output of the CMake defines these file by file.  The two methods
are not compatible.

Honestly, I had recently been thinking on working on this again.  But
instead of trying to fight the already existing GHS generator that looks
like a Makefile output, I was going to create a new GHS generator for Multi
7 that supported all three versions of Integrity that I use along with the
various compilers and IDEs.

Best regards,
Fred Baksik


On Mon, Jun 25, 2018 at 11:37 AM, Erich Schroeter <
erich.schroeter.official+cm...@gmail.com> wrote:

> I'm interested in adding build configuration support to the "Green Hills
> MULTI" generator and wanted to see if anyone is already in the process of
> implementing this feature. If you've worked on this generator in the past
> and have any notes you'd like to share with me I'll gladly accept them. I'm
> willing to collaborate with anyone wanting to work on this feature too.
>
> My fork is:
> https://gitlab.kitware.com/erichschroeter/cmake/tree/feature/
> GhsMultiBuildConfigurationSupport
>
> -Erich
>
> --
>
> 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
>
>
-- 

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] race condition with target_objects

[Juan E. Sanchez]

Hi,

I am getting a race condition when I do a parallel build.

Having an OBJECT library in one directory:
ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)

And then having that object library being used in another directory:
TARGET_LINK_LIBRARIES (symdiff_tcl $ 
${TCL_ARCHIVE})


Results in this error with a parallel build:
 15%] Building CXX object 
src/engine/CMakeFiles/symdiff_static.dir/EquationObject.o
make[2]: *** No rule to make target 
`src/engine/CMakeFiles/symdiff_objects.dir/EquationObject.o', needed by 
`src/tclcomp/libsymdifftcl.dylib'.  Stop.

make[2]: *** Waiting for unfinished jobs

Serial builds work fine.  How do I tell cmake to wait?  This is cmake 
3.9.0-rc4 running on os x with the makefile generator.


Regards,

Juan
--

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] [ANNOUNCE] CMake 3.12.0-rc1 is ready for testing

[Raffi Enficiaud]

Le 14/06/2018 à 21:10, Robert Maynard a écrit :
I am proud to announce the first CMake 3.12 release candidate. 
https://cmake.org/download/


Documentation is available at: https://cmake.org/cmake/help/v3.12

Release notes appear below and are also published at 
https://cmake.org/cmake/help/v3.12/release/3.12.html


Some of the more significant changes in CMake 3.12 are:

[snip]

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* A "FindODBC" module was added to find an Open Database Connectivity
(ODBC) library.

* New "FindPython3" and "FindPython2" modules, as well as a new 
"FindPython" module, have been added to provide a new way to locate 
python environments.




Hi!

would it be possible to add the following to the release notes?

* FindMatlab now supports the Matlab Runtime Compiler (MCR) for
  compiling and linking matlab extensions. The MCR does not
  consume any license and is free to download.

Thanks!
Raffi

--

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] Interface source paths evaluated relative to dependent library

[Marc CHEVRIER]

Fine.
I am surprised because both commands expects the same thing: a CMake list.
The only touchy point is to ensure that the list separator is correctly
passed to the command without early evaluation. For that purpose ensure
that the generator expression is passed to the command inside quotes:
target_include_directories(target INTERFACE
"$")



Le lun. 25 juin 2018 à 17:41, Rich T  a écrit :

> Ah, brilliant - I thought I'd tried that, but just gave it another go
> following your advice and it worked a charm.
> Incidentally, do you know what the rules are around the
> BUILD_INTERFACE generator expression and line breaks / list items?
> It seems to work fine in target_sources when enclosing multiple
> lines/files, but in target_include_directories I need one
> BUILD_INTERFACE expression per directory or I get an error.
>
> Thanks again,
>
> Rich
>
> On Mon, Jun 25, 2018 at 3:28 PM, Marc CHEVRIER 
> wrote:
> > You can manage different paths (one for build export and one for install
> > export) by using '$' and '$'.
> > '$' accepts absolute paths and
> > '$ expects paths relative to the install prefix
> > (CMAKE_INSTALL_PREFIX variable).
> > .
> >
> >
> > Le lun. 25 juin 2018 à 16:23, Rich T  a
> écrit :
> >>
> >> Hi everyone, I've a question about interface sources.
> >>
> >> If you create an interface target A, add some sources via
> >>
> >> add_library(A INTERFACE)
> >> target_sources(A INTERFACE some/relative/path)
> >>
> >> then link to another library B:
> >>
> >> add_library(B)
> >> target_link_libraries(B PRIVATE A)
> >>
> >> B will search for those sources relative to its own source directory,
> not
> >> the directory where A is defined. This means B fails to configure with a
> >> missing sources error if the targets are in different directories.
> >>
> >> If I specify the paths absolutely, B successfully finds the sources.
> >> However, A can no longer be exported and neither can the static variant
> of B
> >> by association.
> >>
> >> I tried using $ in front of the relative
> >> path, however it turns out SOURCE_DIR isn't a whitelisted property for
> >> INTERFACE libraries.
> >>
> >> Is this behavior intentional, and if so, is there any workaround? (other
> >> than defining all targets with interface sources in the same directory
> as
> >> the targets that use them)
> >> --
> >>
> >> 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] Interface source paths evaluated relative to dependent library

[Rich T]

Ah, brilliant - I thought I'd tried that, but just gave it another go
following your advice and it worked a charm.
Incidentally, do you know what the rules are around the
BUILD_INTERFACE generator expression and line breaks / list items?
It seems to work fine in target_sources when enclosing multiple
lines/files, but in target_include_directories I need one
BUILD_INTERFACE expression per directory or I get an error.

Thanks again,

Rich

On Mon, Jun 25, 2018 at 3:28 PM, Marc CHEVRIER  wrote:
> You can manage different paths (one for build export and one for install
> export) by using '$' and '$'.
> '$' accepts absolute paths and
> '$ expects paths relative to the install prefix
> (CMAKE_INSTALL_PREFIX variable).
> .
>
>
> Le lun. 25 juin 2018 à 16:23, Rich T  a écrit :
>>
>> Hi everyone, I've a question about interface sources.
>>
>> If you create an interface target A, add some sources via
>>
>> add_library(A INTERFACE)
>> target_sources(A INTERFACE some/relative/path)
>>
>> then link to another library B:
>>
>> add_library(B)
>> target_link_libraries(B PRIVATE A)
>>
>> B will search for those sources relative to its own source directory, not
>> the directory where A is defined. This means B fails to configure with a
>> missing sources error if the targets are in different directories.
>>
>> If I specify the paths absolutely, B successfully finds the sources.
>> However, A can no longer be exported and neither can the static variant of B
>> by association.
>>
>> I tried using $ in front of the relative
>> path, however it turns out SOURCE_DIR isn't a whitelisted property for
>> INTERFACE libraries.
>>
>> Is this behavior intentional, and if so, is there any workaround? (other
>> than defining all targets with interface sources in the same directory as
>> the targets that use them)
>> --
>>
>> 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-developers] CMake Green Hills MULTI build configuration support

[Erich Schroeter]

I'm interested in adding build configuration support to the "Green Hills
MULTI" generator and wanted to see if anyone is already in the process of
implementing this feature. If you've worked on this generator in the past
and have any notes you'd like to share with me I'll gladly accept them. I'm
willing to collaborate with anyone wanting to work on this feature too.

My fork is:
https://gitlab.kitware.com/erichschroeter/cmake/tree/feature/GhsMultiBuildConfigurationSupport

-Erich
-- 

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] compiling for both python2 and python3

[Juan E. Sanchez]

Hi,

What happens if you call FindBoost once for python 2 and once for python 
3?  Between invocations you could copy the boost variables to python 
specific variants.


FindBoost( . . . .)
SET(Boost_LIBRARY_DIRS_PYTHON2 ${Boost_LIBRARY_DIRS})
FindBoost( . . . .)
SET(Boost_LIBRARY_DIRS_PYTHON3 ${Boost_LIBRARY_DIRS})


Regards,

Juan


On 6/25/18 1:24 AM, Alexander Bürger wrote:

Hello Juan,

but there are also two boost-python versions required, one for python2 
and one for python3. I think it is not a good idea to reimplement the 
FindBoost logic.


Cheers,

Alexander Bürger
MET Norway
​




--

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] Interface source paths evaluated relative to dependent library

[Marc CHEVRIER]

You can manage different paths (one for build export and one for install
export) by using '$' and '$'.
'$' accepts absolute paths and
'$ expects paths relative to the install prefix
(CMAKE_INSTALL_PREFIX variable).
.


Le lun. 25 juin 2018 à 16:23, Rich T  a écrit :

> Hi everyone, I've a question about interface sources.
>
> If you create an interface target A, add some sources via
>
> add_library(A INTERFACE)
> target_sources(A INTERFACE some/relative/path)
>
> then link to another library B:
>
> add_library(B)
> target_link_libraries(B PRIVATE A)
>
> B will search for those sources relative to its own source directory, not
> the directory where A is defined. This means B fails to configure with a
> missing sources error if the targets are in different directories.
>
> If I specify the paths absolutely, B successfully finds the sources.
> However, A can no longer be exported and neither can the static variant of
> B by association.
>
> I tried using $ in front of the relative
> path, however it turns out SOURCE_DIR isn't a whitelisted property for
> INTERFACE libraries.
>
> Is this behavior intentional, and if so, is there any workaround? (other
> than defining all targets with interface sources in the same directory as
> the targets that use them)
> --
>
> 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-commits] CMake branch, master, updated. v3.12.0-rc1-118-g07cfb18

[Kitware Robot]

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  07cfb18f9d29cfc0588ede928846a03ec5599c48 (commit)
   via  2c36dabbeef72e2d9c9697e6dcc5c67fd0a912dd (commit)
   via  7e283acde7454e57a801edc9cb38b5dc0630210d (commit)
   via  889033b5c6847cf1f7bd789384405d59dc333bf6 (commit)
  from  e9ec0cc3bb9ee2a03cdf2ad45712ea41cc8fac81 (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=07cfb18f9d29cfc0588ede928846a03ec5599c48
commit 07cfb18f9d29cfc0588ede928846a03ec5599c48
Merge: 2c36dab 7e283ac
Author: Brad King 
AuthorDate: Mon Jun 25 10:21:10 2018 -0400
Commit: Brad King 
CommitDate: Mon Jun 25 10:21:10 2018 -0400

Merge branch 'release-3.12'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c36dabbeef72e2d9c9697e6dcc5c67fd0a912dd
commit 2c36dabbeef72e2d9c9697e6dcc5c67fd0a912dd
Merge: e9ec0cc 889033b
Author: Brad King 
AuthorDate: Mon Jun 25 14:20:31 2018 +
Commit: Kitware Robot 
CommitDate: Mon Jun 25 10:20:38 2018 -0400

Merge topic 'libuv-new-version-file-location'

889033b5c6 FindLibUV: Also check uv/version.h for version detection

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


---

Summary of changes:
 Source/Modules/FindLibUV.cmake | 2 ++
 1 file changed, 2 insertions(+)


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

[CMake] Interface source paths evaluated relative to dependent library

[Rich T]

Hi everyone, I've a question about interface sources.

If you create an interface target A, add some sources via

add_library(A INTERFACE)
target_sources(A INTERFACE some/relative/path)

then link to another library B:

add_library(B)
target_link_libraries(B PRIVATE A)

B will search for those sources relative to its own source directory, not
the directory where A is defined. This means B fails to configure with a
missing sources error if the targets are in different directories.

If I specify the paths absolutely, B successfully finds the sources.
However, A can no longer be exported and neither can the static variant of
B by association.

I tried using $ in front of the relative
path, however it turns out SOURCE_DIR isn't a whitelisted property for
INTERFACE libraries.

Is this behavior intentional, and if so, is there any workaround? (other
than defining all targets with interface sources in the same directory as
the targets that use them)
-- 

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.12.0-rc1-114-ge9ec0cc

[Kitware Robot]

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  e9ec0cc3bb9ee2a03cdf2ad45712ea41cc8fac81 (commit)
   via  8848a1c07a47813d4d074292038add1c8822d158 (commit)
   via  268919069baaa5c9a72e8a6b9070f78b26e02f0e (commit)
   via  00523ad9c5588065b09e345e3486c15250dc4c19 (commit)
   via  7bffd71c3b79dabb90c1c90f9527f3533411d7bb (commit)
   via  b41b30f16e1ae2c8248321dbf51347b7a4b90d30 (commit)
   via  f2d97c1cdf06f8575d0b23130db4ffa725ca5161 (commit)
   via  6d7fdedde6c41e6d5e7840a7d653d490296aa6e7 (commit)
   via  221f8aa7e28eadcc7541e16d0b5dbaa243ba7829 (commit)
  from  ae153c691454ec24dbae5caa5d0e4bb2351d0886 (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=e9ec0cc3bb9ee2a03cdf2ad45712ea41cc8fac81
commit e9ec0cc3bb9ee2a03cdf2ad45712ea41cc8fac81
Merge: 8848a1c b41b30f
Author: Brad King 
AuthorDate: Mon Jun 25 13:56:48 2018 +
Commit: Kitware Robot 
CommitDate: Mon Jun 25 09:57:35 2018 -0400

Merge topic 'update-kwsys'

b41b30f16e Update use of KWSys SystemTools::SplitString for new signature
f2d97c1cdf Merge branch 'upstream-KWSys' into update-kwsys
6d7fdedde6 KWSys 2018-06-22 (49068d94)

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8848a1c07a47813d4d074292038add1c8822d158
commit 8848a1c07a47813d4d074292038add1c8822d158
Merge: 2689190 7bffd71
Author: Brad King 
AuthorDate: Mon Jun 25 13:56:36 2018 +
Commit: Kitware Robot 
CommitDate: Mon Jun 25 09:56:56 2018 -0400

Merge topic 'test-wizard'

7bffd71c3b Tests: Adopt wizard test in RunCMake.CommandLine

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=268919069baaa5c9a72e8a6b9070f78b26e02f0e
commit 268919069baaa5c9a72e8a6b9070f78b26e02f0e
Merge: ae153c6 00523ad
Author: Brad King 
AuthorDate: Mon Jun 25 09:55:05 2018 -0400
Commit: Brad King 
CommitDate: Mon Jun 25 09:55:05 2018 -0400

Merge branch 'release-3.12'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7bffd71c3b79dabb90c1c90f9527f3533411d7bb
commit 7bffd71c3b79dabb90c1c90f9527f3533411d7bb
Author: Brad King 
AuthorDate: Fri Jun 22 13:59:14 2018 -0400
Commit: Brad King 
CommitDate: Fri Jun 22 13:59:14 2018 -0400

Tests: Adopt wizard test in RunCMake.CommandLine

Avoid a whole separate test for one removed command-line option.

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 89babe4..b389a13 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -3441,10 +3441,6 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
   )
   endif()
 
-  add_test(NAME CMakeWizardTest COMMAND cmake -i)
-  set_property(TEST CMakeWizardTest PROPERTY PASS_REGULAR_EXPRESSION
-"The \"cmake -i\" wizard mode is no longer supported.")
-
   # Define a set of "contract" tests, each activated by a cache entry
   # named "CMake_TEST_CONTRACT_".  For each Contract test,
   # the project should provide a directory with a CMakeLists.txt file
diff --git a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake 
b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
index 3bb2a89..cef2b9b 100644
--- a/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
+++ b/Tests/RunCMake/CommandLine/RunCMakeTest.cmake
@@ -3,6 +3,7 @@ cmake_minimum_required(VERSION 3.1)
 include(RunCMake)
 
 run_cmake_command(NoArgs ${CMAKE_COMMAND})
+run_cmake_command(Wizard ${CMAKE_COMMAND} -i)
 run_cmake_command(C-no-arg ${CMAKE_COMMAND} -C)
 run_cmake_command(C-no-file ${CMAKE_COMMAND} -C nosuchcachefile.txt)
 run_cmake_command(cache-no-file ${CMAKE_COMMAND} nosuchsubdir/CMakeCache.txt)
diff --git a/Tests/RunCMake/CommandLine/Wizard-result.txt 
b/Tests/RunCMake/CommandLine/Wizard-result.txt
new file mode 100644
index 000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Wizard-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/CommandLine/Wizard-stderr.txt 
b/Tests/RunCMake/CommandLine/Wizard-stderr.txt
new file mode 100644
index 000..f757aff
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/Wizard-stderr.txt
@@ -0,0 +1 @@
+^The "cmake -i" wizard mode is no longer supported\.

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b41b30f16e1ae2c8248321dbf51347b7a4b90d30
commit b41b30f16e1ae2c8248321dbf51347b7a4b90d30
Author: Brad King 
AuthorDate: Fri Jun 22 11:35:34 2018 -0400
Commit: Brad King 
CommitDate: Fri Jun 22 13:38:18 2018 -0400

Update use of KWSys SystemTools::SplitString for new signature

diff --git 

[Cmake-commits] CMake branch, release, updated. v3.12.0-rc1-22-g00523ad

[Kitware Robot]

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, release has been updated
   via  00523ad9c5588065b09e345e3486c15250dc4c19 (commit)
   via  3c4698da3a3c8470c8b6b1d025b10af0d5371625 (commit)
   via  b759f7068f4e263917ab029f9e9a518dfd386ddb (commit)
   via  d548994afcfccbff17fcba5698ed10f083142059 (commit)
   via  221f8aa7e28eadcc7541e16d0b5dbaa243ba7829 (commit)
   via  142a6257294afbfdf86ec13fdb4ecf303b131f99 (commit)
  from  5dc9f440c5c368ce67de52130a845bb5a5089a0e (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 -
---

Summary of changes:
 Source/cmFileCommand.cxx   | 28 +
 Source/cmGlobalVisualStudio10Generator.cxx | 49 ++
 Source/cmGlobalVisualStudio10Generator.h   |  1 +
 Source/cmGlobalVisualStudio15Generator.cxx | 21 ++
 Source/cmGlobalVisualStudio15Generator.h   |  1 +
 Source/cmVSSetupHelper.cxx | 13 ++
 Source/cmVSSetupHelper.h   | 15 +++
 .../file/GLOB-error-FOLLOW_SYMLINKS-result.txt |  1 -
 .../file/GLOB-error-FOLLOW_SYMLINKS-stderr.txt |  4 --
 ...INKS.cmake => GLOB-noexp-FOLLOW_SYMLINKS.cmake} |  0
 .../file/GLOB-noexp-LIST_DIRECTORIES-result.txt|  1 -
 .../file/GLOB-noexp-LIST_DIRECTORIES-stderr.txt|  4 --
 Tests/RunCMake/file/RunCMakeTest.cmake |  2 +-
 13 files changed, 85 insertions(+), 55 deletions(-)
 delete mode 100644 Tests/RunCMake/file/GLOB-error-FOLLOW_SYMLINKS-result.txt
 delete mode 100644 Tests/RunCMake/file/GLOB-error-FOLLOW_SYMLINKS-stderr.txt
 rename Tests/RunCMake/file/{GLOB-error-FOLLOW_SYMLINKS.cmake => 
GLOB-noexp-FOLLOW_SYMLINKS.cmake} (100%)
 delete mode 100644 Tests/RunCMake/file/GLOB-noexp-LIST_DIRECTORIES-result.txt
 delete mode 100644 Tests/RunCMake/file/GLOB-noexp-LIST_DIRECTORIES-stderr.txt


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

[Cmake-commits] CMake branch, master, updated. v3.12.0-rc1-105-gae153c6

[Kitware Robot]

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  ae153c691454ec24dbae5caa5d0e4bb2351d0886 (commit)
   via  383f29fd63e98e574606150c5f717d3298f4d5c9 (commit)
   via  3c4698da3a3c8470c8b6b1d025b10af0d5371625 (commit)
   via  b759f7068f4e263917ab029f9e9a518dfd386ddb (commit)
   via  d548994afcfccbff17fcba5698ed10f083142059 (commit)
   via  142a6257294afbfdf86ec13fdb4ecf303b131f99 (commit)
  from  8e50de4dc5c06a7a2279bc162a59e6e8ba9ca4fa (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=ae153c691454ec24dbae5caa5d0e4bb2351d0886
commit ae153c691454ec24dbae5caa5d0e4bb2351d0886
Merge: 383f29f 3c4698d
Author: Brad King 
AuthorDate: Mon Jun 25 13:53:25 2018 +
Commit: Kitware Robot 
CommitDate: Mon Jun 25 09:54:11 2018 -0400

Merge topic 'vs-filter-default-toolset'

3c4698da3a VS: Allow toolset version selection to specify default toolset
b759f7068f cmVSSetupHelper: Expose default toolset version
d548994afc cmVSSetupHelper: Use in-class member initialization

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=383f29fd63e98e574606150c5f717d3298f4d5c9
commit 383f29fd63e98e574606150c5f717d3298f4d5c9
Merge: 8e50de4 142a625
Author: Brad King 
AuthorDate: Mon Jun 25 13:53:17 2018 +
Commit: Kitware Robot 
CommitDate: Mon Jun 25 09:53:24 2018 -0400

Merge topic 'file-GLOB-remove-new-errors'

142a625729 file: Drop error cases added by CMake 3.12.0-rc1 to avoid 
regressions

Acked-by: Kitware Robot 
Acked-by: Shane Parris 
Merge-request: !2164


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c4698da3a3c8470c8b6b1d025b10af0d5371625
commit 3c4698da3a3c8470c8b6b1d025b10af0d5371625
Author: Basil Fierz 
AuthorDate: Wed Jun 20 22:34:54 2018 +0200
Commit: Brad King 
CommitDate: Sun Jun 24 10:36:03 2018 -0400

VS: Allow toolset version selection to specify default toolset

Teach the feature added by commit v3.12.0-rc1~38^2 (VS: Add option to
select the version of the toolset used by VS 2017, 2018-05-19) to accept
the default toolset version in addition to older versions.  If the
default toolset version is supplied, simply clear it so the default will
be used.

Fixes: #18107

diff --git a/Source/cmGlobalVisualStudio10Generator.cxx 
b/Source/cmGlobalVisualStudio10Generator.cxx
index 8c20313..a5709d5 100644
--- a/Source/cmGlobalVisualStudio10Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Generator.cxx
@@ -263,25 +263,32 @@ bool cmGlobalVisualStudio10Generator::SetGeneratorToolset(
   this->GeneratorToolsetVersion.clear();
 }
 
-std::string const toolsetPath = this->GetAuxiliaryToolset();
-if (!toolsetPath.empty() && !cmSystemTools::FileExists(toolsetPath)) {
-
-  std::ostringstream e;
-  /* clang-format off */
-  e <<
-"Generator\n"
-"  " << this->GetName() << "\n"
-"given toolset and version specification\n"
-"  " << this->GetPlatformToolsetString() << ",version=" <<
-this->GeneratorToolsetVersion << "\n"
-"does not seem to be installed at\n" <<
-"  " << toolsetPath;
-  ;
-  /* clang-format on */
-  mf->IssueMessage(cmake::FATAL_ERROR, e.str());
-
-  // Clear the configured tool-set
+bool const isDefaultToolset =
+  this->IsDefaultToolset(this->GeneratorToolsetVersion);
+if (isDefaultToolset) {
+  // If the given version is the default toolset, remove the setting
   this->GeneratorToolsetVersion.clear();
+} else {
+  std::string const toolsetPath = this->GetAuxiliaryToolset();
+  if (!toolsetPath.empty() && !cmSystemTools::FileExists(toolsetPath)) {
+
+std::ostringstream e;
+/* clang-format off */
+e <<
+  "Generator\n"
+  "  " << this->GetName() << "\n"
+  "given toolset and version specification\n"
+  "  " << this->GetPlatformToolsetString() << ",version=" <<
+  this->GeneratorToolsetVersion << "\n"
+  "does not seem to be installed at\n" <<
+  "  " << toolsetPath;
+;
+/* clang-format on */
+mf->IssueMessage(cmake::FATAL_ERROR, e.str());
+
+// Clear the configured tool-set
+this->GeneratorToolsetVersion.clear();
+  }
 }
   }
 
@@ -615,6 +622,12 @@ 
cmGlobalVisualStudio10Generator::GetPlatformToolsetCudaString() const
   return this->GeneratorToolsetCuda;
 }
 
+bool cmGlobalVisualStudio10Generator::IsDefaultToolset(
+  const std::string&) const
+{
+  return true;
+}
+
 

Re: [cmake-developers] cmake on AIX

[REIX, Tony]

Hi Rolf,


Thanks for your help! I have warned the MariaDB project on 
maria-develop...@lists.launchpad.net about his issue.


Séna and I are CMake and MariaDB beginners. They are new and very complex for 
us. Learning.


Thanks again !

Regards,


Tony



Date: Fri, 22 Jun 2018 14:20:48 +0200
From: Rolf Eike Beer 
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] cmake on AIX
Message-ID: 
Content-Type: text/plain; charset=US-ASCII; format=flowed

Am 2018-06-22 14:11, schrieb REIX, Tony:
> Hi Brad,
>
>
> Still investigating why MariaDB does not build.
>
>
> We have the following trace:
> ...

As Brad already said:

> I suspect mariadb's source is setting CMAKE_REQUIRED_LIBRARIES
> to a space-separated value instead of a ;-separated value.

That broken here:
https://github.com/MariaDB/server/blob/ed0b84a0270bd99b001dd00654875d26e29b9432/plugin/auth_gssapi/cmake/FindGSSAPI.cmake#L56

Report to MariaDB to fix their things.

Eike

--



Cordialement,

Tony Reix

ATOS / Bull SAS
ATOS Expert
IBM Coop Architect & Technical Leader
Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 Échirolles - France
www.atos.net
-- 

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] (no subject)

[David Henderson via CMake]

http://practice.deloresmontez.com
David Henderson

-- 

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] compiling for both python2 and python3

[Alexander Bürger]

Hi Isaiah,

that's correct and basically the reason why I need to compile two different
modules for python2 and python3. In addition, I assume that the python
minor version does not change; with that, I get some help from the package
manager.

Cheers,

Alexander Bürger
MET Norway
​
-- 

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] compiling for both python2 and python3

[Alexander Bürger]

Hello Juan,

but there are also two boost-python versions required, one for python2 and
one for python3. I think it is not a good idea to reimplement the FindBoost
logic.

Cheers,

Alexander Bürger
MET Norway
​
-- 

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