Re: [CMake] IMPORTED DLL-only Target on MSVC

[Mueller-Roemer, Johannes Sebastian]

>From the CMake side of things yes, but MSVC requires an import library. You 
>could use a tool such as Digital Mars' implib tool 
>(https://digitalmars.com/ctg/implib.html), or use dumpbin to list all exports, 
>put those in a .def file and use lib to create an import library from the def 
>file. If I am not mistaken, CMake's GNUtoMS switch (for the Mingw Makefiles 
>generator) does something like this automatically, so you could have a look at 
>how it is done there. But I assume it's simply parsing the dumpbin /exports 
>output to write a def file and running lib afterwards.

Regards,
Johannes

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de

-Original Message-
From: CMake  On Behalf Of Marek Vojtko (Firaxis)
Sent: Tuesday, April 3, 2018 00:49
To: cmake@cmake.org
Subject: [CMake] IMPORTED DLL-only Target on MSVC

Hi,

Is it not possible to wrap an external DLL-only library in an IMPORTED target?

I have an external dependency that is a single DLL (shared library) and a 
header file, but no LIB (static library) file. When I create an IMPORTED target 
and depend on it via target_link_libraries() I run into linkage issues, because 
on MSVC CMake puts the DLL into the linker command (the "Input" text field in 
the "Linker" settings of the Project Properties).

add_library( MyDependency::MyDependency MODULE IMPORTED ) 
set_target_properties( MyDependency::MyDependency
PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${MyDependency_INCLUDE_DIR}"
IMPORTED_LOCATION "${MyDependency_SHARED_LIB}"
)
[..]
add_executable( MyExecutable ... )
target_link_libraries( MyExecutable PRIVATE MyDependency::MyDependency )

I tried changing the library type in my add_library() call:
- STATIC obviously didn't work, because I don't have a .lib file and the .dll 
file in IMPORTED_LOCATION was added to MyExecutable's linker line.
- SHARED did not work because CMake expects a .dll in IMPORTED_LOCATION and a 
.lib in IMPORTED_IMP_LOCATION, so MyExecutable's linker line had a 
MyDependency::MyDependency-NOTFOUND entry in it.
- MODULE seemed like the right choice when reading the documentation, but 
MyExecutable's linker line still contains the .dll file specified in 
IMPORTED_LOCATION.

What am I doing wrong?

Thanks,
Marek

-- 

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] Link Time Code Generation (LTGC) by default, for Release configurations of Visual Studio projects?

[Mueller-Roemer, Johannes Sebastian]

This would be a great feature! Currently I override my release flags by setting 
CMAKE__FLAGS_RELEASE_INIT and CMAKE__LINKER_FLAGS_RELEASE_INIT in a 
CMAKE_USER_MAKE_RULES_OVERRIDE script. Direct support for /GL and /LTCG in 
CMake would be great. Fewer target specifics to worry about…

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de
 | www.igd.fraunhofer.de

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Cristian Adam
Sent: Wednesday, January 24, 2018 21:42
To: Niels Dekker 
Cc: cmake 
Subject: Re: [CMake] Link Time Code Generation (LTGC) by default, for Release 
configurations of Visual Studio projects?

Hi,

I had a quick check to see if CMake 3.10 for which compilers it has support for 
Interprocedural 
Optimization
 (IPO, or LTCG as known on Visual C++).

Modules/Compiler had only for GNU, Clang and PGI the following:
set(_CMAKE_${lang}_IPO_MAY_BE_SUPPORTED_BY_COMPILER YES)

QNX with QCC didn't have it set to YES even though nowdays QNX comes with GCC 
5.4.0 on QNX 7.0, which should be just fine.

It would be nice if CMake would have support for IPO on Visual C++.

The steps would be to set the right variables into 
Modules/Compiler/MSVC-CXX.cmake, change the 
CheckIPOSupported
 module, change some flags in some places,update tests, documentation, and so 
on.

Shouldn't be hard to add this feature.

Cheers,
Cristian.



On Wed, Jan 24, 2018 at 9:06 PM, Niels Dekker 
mailto:niels_dekker_address_until_2...@xs4all.nl>>
 wrote:
When a Visual C++ project is created within Visual Studio (by File menu, New, 
Project...), it has Link Time Code Generation (LTGC) by default, for its 
Release configurations: Compiler option /GL and linker option /LTCG. However, 
when the Visual C++ project is generated by CMake, it does not have LTGC, by 
default. LTCG looks like a very useful feature to me. I think it's worth 
enabling the feature by default, for Release configurations. What do you think?


Some details:

I created a "dummy" Visual C++ project in Visual Studio 2017 (Version 15.5.4), 
by File menu, New, Project..., and I also generated one by CMake (version 
3.10.2), using a very minimal CMakeLists.txt

The Visual C++ project created by Visual Studio 2017 has the following compile 
options, by default, for Release (x64):

/permissive- /GS /GL /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl 
/Fd"x64\Release\vc141.pdb" /Zc:inline /fp:precise /D "_MBCS" 
/errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" /EHsc 
/nologo /Fo"x64\Release\" /Fp"x64\Release\MyVS2015Project.pch" 
/diagnostics:classic

And the following linker options:

/OUT:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.exe" 
/MANIFEST /LTCG:incremental /NXCOMPAT 
/PDB:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pdb" 
/DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" 
"comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" 
"uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG:FULL /MACHINE:X64 /OPT:REF 
/PGD:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pgd" 
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
/ManifestFile:"x64\Release\MyVS2015Project.exe.intermediate.manifest" /OPT:ICF 
/ERRORREPORT:PROMPT /NOLOGO /TLBID:1

The vcxproj file created by Visual Studio has 
"true" for its Release 
configurations.


The Visual C++ project generated by CMake (Generator: Visual Studio 15 2017 
Win64) has the following compile options, for its Release configuration:

/GS /TP /W3 /Zc:wchar_t /Gm- /O2 /Ob2 /Fd"MyExecutable.dir\Release\vc141.pdb" 
/Zc:inline /fp:precise /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D 
"CMAKE_INTDIR=\"Release\"" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR 
/Gd /MD /Fa"Release/" /EHsc /nologo /Fo"MyExecutable.dir\Release\" 
/Fp"MyExecutable.dir\Release\MyExecutable.pch" /diagnostics:classic

And the following linker options:

/OUT:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.exe" /MANIFEST /NXCOMPAT 
/PDB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.pdb" /DYNAMICBASE 
"kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" 
"ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib" 
/IMPLIB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.lib" /MACHINE:X64 
/INCREMENTAL:NO /PGD:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.pgd" 
/SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
/ManifestFile:"MyExecutable.dir\Release\MyExecutable.exe.intermediate.manifest"
 /ERRORREPORT:PROMPT /NOLOGO /TLBID:1

The vcxproj file generated by

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Mueller-Roemer, Johannes Sebastian]

Yes


From: Robert Maynard [robert.mayn...@kitware.com]
Sent: Wednesday, September 06, 2017 6:58 PM
To: Mueller-Roemer, Johannes Sebastian
Cc: cmake@cmake.org
Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

So it works when they are separate gen-code options, but fails when they are 
combined. Is that correct?


On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
 wrote:
The long form fills the Code Generation field with 
compute_20,sm_20;compute_20,compute_20 (the default without gencode parameters 
is compute_20,sm_20) and results in the following command line:

D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU 
Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" 
-gencode=arch=compute_20,code=\"sm_20,compute_20\" 
-gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env 
--cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing 
Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing 
Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0  
--machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g   
-D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o 
A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu<http://a.cu>"

Which is somewhat redundant

MSVC turns compute_20,sm_20 into 
-gencode=arch=compute_20,code=\"sm_20,compute_20\" and compute_20,compute_20 
into -gencode=arch=compute_20,code=\"compute_20,compute_20\"


Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 
155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
 | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: Robert Maynard 
[mailto:robert.mayn...@kitware.com<mailto:robert.mayn...@kitware.com>]
Sent: Wednesday, September 6, 2017 16:44

To: Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
Cc: cmake@cmake.org<mailto:cmake@cmake.org>
Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

Yes I was responding to comment 3.

I am curious, does the longer form signature "-gencode 
arch=compute_20,code=sm_20  -gencode arch=compute_20,code=compute_20" work 
correctly? CMake has to parse the gencode flags and move them to special 
msbuild entries, and I wonder if there is a bug when parsing multiple code 
options.

On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
 wrote:
If the comment is wrt 3., the result is the same no matter if I use a space or 
an equals sign, if I double escape the quotes (e.g., use the value as you wrote 
it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS becomes 
compute_20,"sm_20,compute_20" instead of compute_20,sm_20,compute_20, which is 
equally illegal and will cause the same error message, also double escaping 
should not be necessary for a subset of flags (Xcompiler works fine without it, 
even if the default values are pointless).
If the comment is wrt 2., this is the line automatically generated by CMake/VS 
when not passing in any gencode flags explicitly.

Or am I misunderstanding what you mean?

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 
155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
 | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: Robert Maynard 
[mailto:robert.mayn...@kitware.com<mailto:robert.mayn...@kitware.com>]
Sent: Wednesday, September 6, 2017 15:38
To: Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
Cc: cmake@cmake.org<mailto:cmake@cmake.org>
Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

As far as gencode goes, your line has errors. With CUDA 8 it should look like:

-gencode arch=compute_20,code=\"sm_20,compute_20\"



On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
 wrote:
I’m having two issues with debug symbols for CUDA libraries on a project:


1.   The PDBs are not placed where the linker later expects to find them 
(haven’t been able to replicate this in a minimal project yet)

2.   Trying to circumnavigate this issue by using “/Z7” instead of “/Zi” 
does not work, Zi is always used (replicable in any project with CUDA)

Repli

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Mueller-Roemer, Johannes Sebastian]

The long form fills the Code Generation field with 
compute_20,sm_20;compute_20,compute_20 (the default without gencode parameters 
is compute_20,sm_20) and results in the following command line:

D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU 
Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" 
-gencode=arch=compute_20,code=\"sm_20,compute_20\" 
-gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env 
--cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing 
Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing 
Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0  
--machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g   
-D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o 
A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu"

Which is somewhat redundant

MSVC turns compute_20,sm_20 into 
-gencode=arch=compute_20,code=\"sm_20,compute_20\" and compute_20,compute_20 
into -gencode=arch=compute_20,code=\"compute_20,compute_20\"


Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
 | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: Robert Maynard [mailto:robert.mayn...@kitware.com]
Sent: Wednesday, September 6, 2017 16:44
To: Mueller-Roemer, Johannes Sebastian 

Cc: cmake@cmake.org
Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

Yes I was responding to comment 3.

I am curious, does the longer form signature "-gencode 
arch=compute_20,code=sm_20  -gencode arch=compute_20,code=compute_20" work 
correctly? CMake has to parse the gencode flags and move them to special 
msbuild entries, and I wonder if there is a bug when parsing multiple code 
options.

On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
 wrote:
If the comment is wrt 3., the result is the same no matter if I use a space or 
an equals sign, if I double escape the quotes (e.g., use the value as you wrote 
it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS becomes 
compute_20,"sm_20,compute_20" instead of compute_20,sm_20,compute_20, which is 
equally illegal and will cause the same error message, also double escaping 
should not be necessary for a subset of flags (Xcompiler works fine without it, 
even if the default values are pointless).
If the comment is wrt 2., this is the line automatically generated by CMake/VS 
when not passing in any gencode flags explicitly.

Or am I misunderstanding what you mean?

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 
155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
 | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: Robert Maynard 
[mailto:robert.mayn...@kitware.com<mailto:robert.mayn...@kitware.com>]
Sent: Wednesday, September 6, 2017 15:38
To: Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
Cc: cmake@cmake.org<mailto:cmake@cmake.org>
Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

As far as gencode goes, your line has errors. With CUDA 8 it should look like:

-gencode arch=compute_20,code=\"sm_20,compute_20\"



On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
 wrote:
I’m having two issues with debug symbols for CUDA libraries on a project:


1.   The PDBs are not placed where the linker later expects to find them 
(haven’t been able to replicate this in a minimal project yet)

2.   Trying to circumnavigate this issue by using “/Z7” instead of “/Zi” 
does not work, Zi is always used (replicable in any project with CUDA)

Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by -Z7 
or /Z7. Build and see several warnings like “cl : Command line warning D9025: 
overriding '/Z7' with '/Zi'” in the output window.
And do the flags in the –Xcompiler make sense at all in VS? The CUDA build 
tools seem to determine these automatically anyways… for example I get the 
following call in the above scenario:

"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" 
-gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 
2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64"  

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Mueller-Roemer, Johannes Sebastian]

If the comment is wrt 3., the result is the same no matter if I use a space or 
an equals sign, if I double escape the quotes (e.g., use the value as you wrote 
it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS becomes 
compute_20,"sm_20,compute_20" instead of compute_20,sm_20,compute_20, which is 
equally illegal and will cause the same error message, also double escaping 
should not be necessary for a subset of flags (Xcompiler works fine without it, 
even if the default values are pointless).
If the comment is wrt 2., this is the line automatically generated by CMake/VS 
when not passing in any gencode flags explicitly.

Or am I misunderstanding what you mean?

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
 | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: Robert Maynard [mailto:robert.mayn...@kitware.com]
Sent: Wednesday, September 6, 2017 15:38
To: Mueller-Roemer, Johannes Sebastian 

Cc: cmake@cmake.org
Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

As far as gencode goes, your line has errors. With CUDA 8 it should look like:

-gencode arch=compute_20,code=\"sm_20,compute_20\"



On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
 wrote:
I’m having two issues with debug symbols for CUDA libraries on a project:


1.   The PDBs are not placed where the linker later expects to find them 
(haven’t been able to replicate this in a minimal project yet)

2.   Trying to circumnavigate this issue by using “/Z7” instead of “/Zi” 
does not work, Zi is always used (replicable in any project with CUDA)

Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by -Z7 
or /Z7. Build and see several warnings like “cl : Command line warning D9025: 
overriding '/Z7' with '/Zi'” in the output window.
And do the flags in the –Xcompiler make sense at all in VS? The CUDA build 
tools seem to determine these automatically anyways… for example I get the 
following call in the above scenario:

"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" 
-gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 
2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64"  
-I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" 
-I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include"  -G   
--keep-dir x64\Debug -maxrregcount=0  --machine 64 --compile -cudart static 
-Xcompiler="/EHsc -Z7 -Ob0" -g   -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od 
/FS /Zi /RTC1 /MDd /GR" -o A.dir\Debug\a.cu.obj 
"D:\jsroemer\projects\cuda-pdb-test\a\a.cu<http://a.cu>"

3.   Also, -gencode flags do not behave as expected when given in the form 
-gencode=arch=compute_20,code="sm_20,compute_20", as this causes the VS build 
system to error out:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\CUDA 
8.0.targets(216,9): error : Item '..\..\a\a.cu<http://a.cu>' Code Generation 
value is not in the expected format '[Arch],[Code]'.

The code generation value in this example is set to compute_20,sm_20,compute_20 
by CMake.

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 
155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
 | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>


--

Powered by www.kitware.com<http://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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Mueller-Roemer, Johannes Sebastian]

I'm having two issues with debug symbols for CUDA libraries on a project:


1.   The PDBs are not placed where the linker later expects to find them 
(haven't been able to replicate this in a minimal project yet)

2.   Trying to circumnavigate this issue by using "/Z7" instead of "/Zi" 
does not work, Zi is always used (replicable in any project with CUDA)

Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by -Z7 
or /Z7. Build and see several warnings like "cl : Command line warning D9025: 
overriding '/Z7' with '/Zi'" in the output window.
And do the flags in the -Xcompiler make sense at all in VS? The CUDA build 
tools seem to determine these automatically anyways... for example I get the 
following call in the above scenario:

"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" 
-gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 
2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64"  
-I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" 
-I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include"  -G   
--keep-dir x64\Debug -maxrregcount=0  --machine 64 --compile -cudart static 
-Xcompiler="/EHsc -Z7 -Ob0" -g   -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od 
/FS /Zi /RTC1 /MDd /GR" -o A.dir\Debug\a.cu.obj 
"D:\jsroemer\projects\cuda-pdb-test\a\a.cu"

3.   Also, -gencode flags do not behave as expected when given in the form 
-gencode=arch=compute_20,code="sm_20,compute_20", as this causes the VS build 
system to error out:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\CUDA 
8.0.targets(216,9): error : Item '..\..\a\a.cu' Code Generation value is not in 
the expected format '[Arch],[Code]'.

The code generation value in this example is set to compute_20,sm_20,compute_20 
by CMake.

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de
 | www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Future direction for FindCUDA

[Mueller-Roemer, Johannes Sebastian]

Hi,

we have encountered this issue as well, in our case when using thrust on the 
host side. We currently solve this by still using FindCUDA, even when using 
CMake 3.8/3.9, but only using the CUDA_*_LIBRARY and CUDA_TOOLKIT_INCLUDE 
variables and nothing else.

Instead of modifying what FindCUDA does, which would break backwards 
compatibility, FindCUDA could be split into FindCUDA and FindCUDALibraries or 
something like that.

Regards
Johannes

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Siyuan Liu
Sent: Wednesday, August 30, 2017 07:05
To: cmake@cmake.org
Subject: [CMake] Future direction for FindCUDA

Dear all,

I've noticed the change to CUDA as a language in CMake 3.8. I've migrated to 
this new syntax, but this change leads to some difficulties for me with CMake. 
I think we should treat CUDA as not just a language but rather a language with 
some libraries. 

Now that the FindCUDA module is deprecated, I cannot compile a file with GCC 
while linking to a CUDA library (since the CUDA_xxx_LIBRARY variables are 
gone). The reason for not using NVCC is to save compilation time. Personally, I 
think FindCUDA should become a module for purely finding CUDA libraries for 
linking without anything related to the NVCC compiler (e.g. the 
cuda_add_executable macro).

My questions in short:
1. Can I link to CUDA libraries with GCC while not using FindCUDA?
2. What's your opinion on my suggestion about FindCUDA?

Regards,
Siyuan
-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Yet another CMake 3.9 CUDA issue

[Mueller-Roemer, Johannes Sebastian]

I attached the -system-information output for the build. I was not able to 
glean anything useful from it though, as CMakeError.log is empty, as previously 
mentioned.

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
 | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Mueller-Roemer, 
Johannes Sebastian
Sent: Monday, August 7, 2017 09:28
To: cmake@cmake.org
Subject: [CMake] Yet another CMake 3.9 CUDA issue

Hi,

after solving a different issue (lack of .NET 3.5 Framework causing the CUDA 
MSBuild component to not work, discussion thread "Visual Studio with CUDA does 
not work in 3.9") and getting good results (parallel CUDA builds, yay!), I now 
wanted to try CMake 3.9 on a different machine, but no success :(

The machine is running Windows Server 2012 R2 with Visual Studio 2015 (2012 is 
installed as well). The CUDA SDK is installed in versions 7.5 and 8.0. .Net 3.5 
is installed as well. However, the following error is reported:

CMake Error at 
E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:247 
(message):
  No CUDA toolset found.
Call Stack (most recent call first):
  E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:31 
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  
E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCUDACompiler.cmake:73 
(CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "C:/Users/buildbot/Desktop/test/build/CMakeFiles/CMakeOutput.log".

The CMakeOutput.log is also not very informative and only contains:
The system is: Windows - 6.3.9600 - AMD64

Regards
Johannes Mueller-Roemer

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
 | www.igdfraunhofer.de<http://www.igd.fraunhofer.de>

Avoid ctest truncation of output: CTEST_FULL_OUTPUT

=== MAIN VARIABLES

CMAKE_STATIC_LIBRARY_PREFIX == ""
CMAKE_STATIC_LIBRARY_SUFFIX == ".lib"
CMAKE_SHARED_LIBRARY_PREFIX == ""
CMAKE_SHARED_LIBRARY_SUFFIX == ".dll"
CMAKE_SHARED_MODULE_PREFIX == ""
CMAKE_SHARED_MODULE_SUFFIX == ".dll"


CMAKE_DL_LIBS == ""
CMAKE_LIBRARY_PATH_FLAG == "-LIBPATH:"
CMAKE_LINK_LIBRARY_FLAG == ""
CMAKE_SKIP_RPATH == "NO"
CMAKE_SYSTEM_INFO_FILE == "Platform/Windows"
CMAKE_SYSTEM_NAME == "Windows"
CMAKE_SYSTEM == "Windows-6.3.9600"
CMAKE_CXX_COMPILER == "C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/x86_amd64/cl.exe"
CMAKE_C_COMPILER == "C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/x86_amd64/cl.exe"
CMAKE_COMPILER_IS_GNUCC == ""
CMAKE_COMPILER_IS_GNUCXX == ""

// C shared library flag
CMAKE_SHARED_LIBRARY_C_FLAGS == ""
CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS == "-shared"
CMAKE_SHARED_LIBRARY_LINK_FLAGS == ""
CMAKE_SHARED_LIBRARY_RUNTIME_FLAG == ""
CMAKE_SHARED_LIBRARY_RUNTIME_FLAG_SEP == ""
CMAKE_SHARED_LIBRARY_LINK_STATIC_C_FLAGS == ""
CMAKE_SHARED_LIBRARY_LINK_DYNAMIC_C_FLAGS == ""

// C shared module flags
CMAKE_SHARED_MODULE_C_FLAGS  == ""
CMAKE_SHARED_MODULE_CREATE_C_FLAGS == "-shared"
CMAKE_SHARED_MODULE_LINK_STATIC_C_FLAGS == ""
CMAKE_SHARED_MODULE_LINK_DYNAMIC_C_FLAGS == ""

// C exe flags
CMAKE_EXE_LINK_STATIC_C_FLAGS == ""
CMAKE_EXE_LINK_DYNAMIC_C_FLAGS == ""

// CXX shared library flags
CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS == "-shared"
CMAKE_SHARED_LIBRARY_CXX_FLAGS == ""
CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS == ""
CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG == ""
CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG_SEP == ""
CMAKE_SHARED_LIBRARY_LINK_STATIC_CXX_FLAGS == ""
CMAKE_SHARED_LIBRARY_LINK_DYNAMIC_CXX_FLAGS == ""

// CXX shared module flags
CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS == "-shared"
CMAKE_SHARED_MODULE_CXX_FLAGS == ""
CMAKE_SHARED_MODULE_LINK_STATIC_CXX_FLAGS == ""
CMAKE_SHARED_MODULE_LINK_DYNAMIC_CXX_FLAGS == ""

// CXX exe flags
CMAKE_EXE_LINK_STATIC_CXX_FLAGS == ""
CMAKE_EXE_LINK_DYNAMIC_CXX_FLAGS == ""

CMAKE_USER_MAKE_RULES_OVERRIDE == ""
CMAKE_VERBOSE_MAKEFILE == "FALSE"
CMAKE_BUILD_TYPE == ""
CMAKE_CXX_FLAGS == "/DWIN32 /D_

[CMake] Yet another CMake 3.9 CUDA issue

[Mueller-Roemer, Johannes Sebastian]

Hi,

after solving a different issue (lack of .NET 3.5 Framework causing the CUDA 
MSBuild component to not work, discussion thread "Visual Studio with CUDA does 
not work in 3.9") and getting good results (parallel CUDA builds, yay!), I now 
wanted to try CMake 3.9 on a different machine, but no success :(

The machine is running Windows Server 2012 R2 with Visual Studio 2015 (2012 is 
installed as well). The CUDA SDK is installed in versions 7.5 and 8.0. .Net 3.5 
is installed as well. However, the following error is reported:

CMake Error at 
E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:247 
(message):
  No CUDA toolset found.
Call Stack (most recent call first):
  E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:31 
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  
E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCUDACompiler.cmake:73 
(CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "C:/Users/buildbot/Desktop/test/build/CMakeFiles/CMakeOutput.log".

The CMakeOutput.log is also not very informative and only contains:
The system is: Windows - 6.3.9600 - AMD64

Regards
Johannes Mueller-Roemer
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de
 | www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] What is the default build type?

[Mueller-Roemer, Johannes Sebastian]

Exactly. Also, CMAKE_CONFIGURATION_TYPES uses the CamelCase Versions by 
default, so if your CMake code breaks with that spelling, your CMakeLists.txt 
can be considered broken anyways...

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Marcus D. Hanwell
Sent: Thursday, August 3, 2017 16:25
To: J Decker 
Cc: cmake@cmake.org
Subject: Re: [CMake] What is the default build type?

On Wed, Aug 2, 2017 at 4:18 PM, J Decker  wrote:
>
> On Wed, Aug 2, 2017 at 8:55 AM, Marcus D. Hanwell 
>  wrote:
>>
>> On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou  wrote:
>>>
>>> It depends on the Generator.
>>>
>>> To the Makefile, the actual type was controlled by the compiler options. If 
>>> you don't specific any type, usually it means non-debug and 
>>> non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is 
>>> critical, so usually people should specific the actual type they want to 
>>> build.
>>>
>>> To the generator of the IDE, such as Visual Studio and Xcode, the 
>>> CMAKE_BUILD_TYPE doesn't make sense but we have to use 
>>> CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration 
>>> sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} .
>>
>>
>> This thread inspired me to write up how we have been doing it in some 
>> of the projects I work on for quite a while now,
>>
>> https://blog.kitware.com/cmake-and-the-default-build-type/
>>
> These should use lower case 'debug' 'release' etc.  Because if it's not VS, 
> it's probably also not windows, and case matters.
>
No, camel case works just fine. I took a quick look and lowercase will work, as 
well as all caps. I have used this for many years on Linux builds with 
Makefile/Ninja without issue.
-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Visual Studio with CUDA does not work in 3.9

[Mueller-Roemer, Johannes Sebastian]

If anyone else runs into this issue: I was able to solve it by re-installing 
the .NET 3.5 Framework which a recent Update had apparently removed (because I 
have previously built "native" CUDA VS projects on this machine without issues).

This solved the issue for me. If you have an error message like

error MSB4062: The "Nvda.Build.CudaTasks.SanitizePaths" task could not be 
loaded from the assembly C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\Nvda.Build.CudaTasks.v8.0.dll.
Could not load file or assembly 'Microsoft.Build.Utilities.v3.5, 
Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of 
its dependencies. The system cannot find the file specified.
Confirm that the  declaration is correct, that the assembly and all 
its dependencies are available, and that the task contains a public class that 
implements

in your cmake error log, you are running into the same issue.

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de


-Original Message-
From: Robert Maynard [mailto:robert.mayn...@kitware.com] 
Sent: Friday, June 23, 2017 15:40
To: Mueller-Roemer, Johannes Sebastian 

Cc: CMake MailingList 
Subject: Re: [CMake] Visual Studio with CUDA does not work in 3.9

Hi

Unfortunately you are going to need to provide more information to help track 
down the issue. We currently have machines that verify
2015/8.0 and 2013/7.5 properly work (
https://open.cdash.org/index.php?project=CMake&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=CUDA
)

Can you please provide run from the build directory cmake --system-information 
 and send the results?

On Fri, Jun 23, 2017 at 9:11 AM, Mueller-Roemer, Johannes Sebastian 
 wrote:
> Hi Robert,
>
> yes, according to the Windows installed program list, I have "NVIDIA CUDA 
> Visual Studio Integration 8.0" installed. I can also create CUDA projects via 
> "New project" and have an Nsight menu entry.
>
> Regards
> Johannes Mueller-Roemer
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD 
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany Tel +49 6151 155-606  
> |  Fax +49 6151 155-139 johannes.mueller-roe...@igd.fraunhofer.de | 
> www.igd.fraunhofer.de
>
>
> -Original Message-----
> From: Robert Maynard [mailto:robert.mayn...@kitware.com]
> Sent: Friday, June 23, 2017 14:52
> To: Mueller-Roemer, Johannes Sebastian 
> 
> Cc: CMake MailingList 
> Subject: Re: [CMake] Visual Studio with CUDA does not work in 3.9
>
> Hi,
>
> Do you have the NVIDIA CUDA Visual Studio Integration tools installed?
> This is needed for support when using the Visual Studio Generator(s).
> Otherwise you can still use ninja or the nmake generators.
>
> On Fri, Jun 23, 2017 at 7:06 AM, Mueller-Roemer, Johannes Sebastian 
>  wrote:
>> The absolute minimum example
>>
>>
>>
>> cmake_minimum_required(VERSION 3.9 FATAL_ERROR)
>>
>> project(cuda-test LANGUAGES C CXX CUDA)
>>
>> add_executable(cuda-test main.cu)
>>
>>
>>
>> Fails to configure with the error:
>>
>> CMake Error at CMakeLists.txt:2 (project):
>>
>>   No CMAKE_CUDA_COMPILER could be found.
>>
>>
>>
>> Am I missing something, or is the support mentioned in the change 
>> list simply not true?
>>
>>
>>
>> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>>
>> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>>
>> Tel +49 6151 155-606  |  Fax +49 6151 155-139
>>
>> johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
>>
>>
>>
>>
>> --
>>
>> 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:
>> http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Visual Studio with CUDA does not work in 3.9

[Mueller-Roemer, Johannes Sebastian]

Hi Robert,

yes, according to the Windows installed program list, I have "NVIDIA CUDA 
Visual Studio Integration 8.0" installed. I can also create CUDA projects via 
"New project" and have an Nsight menu entry.

Regards
Johannes Mueller-Roemer

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de


-Original Message-
From: Robert Maynard [mailto:robert.mayn...@kitware.com] 
Sent: Friday, June 23, 2017 14:52
To: Mueller-Roemer, Johannes Sebastian 

Cc: CMake MailingList 
Subject: Re: [CMake] Visual Studio with CUDA does not work in 3.9

Hi,

Do you have the NVIDIA CUDA Visual Studio Integration tools installed?
This is needed for support when using the Visual Studio Generator(s).
Otherwise you can still use ninja or the nmake generators.

On Fri, Jun 23, 2017 at 7:06 AM, Mueller-Roemer, Johannes Sebastian 
 wrote:
> The absolute minimum example
>
>
>
> cmake_minimum_required(VERSION 3.9 FATAL_ERROR)
>
> project(cuda-test LANGUAGES C CXX CUDA)
>
> add_executable(cuda-test main.cu)
>
>
>
> Fails to configure with the error:
>
> CMake Error at CMakeLists.txt:2 (project):
>
>   No CMAKE_CUDA_COMPILER could be found.
>
>
>
> Am I missing something, or is the support mentioned in the change list 
> simply not true?
>
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>
> Tel +49 6151 155-606  |  Fax +49 6151 155-139
>
> johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
>
>
>
>
> --
>
> 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:
> http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Visual Studio with CUDA does not work in 3.9

[Mueller-Roemer, Johannes Sebastian]

The absolute minimum example

cmake_minimum_required(VERSION 3.9 FATAL_ERROR)
project(cuda-test LANGUAGES C CXX CUDA)
add_executable(cuda-test main.cu)

Fails to configure with the error:
CMake Error at CMakeLists.txt:2 (project):
  No CMAKE_CUDA_COMPILER could be found.

Am I missing something, or is the support mentioned in the change list simply 
not true?

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de
 | www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Force MSVC runtime for debug builds

[Mueller-Roemer, Johannes Sebastian]

I agree that CMake should not be defining _DEBUG explicitly, as it is used by 
Microsoft’s headers to match the chosen runtime.
Maybe this warrants a bug report on gitlab.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Kim Kryger
Sent: Monday, November 14, 2016 22:05
To: Stephan Menzel 
Cc: cmake 
Subject: Re: [CMake] Force MSVC runtime for debug builds

I ran into this today. I tried to use /MD to link against a custom md library, 
but because _DEBUG was defined *by CMake* I couldn't use it out of the box.

Why is CMake defining _DEBUG for MSVC projects anyways? _DEBUG is automatically 
defined when using /MDd, and I don't believe it should be defining it itself. 
I've had to remove it for multiple projects because it's making assumptions as 
to what I want defined.


Default for CMAKE_CXX_FLAGS_DEBUG_INIT
/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1

I don't think that first define should be there.


Reference:
https://github.com/Kitware/CMake/blob/5d29506811c5b75ae48e12de6c317f6440874215/Modules/Platform/Windows-MSVC.cmake#L294
https://msdn.microsoft.com/en-us/library/0b98s6w8.aspx


On Fri, Nov 11, 2016 at 9:42 AM, Stephan Menzel 
mailto:stephan.men...@gmail.com>> wrote:

On Tue, Nov 8, 2016 at 4:21 PM, 
mailto:clin...@elemtech.com>> wrote:
If you are going to use /MD instead of /MDd, then you probably also need to 
remove the _DEBUG preprocessor flag.
IIRC, I've seen cases where defining _DEBUG includes symbols only defined by 
the debug runtimes.

Clint

What a surprise. Removing _DEBUG did the trick. I was under the impression 
_DEBUG only controls Microsoft STL impl's debug iterator stuff but apparently 
it also makes the resulting exe link with /MD rather than /MDd. Guess that was 
wrong.

So yes, problem solved.

Thank you!

Stephan

--

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] add_subdirectory with EXCLUDE_FROM_ALL and cmake --build (Visual Studio)

[Mueller-Roemer, Johannes Sebastian]

I just noticed the following issue:

If I do an add_subdirectory([...] EXCLUDE_FROM_ALL) and generate a VS (2015) 
solution, projects added in that subdirectory generate an entirely separate 
solution (and therefore do not appear in the main solution at all) in the 
corresponding binary dir subfolder. This causes a cmake -build 
${CMAKE_BINARY_DIR} to fail, unlike other generators. Is this intended 
behavior? It seems odd not to have the targets in the same solution at all

Johannes Mueller-Roemer

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de
 | www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Using Clang + Ninja on Windows?

[Mueller-Roemer, Johannes Sebastian]

It is true that there is no official bundled installer with both, but the 
official installer works just fine with mingw as long as you pass in the 
correct target to clang(++)

For example
clang++ --target=x86_64-w64-mingw32 test.cpp

However, it assumes that mingw64 is installed under C:/mingw64 (the default 
location, it’ll work with a junction point though).


From: Cristian Adam [mailto:cristian.a...@gmail.com]
Sent: Friday, April 22, 2016 09:15
To: Mueller-Roemer, Johannes Sebastian 

Cc: cmake@cmake.org
Subject: Re: [CMake] Using Clang + Ninja on Windows?

On Fri, Apr 22, 2016 at 8:59 AM, Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
 wrote:
You are mistaken, Clang absolutely also works with MinGW. Or it did at least up 
to 3.7 (didn’t get around to trying 3.8 yet)


Clang works fine with libstdc++ on Linux and Cygwin, there should be no reason 
why it shouldn't work with MinGW.

What I should have wrote was that Clang on Windows officially supports only a 
Visual C++ setup / Visual Studio integration.

I don't think I have seen a package containing clang and libstdc++ from MinGW.

Cheers,
Cristian.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Using Clang + Ninja on Windows?

[Mueller-Roemer, Johannes Sebastian]

You are mistaken, Clang absolutely also works with MinGW. Or it did at least up 
to 3.7 (didn’t get around to trying 3.8 yet)

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Cristian Adam
Sent: Thursday, April 21, 2016 23:30
To: Johan Holmberg 
Cc: cmake@cmake.org
Subject: Re: [CMake] Using Clang + Ninja on Windows?


On Wed, Apr 20, 2016 at 4:01 PM, Johan Holmberg 
mailto:johan...@gmail.com>> wrote:
Hi!
How should I setup CMake to build a C/C++ application on Windows using 
clang/clang++ as compilers and Ninja as build tool?
I tried specifying "-GNinja" to cmake, and setting CC/CXX to clang/clang++. But 
this didn't work. I get errors like:

  clang.exe: error: no such file or directory: '/nologo'
indicating that CMake thinks it should pass Visual C++ style options to clang.
I'm thinking about fooling CMake that clang/clang++ are cross compilers (I know 
how to get cross compiling working in other cases). But since clang/clang++ are 
the native tools for Windows, I was hoping to be able to use Clang + Ninja on 
Windows almost like I use on Linux.
If I run Clang from the command line, I can build my application, so my 
Clang-installation works.

I'm using CMake 3.5.1 and Clang 3.8.0.
/Johan Holmberg

Hi,

On Windows Clang works only with Visual C++, since they don't provide libc++. 
MinGW is not supported.
Clang provides a Visual C++'s cl.exe replacement.

You need to have the official 
windows Clang and Visual C++ 
Express or Community installed.

Then it's just a matter of:
1.   Opening a Visual C++ 2013 64 bit command prompt window
2.   Putting clang's cl.exe in the path and setting clang's INCLUDE path 
first

set PATH=c:\Program Files\LLVM\msbuild-bin\;%PATH%
set INCLUDE=c:\Program Files\LLVM\lib\clang\3.8.0\include\;%INCLUDE%
3.   cmake -G "Ninja"
4.   Ninja
CMake / Ninja will think that they compile with Visual C++, but instead will 
use clang.

Note that you have to match Visual C++ and Clang's build, 32 or 64 bit. You 
can't mix them,
or you'll have weird 
errors.

Cheers,
Cristian.

P.S. This is actually a re-post, this time adding the mailing list.
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Can't get CMake to use an import library generated from a MODULE target

[Mueller-Roemer, Johannes Sebastian]

Why are you trying to link a MODULE? The add_library should be changed to 
SHARED not MODULE.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Sam Habiel
Sent: Thursday, February 18, 2016 09:45
To: cmake@cmake.org
Subject: [CMake] Can't get CMake to use an import library generated from a 
MODULE target

Rather than email one of the folks at Kitware, I decided to join the CMake 
mailing list... Hello all for those who remember me.

I apologize for the long email.

A few of us have been trying to port GT.M
(https://www.fisglobal.com/Solutions/Services/Database-Engine) to Cygwin, 1. to 
get it running on Windows 2. as an exercise to prepare for harder ports, the 
Raspberry Pi being the holy grail here. That's the background.

The problem we are having is familiar to many; but not initially to me. See the 
heading "Shared libraries with Windows/MinGW" in this
article: 
http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/.

CMakeLists.txt:
https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt

The error:
[ 88%] Linking C shared module plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o:
In function `gc_load_gtmshr_symbols':
/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:100: undefined reference to 
`gtm_malloc'
/home/sam/fis-gtm-cygwin/sr_unix/gtmcrypt_util.c:101: undefined reference to 
`gtm_free'
collect2: error: ld returned 1 exit status
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/build.make:202: recipe for 
target 'plugin/cyggtmcrypt_gcrypt_AES256CFB.dll' failed
make[2]: *** [plugin/cyggtmcrypt_gcrypt_AES256CFB.dll] Error 1
CMakeFiles/Makefile2:891: recipe for target 
'CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all' failed
make[1]: *** [CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

Here's the link command (I turned CMAKE_VERBOSE_MAKEFILE=ON):
/usr/bin/cc   -march=i586 -fsigned-char -Wmissing-prototypes
-Wreturn-type -Wpointer-sign -fno-omit-frame-pointer -g -DDEBUG -shared 
-Wl,--enable-auto-import -o plugin/cyggtmcrypt_gcrypt_AES256CFB.dll
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_pk_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_dbk_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_sym_ref.c.o
CMakeFiles/libgtmcrypt_gcrypt_AES256CFB.so.dir/sr_unix/gtmcrypt_util.c.o
-lgpg-error -lgpgme -lgcrypt /usr/local/lib/libconfig.dll.a

What is missing is that there needs to be either a link to cyggtmshr.dll, or a 
way for CMake to know to generate a libgtmshr_import.lib and add it to the link 
command.

So here is what I tried:
1. Using the GenerateExportHeader functionality of CMake on libgtmshr.
If I do that, it doesn't seem to generate the import library; but it sure does 
generate an export header, which I don't need. Here it is:
include(GenerateExportHeader)
generate_export_header(libgtmshr
BASE_NAME libgtmshr
EXPORT_MACRO_NAME libgtmshr_EXPORTS
EXPORT_FILE_NAME  libgtmshr_EXPORTS.h
STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)

2. Explicitly adding a libgtmshr as a dependency on line 
https://github.com/shabiel/fis-gtm/blob/cygwin/CMakeLists.txt#L531,
but only for Cygwin. I get this error message:
CMake Error at CMakeLists.txt:542 (target_link_libraries):
  Target "libgtmshr" of type MODULE_LIBRARY may not be linked into another
  target.  One may link only to STATIC or SHARED libraries, or to executables
  with the ENABLE_EXPORTS property set.

The GT.M developer familiar with CMake suggested me to use LINK_FLAGS and have 
CMake use the file by us hardcoding it in; which I am okay doing, but I thought 
I would check to see if there is an alternative way of doing this.

I also tried the suggestions here:
"https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/";
to no avail.

Last, but not least:

sam@horus ~/fis-gtm-cygwin
$ cmake --version
cmake version 3.4.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

sam@horus ~/fis-gtm-cygwin
$ uname -a
CYGWIN_NT-10.0-WOW horus 2.2.0(0.289/5/3) 2015-08-03 12:49 i686 Cygwin

--
Sam Habiel, Pharm.D.
VISTA Expertise Network
-- 

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 
informat

Re: [CMake] Problems with transitive dependencies

[Mueller-Roemer, Johannes Sebastian]

You are evaluating those properties at the wrong time. Transitive properties 
are not passed on at configure time (they can’t be), but at generation time. 
Therefore to debug those values you will have to use generator expressions 
(except they don’t work for link_libraries). Or just look at the generated 
project…

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Chris Wilson
Sent: Monday, December 07, 2015 20:43
To: cmake@cmake.org
Subject: [CMake] Problems with transitive dependencies

Dear CMake users,

I'm trying to use CMake to replace the complex hand-built Visual Studio 
configuration of our open source project, Box Backup. And I'm having trouble 
making it generate the correct transitive dependencies between modules, 
particularly for include directories.

We have a lot of modules whose header files need to be part of the public 
interface to link to these modules. I thought from the manual that "The usage 
requirements of a target can transitively propagate to dependents" but I can't 
make it work (for anything except link libraries).

Here is a toy example taken from the manual:

add_library(archive archive.cpp)
target_compile_definitions(archive PUBLIC USING_ARCHIVE_LIB)

add_library(serialization serialization.cpp)
target_compile_definitions(serialization INTERFACE USING_SERIALIZATION_LIB)

add_library(archiveExtras extras.cpp)
target_link_libraries(archiveExtras PUBLIC archive)
target_link_libraries(archiveExtras PRIVATE serialization)
# archiveExtras is compiled with -DUSING_ARCHIVE_LIB
# and -DUSING_SERIALIZATION_LIB

add_executable(consumer consumer.cpp)
# consumer is compiled with -DUSING_ARCHIVE_LIB
target_link_libraries(consumer archiveExtras)

My understanding is that the target_compile_definitions are part of the public 
interface of the archive module, and should be added to anything that links to 
it, which archiveExtras does. But if I add some debugging messages after the 
above code:

foreach (lib archive serialization archiveExtras consumer)
  get_property(ill TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
  get_property(ll TARGET ${lib} PROPERTY LINK_LIBRARIES)
  get_property(icd TARGET ${lib} PROPERTY INTERFACE_COMPILE_DEFINITIONS)
  get_property(cd TARGET ${lib} PROPERTY COMPILE_DEFINITIONS)
  message(STATUS "${lib}: INTERFACE_LINK_LIBRARIES = \"${ill}\" "
"LINK_LIBRARIES = \"${ll}\"")
  message(STATUS "${lib}: INTERFACE_COMPILE_DEFINITIONS = \"${icd}\" "
"COMPILE_DEFINITIONS = \"${cd}\"")
endforeach()

I can see that archiveExtras inherits the link libraries of archive, but not 
its compile_definitions (nor the include directories if I try to inherit them 
instead):

-- archive: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = ""
-- archive: INTERFACE_COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB" 
COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB"

-- serialization: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = ""
-- serialization: INTERFACE_COMPILE_DEFINITIONS = "USING_SERIALIZATION_LIB" 
COMPILE_DEFINITIONS = ""

-- archiveExtras: INTERFACE_LINK_LIBRARIES = 
"archive;$" LINK_LIBRARIES = "archive;serialization"
-- archiveExtras: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = ""

-- consumer: INTERFACE_LINK_LIBRARIES = "archiveExtras" LINK_LIBRARIES = 
"archiveExtras"
-- consumer: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = ""

The COMPILE_DEFINITIONS of archiveExtras is empty; it has not inherited 
anything.

The manual says:

Because archive is a PUBLIC dependency of archiveExtras, the usage requirements 
of it are propagated to consumer too. Because serialization is a PRIVATE 
dependency of archive, the usage requirements of it are not propagated to 
consumer...

"Usage requirements are propagated by reading the INTERFACE_ variants of target 
properties from dependencies and appending the values to the non-INTERFACE_ 
variants of the operand. For example, the INTERFACE_INCLUDE_DIRECTORIES of 
dependencies is read and appended to the INCLUDE_DIRECTORIES of the operand."

I would assume that the same happens for COMPILE_DEFINITIONS: it should be 
copied from the INTERFACE_COMPILE_DEFINITIONS of the dependencies. But this 
doesn't appear to be happening, as far as I can tell. Nor is the "consumer 
compiled with -DUSING_ARCHIVE_LIB", contrary to the comment (at least it's not 
in the COMPILE_DEFINITIONS).

Can anyone tell me what I'm doing wrong? Specifiying "dependencies" the wrong 
way? I would really appreciate some help :) Do I have to hard-code or script 
all the transitive dependencies myself, or is there something I'm missing?

Thanks in advance, Chris.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check t

Re: [CMake] Asking CMake to setup compiler for c++11

[Mueller-Roemer, Johannes Sebastian]

This fails for me when using Visual Studio

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Dan Kegel
Sent: Wednesday, October 21, 2015 21:55
To: Chris Stankevitz
Cc: cmake
Subject: Re: [CMake] Asking CMake to setup compiler for c++11

Something like

CMAKE_MINIMUM_REQUIRED(VERSION 3.1)
SET(CMAKE_CXX_STANDARD 11)

I think.

On Wed, Oct 21, 2015 at 12:43 PM, Chris Stankevitz  
wrote:
> Hi,
>
> Q: What is the "CMake way" to ask that the compiler be setup for c++11?
>
> FYI I could not find the answer at
> https://cmake.org/cmake/help/v3.4/search.html?q=c%2B%2B11
>
> Thank you,
>
> Chris
> --
>
> 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:
> http://public.kitware.com/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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Generated .rc files silently ignored

[Mueller-Roemer, Johannes Sebastian]

Hej hej,

for some reason your mail was not delivered to me and I only stumbled upon it 
by chance in the archives (while trying to find out where another one of my 
mails to the list disappeared to).

In any case, yes, I am adding the .rc file to my add_library command. The issue 
I have is that if I use mylib.rc in add_library and have an 
add_custom_command(OUTPUT mylib.rc ...) nothing is created but no error message 
is produced either (i.e. silently ignored). I have to use 
${CMAKE_CURRENT_BINARY_DIR}/mylib.rc explicitly. For most files (such as 
generated .cpp files) using a relative path just works, because relative paths 
used in add_custom_command are interpreted relative to 
${CMAKE_CURRENT_BINARY_DIR}.

Original text:

Hej,

Some more information about how you setup things would be useful. For instance: 
you would need to add the filename of the generated .rc file to the 
executable/library for which it is generated: are you doing that?

In the application I currently work on, we have created a small function to 
wrap the generation of the .rc file. I just checked that we actually also build 
a full path. That actually makes sense, because the generated file is put in 
the ${CMAKE_CURRENT_BINARY_DIR} and *not* in the current source dir. In other 
words: we could never accomplish this with any type of 'relative' path anyway. 
Are you maybe also mixing up the *SOURCE_DIR and *BINARY_DIR?

Sincerely,
Jakob

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Generated .rc files silently ignored

[Mueller-Roemer, Johannes Sebastian]

While adding versioning info to a  .dll I noticed that .rc files that are 
generated (via configure_file) are silently being ignored. Adding them via an 
absolute path works, but using a relative leads to it being ignored.

Is this a bug or is this by design? At the very least just silently ignoring it 
seems wrong.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Function to get a list of all (recursively) linked libraries?

[Mueller-Roemer, Johannes Sebastian]

Is there any simple method of acquiring a list of (absolute paths, generator 
expressions for debug/release are ok) all libraries linked to an executable or 
shared target? The LINK_LIBRARIES property contains targets and aliased targets 
and makes creating such a list quite complicated, but CMake must internally be 
able to create such a list for linking.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Copying shared libraries in a post-build step

[Mueller-Roemer, Johannes Sebastian]

Only after manually changing per-user project debug settings.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of J Decker
Sent: Wednesday, December 10, 2014 11:38
To: Tim Blechmann
Cc: cmake@cmake.org
Subject: Re: [CMake] Copying shared libraries in a post-build step


b: in msvc, you cannot debug by right-click on the target -> debug ->
start new instance.

I can and do all the time.

--

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Creating a library from subdirectories

[Mueller-Roemer, Johannes Sebastian]

No, the quoted text is absolutely correct. If you were to do

add_executable(exec ${srcs})
target_link_libraries(exec big)

A and B would be linked in automatically, as CMake tracks the link 
dependencies, just as the quote states. This does not mean that libbig.a 
contains libA.a and libB.a, only that CMake knows that those have to be linked 
as well.

From: Chris Johnson [cxjohn...@gmail.com]
Sent: Wednesday, November 26, 2014 8:45 PM
To: Mueller-Roemer, Johannes Sebastian
Cc: cmake@cmake.org
Subject: Re: [CMake] Creating a library from subdirectories

I know that one cannot link static libraries together; they're just archives of 
objects, really.  But since CMake abstracts the actual construction of the 
library, it could conceivably know how to do the right thing and collect all 
the needed objects recursively, as it appears to do for executables.  It seems 
it does not know how to do this.  Hence, I believe the section of the wiki 
quoted below is thus in error, as it implies this kind of transitive linking 
resolution can be done.  I've made it work using OBJECT libraries, but as I 
originally mentioned, I'm really trying for the simplest, most basic kind 
CMakeLists.txt syntax possible so as to allow my automation to do most of the 
work (I have a very large source tree).  Thanks.

Quote:

For example, we can create two subdirectories:

# A/CMakeLists.txt
add_library(A ${A_srcs})

# B/CMakeLists.txt
add_library(B ${B_srcs})


and then refer to those libraries from the top directory:

# CMakeLists.txt
add_subdirectory(A)
add_subdirectory(B)
add_library(big ${other_srcs})
target_link_libraries(big A B)


This approach is easy to use and helps organize the project source tree. Since 
CMake tracks link dependencies automatically it is easy to refer to the "big" 
library in target_link_libraries calls elsewhere in the project and let CMake 
propagate the dependency on A and B.



On Wed, Nov 26, 2014 at 6:52 AM, Mueller-Roemer, Johannes Sebastian 
mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
 wrote:
Sorry overread the last point in your mail. I don’t believe there is a way to 
avoid this directly. What you seem to want is what Xcode calls a prelinked 
library (http://cocoadev.com/SingleObjectPrelink) . CMake does not have such an 
option as far as I know

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 
155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
  |  www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: Mueller-Roemer, Johannes Sebastian
Sent: Wednesday, November 26, 2014 13:50
To: 'Chris Johnson'; cmake@cmake.org<mailto:cmake@cmake.org>
Subject: RE: [CMake] Creating a library from subdirectories

In the example on that site an OBJECT library is created (the output consists 
of multiple .obj files), you used STATIC libraries instead (which each output a 
single .lib)

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 
155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
  |  www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Chris Johnson
Sent: Wednesday, November 26, 2014 01:36
To: cmake@cmake.org<mailto:cmake@cmake.org>
Subject: [CMake] Creating a library from subdirectories

This CMake wiki page (http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) 
claims one can create a library from subdirectories containing libraries, which 
is exactly what I want to do.  However, it doesn't seem to work.  Here's my 
SSCCE (http://sscce.org) "toy" example file structure:

.
|-- CMakeLists.txt
|-- component1/
|   |-- CMakeLists.txt
|   `-- c1.c
|-- component2/
|   |-- CMakeLists.txt
|   `-- c2.c
`-- dummy.c


## Here's the top level CMakeLists.txt, per example from Wiki:

cmake_minimum_required(VERSION 2.8.4)
project(lib)
add_subdirectory(component1)
add_subdirectory(component2)
add_library(lib dummy.c)
target_link_libraries(libcomponent1 component2)

## The subdirectory CMakeLists.txt files contain effectively just:
add_library(component1  STATIC  c1.c)
## and
add_library(component2  STATIC  c2.c)


## The resulting library file liblib.a contains only the dummy placeholder, but 
none of the subdirectory content:

lib$ ar tv liblib.a

rw-r--r-- 502/20  696 Nov 25 18:23 2014 dummy.c.o


## Is there some way to make this work?

* Ideally, I would not even need the dummy.c placeholder, but I can l

[CMake] out-of-tree buildable libraries and find_package

[Mueller-Roemer, Johannes Sebastian]

I have a project which uses a number of libraries, a bit like this:

CMakeLists.txt -> add_subdirectories, add_executable
Lib1 -> add_library
Lib2 -> add_library, links to/uses Lib1

As the libraries are individually useful I'd like to keep them individually 
buildable (i.e., out-of-tree). Obviously, Lib2 will then have to do a 
find_package(Lib1). However, the find_package will fail if it is built in-tree. 
I currently see three options:


1.   Protect the find_package() with if(CMAKE_CURRENT_SOURCE_DIR STREQUAL 
CMAKE_SOURCE_DIR)

2.   Use export(TARGETS) and export(PACKAGE), however this leads to 
warnings when using CMake 3

3.   Write an empty (or ALIAS-target only if using namespaces for the real 
config) ${PROJECT_NAME}-config.cmake to CMAKE_BINARY_DIR and add 
CMAKE_BINARY_DIR to CMAKE_PREFIX PATH in the root CMakeLists.txt

None of these really feels right. Are there better options? What is the 
cleanest solution?

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Creating a library from subdirectories

[Mueller-Roemer, Johannes Sebastian]

Sorry overread the last point in your mail. I don’t believe there is a way to 
avoid this directly. What you seem to want is what Xcode calls a prelinked 
library (http://cocoadev.com/SingleObjectPrelink) . CMake does not have such an 
option as far as I know

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

From: Mueller-Roemer, Johannes Sebastian
Sent: Wednesday, November 26, 2014 13:50
To: 'Chris Johnson'; cmake@cmake.org
Subject: RE: [CMake] Creating a library from subdirectories

In the example on that site an OBJECT library is created (the output consists 
of multiple .obj files), you used STATIC libraries instead (which each output a 
single .lib)

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
  |  www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Chris Johnson
Sent: Wednesday, November 26, 2014 01:36
To: cmake@cmake.org<mailto:cmake@cmake.org>
Subject: [CMake] Creating a library from subdirectories

This CMake wiki page (http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) 
claims one can create a library from subdirectories containing libraries, which 
is exactly what I want to do.  However, it doesn't seem to work.  Here's my 
SSCCE (http://sscce.org) "toy" example file structure:

.
|-- CMakeLists.txt
|-- component1/
|   |-- CMakeLists.txt
|   `-- c1.c
|-- component2/
|   |-- CMakeLists.txt
|   `-- c2.c
`-- dummy.c


## Here's the top level CMakeLists.txt, per example from Wiki:

cmake_minimum_required(VERSION 2.8.4)
project(lib)
add_subdirectory(component1)
add_subdirectory(component2)
add_library(lib dummy.c)
target_link_libraries(libcomponent1 component2)

## The subdirectory CMakeLists.txt files contain effectively just:
add_library(component1  STATIC  c1.c)
## and
add_library(component2  STATIC  c2.c)


## The resulting library file liblib.a contains only the dummy placeholder, but 
none of the subdirectory content:

lib$ ar tv liblib.a

rw-r--r-- 502/20  696 Nov 25 18:23 2014 dummy.c.o


## Is there some way to make this work?

* Ideally, I would not even need the dummy.c placeholder, but I can live with 
that.

* I do not want to list all of the source files in the top level CMakeLists.txt 
file.

* I do not want to use the add_library(component1 OBJECT ${component1_sources}) 
and add_library(toplevel $ ... ) syntax if it can be 
avoided.


The reasons for my limitations is that to the greatest extent possible, I am 
generating CMakeLists.txt files via automation which needs to use a sort of a 
least-common-denominator approach to building those files.

..chris
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Creating a library from subdirectories

[Mueller-Roemer, Johannes Sebastian]

In the example on that site an OBJECT library is created (the output consists 
of multiple .obj files), you used STATIC libraries instead (which each output a 
single .lib)

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Chris Johnson
Sent: Wednesday, November 26, 2014 01:36
To: cmake@cmake.org
Subject: [CMake] Creating a library from subdirectories

This CMake wiki page (http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) 
claims one can create a library from subdirectories containing libraries, which 
is exactly what I want to do.  However, it doesn't seem to work.  Here's my 
SSCCE (http://sscce.org) "toy" example file structure:

.
|-- CMakeLists.txt
|-- component1/
|   |-- CMakeLists.txt
|   `-- c1.c
|-- component2/
|   |-- CMakeLists.txt
|   `-- c2.c
`-- dummy.c


## Here's the top level CMakeLists.txt, per example from Wiki:

cmake_minimum_required(VERSION 2.8.4)
project(lib)
add_subdirectory(component1)
add_subdirectory(component2)
add_library(lib dummy.c)
target_link_libraries(libcomponent1 component2)

## The subdirectory CMakeLists.txt files contain effectively just:
add_library(component1  STATIC  c1.c)
## and
add_library(component2  STATIC  c2.c)


## The resulting library file liblib.a contains only the dummy placeholder, but 
none of the subdirectory content:

lib$ ar tv liblib.a

rw-r--r-- 502/20  696 Nov 25 18:23 2014 dummy.c.o


## Is there some way to make this work?

* Ideally, I would not even need the dummy.c placeholder, but I can live with 
that.

* I do not want to list all of the source files in the top level CMakeLists.txt 
file.

* I do not want to use the add_library(component1 OBJECT ${component1_sources}) 
and add_library(toplevel $ ... ) syntax if it can be 
avoided.


The reasons for my limitations is that to the greatest extent possible, I am 
generating CMakeLists.txt files via automation which needs to use a sort of a 
least-common-denominator approach to building those files.

..chris
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

[Mueller-Roemer, Johannes Sebastian]

Actually, I'm using this to make a static library that uses boost useable via 
find_package without having hard-coded paths inside it and my Config.cmake 
contains a find_package(Boost 1.56 EXACT REQUIRED COMPONENTS coroutine context 
system). So it isn't exactly only academic... Yes, it would be simpler if Boost 
already provided IMPORTED targets, but expecting IMPORTED targets for every 
library out there is not realistic, so another, ideally less verbose, solution 
would be incredibly useful.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Stephen Kelly
Sent: Tuesday, November 25, 2014 16:14
To: cmake@cmake.org
Subject: Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

Mueller-Roemer, Johannes Sebastian wrote:

> For clarification:
> 
> As an imported target can't have debug and optimized keywords, I can't 
> simply use $
> $ But have to do
> $ $<$:
> ...

Yes, but for the user of the target, it's just

 target_link_libraries(mytgt Boost::Coroutine)

This is academic though anyway until someone decides to submit and maintain 
IMPORTED targets for Boost, or until Boost decides to make them available 
itself. So, for now, you are correct, it's verbose.

Thanks,

Steve.


-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

[Mueller-Roemer, Johannes Sebastian]

For clarification:

As an imported target can't have debug and optimized keywords, I can't simply 
use
$ $
But have to do
$:
${Boost_COROUTINE_LIBRARY_DEBUG}
${Boost_CONTEXT_LIBRARY_DEBUG}
${Boost_SYSTEM_LIBRARY_DEBUG}
>
$<$>:
${Boost_COROUTINE_LIBRARY_RELEASE}
${Boost_CONTEXT_LIBRARY_RELEASE}
${Boost_SYSTEM_LIBRARY_RELEASE}
>
>
$:
\${Boost_COROUTINE_LIBRARY_DEBUG}
\${Boost_CONTEXT_LIBRARY_DEBUG}
\${Boost_SYSTEM_LIBRARY_DEBUG}
>
$<$>:
\${Boost_COROUTINE_LIBRARY_RELEASE}
\${Boost_CONTEXT_LIBRARY_RELEASE}
\${Boost_SYSTEM_LIBRARY_RELEASE}
>
>

Instead which is excessively verbose...

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Stephen Kelly
Sent: Tuesday, November 25, 2014 15:05
To: cmake@cmake.org
Subject: Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

Mueller-Roemer, Johannes Sebastian wrote:

> It appears that wasn't really the issue, but rather that I had my 
> CMake minimum version set to 2.8.11 and not 2.8.12.

See the reply from Nils and the documentation link I posted previously.

> Is there a cleaner solution
> for the "debug" and "optimized" keyword issue than using individual 
> library variables?

I don't fully understand the question. Imported targets for Boost would be 
cleaner, but there's no one submitting and maintaining such a thing. There was 
a discussion that could be picked up though.

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10332/focus=10370

Thanks,

Steve.


-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

[Mueller-Roemer, Johannes Sebastian]

It appears that wasn't really the issue, but rather that I had my CMake minimum 
version set to 2.8.11 and not 2.8.12.
Is there a cleaner solution for the "debug" and "optimized" keyword issue than 
using individual library variables?

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Stephen Kelly
Sent: Tuesday, November 25, 2014 13:40
To: cmake@cmake.org
Subject: Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

Mueller-Roemer, Johannes Sebastian wrote:

> produces a file containing:
> IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
> "${Boost_COROUTINE_LIBRARY_RELEASE}"

You need to make sure policy CMP0022 is NEW for the BUILD_INTERFACE to be 
handled correctly. Unfortunately there is no warning in this case.

See 

 http://www.cmake.org/cmake/help/v3.1/manual/cmake-policies.7.html

for more.

Thanks,

Steve.


-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] BUILD_INTERFACE genex used even in install(EXPORT...

[Mueller-Roemer, Johannes Sebastian]

I am trying to add a library via it's variable(s) in an installed (static 
library) target, but BUILD_INTERFACE appears to be used for the generation of 
*-targets-*.cmake even when using install(EXPORT...), instead of 
INSTALL_INTERFACE:

CMakeLists.txt
[...]
target_link_libraries(${PROJECT_NAME} PUBLIC

$<$:$> 
$<$>:$>
)
[...]
install(EXPORT ${PROJECT_NAME}-targets DESTINATION share/cmake)

produces a file containing:
IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "${Boost_COROUTINE_LIBRARY_RELEASE}"

Which seems wrong (and since I had to use the variable in BUILD_INTERFACE I can 
no longer use it from other projects within the same Build

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] What generator(s) should be used for MinGW-w64?

[Mueller-Roemer, Johannes Sebastian]

mingw32-make, and yes it's included (I recently started using ninja as well, 
but that isn't included, and has some limitations with cmake)

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-Original Message-
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] 
Sent: Friday, October 31, 2014 11:19
To: Mueller-Roemer, Johannes Sebastian
Cc: cmake@cmake.org
Subject: RE: [CMake] What generator(s) should be used for MinGW-w64?

On 2014-10-31 08:14-0000 Mueller-Roemer, Johannes Sebastian wrote:

> I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The 
> main difference between MinGW-w64 and the original MinGW is that it is far 
> more up to date.
> Binary packages can be found here: 
> http://mingw-w64.sourceforge.net/download.php
> I generally recommend using the mingw-builds binary packages

Hi Johannes:

Thanks for that useful information.
What is the name of the make command you use, and is it part of the 
mingw-builds binary packages that you recommend?

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy, 
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation for 
stellar interiors (freeeos.sf.net); the Time Ephemerides project 
(timeephem.sf.net); PLplot scientific plotting software package 
(plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux 
Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] What generator(s) should be used for MinGW-w64?

[Mueller-Roemer, Johannes Sebastian]

I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The 
main difference between MinGW-w64 and the original MinGW is that it is far more 
up to date.
Binary packages can be found here: http://mingw-w64.sourceforge.net/download.php
I generally recommend using the mingw-builds binary packages

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Alan W. Irwin
Sent: Thursday, October 30, 2014 22:07
To: cmake@cmake.org
Subject: [CMake] What generator(s) should be used for MinGW-w64?

PLplot developers and users have had a lot of success with MinGW alone (using 
the "MinGW Makefiles" generator) or the combination of MinGW and MSYS (using 
the "MSYS Makefiles" generator).  However, there is another gcc compiler out 
there for Windows called MinGW-w64 that one of our users would like to use, but 
I don't know exactly what to advise him, and so I hope somebody here has had 
some practical CMake experience with the MinGW-w64 compiler and could help with 
such advice.

Here is what I know so far:

MinGW-w64 is a completely separate project than MinGW with different 
developers, install procedure, etc.  I have read distributed binary versions of 
MSYS are all built with MSYS so are not ABI-compatible with MinGW-w64, and I 
will proceed on that assumption.
Furthermore, there is an MSYS2 project (a completely independent project from 
MSYS, see )
which _is_ API-compatible with MinGW-w64 since it is built with that compiler.

The combination of MinGW-w64 and MSYS2 seems fairly well documented (see the 
above wiki reference).  It appears for example, this combination is a "lite" 
version of Cygwin.  So I assume that if MSYS2 is on the PATH, then the "Unix 
Makefiles" generator is the correct one to use for this case (since that is the 
recommended generator for Cygwin), but I would like confirmation of that if 
someone here has experience with the combination of MinGW-w64 and MSYS2.

Another possible case is when neither MSYS nor MSYS2 are on the PATH.
Is the "MinGW Makefiles" generator the correct one to use with the
MinGW-w64 compiler for this case?  My guess is that might work if the
MinGW-w64 binary package includes some form of make command (similar to the 
MinGW mingw32-make.exe command), but I am having trouble finding a binary 
package for MinGW-w64 so I have no idea whether binary packages exist for 
MinGW-w64, and if so whether they include some form of make command.  So if 
somebody here has some experience with the MinGW-w64 without MSYS2, I would 
appreciate your comments.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy, 
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation for 
stellar interiors (freeeos.sf.net); the Time Ephemerides project 
(timeephem.sf.net); PLplot scientific plotting software package 
(plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux 
Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
-- 

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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] INTERFACE_LINK_LIBRARIES and CMP0028

[Mueller-Roemer, Johannes Sebastian]

The behavior of the transitive INTERFACE_LINK_LIBRARIES combined with CMP0028 
seems very broken to me. For libraries using a module (such as ZLIB), I can 
simply do a find_package in one of my libraries' CMakeLists.txt and link to it 
in a different CMakeLists.txt without issues. If I do the same with libraries 
using configs and IMPORTED targets (such as Qt5), I cannot have my find_package 
at the place of use but am forced to move it to the root CMakeLists.txt as I 
otherwise get CMP0028 warnings. Is this actually intended behavior? Am I doing 
something wrong? Shouldn't INTERFACE_LINK_LIBRARIES just include the actual 
libraries (and INTERFACE_INCLUDE_DIRECTORIES the actual include directories) 
when linking to an imported target. These extra dependencies between 
CMakeLists.txt are very ugly :/

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake