[Cmake-commits] CMake branch, master, updated. v3.12.0-rc1-122-g5f4af3e

[Kitware Robot]

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

The branch, master has been updated
   via  5f4af3e556bd266a3f827a297aacbbfb9ddb7d84 (commit)
  from  21a2ace381f0b8245bcdbcb4a61fed9b77f79415 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f4af3e556bd266a3f827a297aacbbfb9ddb7d84
commit 5f4af3e556bd266a3f827a297aacbbfb9ddb7d84
Author: Kitware Robot 
AuthorDate: Fri Jun 29 00:01:17 2018 -0400
Commit: Kitware Robot 
CommitDate: Fri Jun 29 00:01:17 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 9534200..eb7c76b 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 12)
-set(CMake_VERSION_PATCH 20180628)
+set(CMake_VERSION_PATCH 20180629)
 #set(CMake_VERSION_RC 1)

---

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


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

Re: [CMake] How can I compile and link modular code into a single DLL with MSVC?

[Jason Heeris]

On Thu, 28 Jun 2018 at 20:14, Jason Heeris  wrote:
> So I went and tried this on the real project, and it seems like compiling
the static libs into a DLL doesn't give the same results as using the obj
files directly, as per my initial list of commands. Namely, some symbols
seem to not be getting exported, and some flags are mismatched between
compiler and linker.

Finally got to the bottom of this. The linking was fine, but some
compilation flags were affecting the binary interface. I've made some hacks
in the code to work around this just to verify that it *can* work, and
hopefully solving my issues in the other thread (controlling compiler
flags) will give me a longer term solution.

Thanks for your help.

- Jason
-- 

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] How to change (and account for) default Visual Studio compiler flags

[Jason Heeris]

On Thu, 28 Jun 2018 at 15:19, Jason Heeris  wrote:
> 1. How do I clear default compiler flags for the Visual Studio generator?
I would strongly prefer a solution that can apply to specific targets, but
if not, so be it.

I have created an issue about this on Gitlab:
https://gitlab.kitware.com/cmake/cmake/issues/18137

- Jason
-- 

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] target_include_directories and system headers

[Jim Lloyd]

Thank you Nils, that is exactly the information I needed. Simply setting
`set(CMAKE_NO_SYSTEM_FROM_IMPORTED ON)` achieves the workaround I wanted.


On Wed, Jun 27, 2018 at 11:03 PM, Nils Gladitz 
wrote:

> On Thu, Jun 28, 2018 at 7:12 AM Jim Lloyd  wrote:
>
>> [...]
>> But if I make a trivial project that simply includes yaml-cpp as a
>> dependency, the generated compile commands use `-isystem` to include the
>> yaml-cpp headers.
>>
>> Is this a bug in CMake?
>>
>> Also, is there any way I may be able to work around this problem with
>> CMake 3.10? I would be happy to globally force the use of `-I` for all
>> include directories.
>>
>
> I think the question and a potential work around are covered by
> https://cmake.org/cmake/help/latest/manual/cmake-
> buildsystem.7.html#include-directories-and-usage-requirements
> Specifically the paragraph close to the end starting with "When the
> INTERFACE_INCLUDE_DIRECTORIES of an imported target...".
>
> Basically include directories inherited from imported targets are
> implicitly "SYSTEM" by default.
>
> Nils
>
-- 

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] Dependencies with static libraries

[Hendrik Sattler]

Are you sure you hit the right build menu item? Maybe you are just building the 
current target. At least that would explain it. In MSVC you must either build 
the solution or the ALL_BUILD target for this to work.


Am 28. Juni 2018 16:07:33 MESZ schrieb Stephan Menzel 
:
>Hello CMake community,
>
>I am observing a strange problem regarding dependencies to static libs
>in
>executables. I am not entirely sure but it seems this started since I
>upgraded to the 3.11 line. I am using Windows and MSVC14.
>
>Basically, my code base contains a number of static libraries that are
>linked together to a few executables. Very basic and down to earth.
>Like
>this:
>
>set(MY_SERVER_SRC
>ServerSource1.cpp
>ServerSource2.cpp
>)
>
>set(MY_SERVER_HDR
>ServerConfig.hpp
>Header1.hpp
>Header2.hpp
>)
>
>add_library(my_server STATIC ${MY_SERVER_SRC} ${MY_SERVER_HDR})
>target_link_libraries(my_server
>some_tools
>some_base
>${Boost_LIBRARIES}
>${OPENSSL_LIBRARIES}
>)
>add_executable(serverd main.cpp)
>target_link_libraries(serverd
>my_server
>some_tools
>some_base
>
>${Boost_LIBRARIES}
>${OPENSSL_LIBRARIES}
>)
>
>So a few big libs with the beef in them and then a small main.cpp
>containing executable. Nothing fancy.
>
>What gives me trouble now is that dependencies within that seem broken.
>In
>above example, when I edit ServerSource1.cpp and then hit "Build", I
>see
>ServerSource1.o being compiled and the library my_server being linked.
>Like
>expected. Problem is, serverd does not get linked. Or at least I see no
>hint of it being linked (In MSVC's output window).
>So, my question is: What could cause this? I there anything 3.11.x does
>differently which causes those dependecies to break? And how can I fix
>this?
>
>This is quickly turning into a major problem for us here as it means
>that
>we cannot reliably build anymore because whenever we change something
>and
>hit build we can't be sure we get a linked executable anymore unless we
>do
>a complete rebuild, which takes a long time (In fact, I wrote this
>message
>waiting for one).
>
>Thanks for any hint!
>
>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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Dependencies with static libraries

[Stephan Menzel]

Hello Innokentiy,

On Thu, Jun 28, 2018 at 4:17 PM, Innokentiy Alaytsev 
wrote:

> Hello!
>
> I hope you will forgive me a silly question: did you consider checking last
> change date of the executable? And is there any way you can ensure that the
> changes to the library a present in the executable?
>

So far the problem appears too weird to me and I have not tracked it down.
Basically, my way of knowing the changes are not present is debugging for
half a day and getting crazy because whatever I do seems to have no effect
whatsoever ;-)

Since you asked it though, I just did the obvious check for the timestamp
and I see the executable is being updated. It's just not mentioned in the
output log. Perhaps I really am imagining all this and was misled by the
missing output.

Sorry for the noise, I will double check this.

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

Re: [CMake] Dependencies with static libraries

[Innokentiy Alaytsev]

Hello!

I hope you will forgive me a silly question: did you consider checking last
change date of the executable? And is there any way you can ensure that the
changes to the library a present in the executable?

Best regards,
Innokentiy Alaytsev



--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Dependencies with static libraries

[Stephan Menzel]

Hello CMake community,

I am observing a strange problem regarding dependencies to static libs in
executables. I am not entirely sure but it seems this started since I
upgraded to the 3.11 line. I am using Windows and MSVC14.

Basically, my code base contains a number of static libraries that are
linked together to a few executables. Very basic and down to earth. Like
this:

set(MY_SERVER_SRC
ServerSource1.cpp
ServerSource2.cpp
)

set(MY_SERVER_HDR
ServerConfig.hpp
Header1.hpp
Header2.hpp
)

add_library(my_server STATIC ${MY_SERVER_SRC} ${MY_SERVER_HDR})
target_link_libraries(my_server
some_tools
some_base
${Boost_LIBRARIES}
${OPENSSL_LIBRARIES}
)
add_executable(serverd main.cpp)
target_link_libraries(serverd
my_server
some_tools
some_base

${Boost_LIBRARIES}
${OPENSSL_LIBRARIES}
)

So a few big libs with the beef in them and then a small main.cpp
containing executable. Nothing fancy.

What gives me trouble now is that dependencies within that seem broken. In
above example, when I edit ServerSource1.cpp and then hit "Build", I see
ServerSource1.o being compiled and the library my_server being linked. Like
expected. Problem is, serverd does not get linked. Or at least I see no
hint of it being linked (In MSVC's output window).
So, my question is: What could cause this? I there anything 3.11.x does
differently which causes those dependecies to break? And how can I fix this?

This is quickly turning into a major problem for us here as it means that
we cannot reliably build anymore because whenever we change something and
hit build we can't be sure we get a linked executable anymore unless we do
a complete rebuild, which takes a long time (In fact, I wrote this message
waiting for one).

Thanks for any hint!

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

Re: [CMake] How to change (and account for) default Visual Studio compiler flags

[Jason Heeris]

On Thu., 28 Jun. 2018, 8:45 pm Innokentiy Alaytsev, 
wrote:

> Are you setting CMAKE_<...> variables before creating you targets of after
> that?
>

I used the technique in that Stackoverflow link to print and override them
before anything else happens in the project. They are still empty
immediately before the add_executable() call. Certain options (eg. /Wx-) do
not appear in any of those variables but still show up in the generated
output.

— Jason
-- 

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] Super build project with the same library but different version

[Jonathan Dumaresq]

Hi,


Le 6/28/2018 à 7:29 AM, Innokentiy Alaytsev a écrit :

Hello!

The  DownloadProject CMake module
   may be of use in your
situation.

Already test this idea and is' mostly work. I will take a look again.

Basically, you can add the external project with the
add_subdirectory() function in the main build tree. However, there might be
some problems with two targets with the same name, i.e. CppUTest 3.7 and
CppUTest 3.8 will most likely both create the CppUTest target.

As you guest, 2 CppUTest target is created and CMAKE give up.

Unfortunately, I don't know, how to resolve this issue. The best idea I have
is to use v3.8 for bort test suits.
The thing is that I do not want to have this dependency information in 
the top level CMakeLists.txt file.


Regards
Jonathan
-- 

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] Super build project with the same library but different version

[Innokentiy Alaytsev]

Hello!

The  DownloadProject CMake module
   may be of use in your
situation. Basically, you can add the external project with the
add_subdirectory() function in the main build tree. However, there might be
some problems with two targets with the same name, i.e. CppUTest 3.7 and
CppUTest 3.8 will most likely both create the CppUTest target.
Unfortunately, I don't know, how to resolve this issue. The best idea I have
is to use v3.8 for bort test suits.



--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Super build project with the same library but different version

[Jonathan Dumaresq]

Hi all,

I try to do something special and I'm not sure if there a way to handle 
the scenario with CMAKE correctly.


I have a superbuild project with 4 library. each library have there test 
suite. I have different unit test framework needed. Here the the folder 
structure


TOP-Level

|-src

|-inc

|-tests

|-CMakeList.txt

|- Catch2 <--- test framework

|-External

|-LibA

    |-inc

    |-src

    |-tests

        |-CmakeLists.txt

    |-CppUTest (version 3.7)<--- test framework

        |-CmakeLists.txt

    |-CmakeLists.txt

|-LibB

    |-inc

    |-src

    |-tests

        |-CmakeLists.txt

    |-CppUTest (version 3.8)<--- test framework

        |-CmakeLists.txt

    |-CmakeLists.txt

|-CmakeLists.txt

I would like to ba able to build all the tests suite for all the 
library. The simple add_subdirectory doesn't owrk because of multiple 
target definition for CppUTest. So the first try was with the 
ExternalProject and defining different "target" for cppUTest like


ExternalProject_Add ( cppUTest3.7

...)


ExternalProject_Add ( cppUTest3.8

...)

This is working but I cannot use find_package to find it. I think I need 
to do something else to be able to use find_package on it.


Here the portion of The libA CMakeLists.txt

find_package(CppUTest 3.7)

if(NOT CPPUTEST_FOUND)

ExternalProject_Add ( cppUTest3.7

SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/CppUTest

...)

endif()

I have the samething for libB but with 3.8 instead of 3.7


1- Is it the only way to handle this scenario ?

2- Is it possible to build all the test framework dependency before 
building the real application (like at configure time) to be able to use 
find_package(CppUTest 3.7) for example ?


3- Is there a better approch to do it ?


I'm relatively new to CMAKE, so maybe I miss something...

Regards

Jonathan





-- 

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] How to change (and account for) default Visual Studio compiler flags

[Innokentiy Alaytsev]

Jason Heeris wrote
> On Thu., 28 Jun. 2018, 6:07 pm Innokentiy Alaytsev, 

> alaitsev@

> 
> wrote:
>> These flags are visible in cmake-gui
>> if you set (I don't know/remember the right word) the Advanced combo box
>> (setting Grouped will dramatically improve readability).
> 
> So after sending my last email I actually tried that; not only all of the
> flag sets visible in the GUI's advanced mode but all of the _INIT ones I
> could deduce the existence of. The compiler flags are *still* there. Where
> are they coming from?

Are you setting CMAKE_<...> variables before creating you targets of after
that?

Also, try to output the values for the CMAKE_<...> flags and of the
COMPILE_OPTIONS property of each target (i.e. "message ("CMAKE_<...>
${CMAKE_<...>}")") to see where the flags appear first. You may try to
perform experiments, e.g. create a target without setting any CMAKE_<...>
variables and output its properties, set CMAKE_<...> variables and then
create a target and output its properties, etc. This way you will understand
the consequences of different actions.



--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

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] How can I compile and link modular code into a single DLL with MSVC?

[Jason Heeris]

On Thu, 28 Jun 2018 at 08:18, Jason Heeris  wrote:
> > If those modules are not intended to be used outside of the final
shader library, then why not to make them static libraries?
> I'll test it on the real thing and see how that goes. The only problem I
encountered was that the final shared library complains about having "NO
SOURCES given to target: module3_dll". I can add "module3.c" as a source,
even though technically the static lib should already contain everything
from there. I'm not sure why that's an issue though.

So I went and tried this on the real project, and it seems like compiling
the static libs into a DLL doesn't give the same results as using the obj
files directly, as per my initial list of commands. Namely, some symbols
seem to not be getting exported, and some flags are mismatched between
compiler and linker. It *could* be due to certain compiler flags, which
I've raised in another thread. But I need to either add some test code to
my sample project that loads and uses the DLL to demonstrate what's wrong,
or identify what's different in the real project that's causing this.

It'd be nice if there were a way to get CMake to traverse the dependency
graph and just apply specific build commands to each module, even just to
debug exactly where this is going wrong, but I don't think I'm up for that
challenge just yet.

Cheers,
Jason
-- 

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] How to change (and account for) default Visual Studio compiler flags

[Jason Heeris]

On Thu., 28 Jun. 2018, 6:07 pm Innokentiy Alaytsev, 
wrote:
> These flags are visible in cmake-gui
> if you set (I don't know/remember the right word) the Advanced combo box
> (setting Grouped will dramatically improve readability).

So after sending my last email I actually tried that; not only all of the
flag sets visible in the GUI's advanced mode but all of the _INIT ones I
could deduce the existence of. The compiler flags are *still* there. Where
are they coming from?

— Jason
-- 

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] How to change (and account for) default Visual Studio compiler flags

[Innokentiy Alaytsev]

Hello!


Jason Heeris wrote
> I'm not 100% that the latter is relevant, because I think the "_DEBUG"
> affects the build *type* (a Makefile generator thing) and not the build
> *configuration* (a VS thing).

AFAIK, the CMAKE_C[XX]_FLAGS_ work for all generators, so if you are
using MSVS they will apply to respective configurations (i.e. Release,
Debug, RelWithDebInfo). You can provide the desired build configuration with
the --config option to cmake in the command line:

cmake --build . --config Release [--target 

It may also worth looking at CMAKE_C[XX]_FLAGS_RELEASE as well as
CMAKE_EXE_LINKER_FLAGS[_], CMAKE_MODULE_LINKER_FLAGS[_] (if
you are building MODULE_LIBRARY targets),
CMAKE_SHARED_LINKER_FLAGS[_] and
CMAKE_STATIC_LINKER_FLAGS[_]. These flags are visible in cmake-gui
if you set (I don't know/remember the right word) the Advanced combo box
(setting Grouped will dramatically improve readability).

Hope this will be helpful in any way.

Best regards,
Innokentiy Alaytsev




--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

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] How can I compile and link modular code into a single DLL with MSVC?

[Innokentiy Alaytsev]

Innokentiy Alaytsev wrote
> The closest to what you describe could be a horrible abomination
> the project that optionally fetches dependencies from the remote repo and
> adds them as subdirectories to build and link to them (just like in  this
> example project https://github.com/Crascit/DownloadProject;  , but
> uglier).

I think I should clarify something: I don't say and think that  the example
project    is bad and ugly. I
wanted to say, that my own project that uses the same idea and CMake module
is quite horrible. I am sorry for not making it clear enough.

Best regards,
Innokentiy Alaytsev.



--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

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] How can I compile and link modular code into a single DLL with MSVC?

[Innokentiy Alaytsev]

Hello!


Jason Heeris wrote
> The only problem I encountered was that the final shared library complains
> about having "NO SOURCES given to target: module3_dll". I can add
> "module3.c" as a source, even though technically the static lib should
> already contain everything from there. I'm not sure why that's an issue
> though.

The reason is that SHARED_LIBRARY targets must have sources to be built. The
fact that everything is already in the static library does not matter. In
this case, it may worth using OBJECT_LIBRARY targets, but in a different
way:  add an object library and provide it as sources for your target
 
. However, I did not succeed when I tried it on my own project (most likely
due to my own incompetence).


Jason Heeris wrote
> On Thu, 28 Jun 2018 at 04:16, Innokentiy Alaytsev 

> alaitsev@

> 
> wrote:
> 
>> Also, I have an important note about the structure of the project: It may
> be better to have all the dependencies defined before they are used, i.e.
> you should not be able to use the target_link_libraries() with an
> undefined
> target as a linked library.
> 
> I have no idea how I'd achieve this though, with so many subdirectories. I
> think CMake is perfectly happy to resolve these links at generate time
> rather than as the configuration is parsed though?

You may be right about CMake being happy to resolve everything by itself. As
I wrote "It may be better", so I may as well be plain wrong.




--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

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] target_include_directories and system headers

[Nils Gladitz]

On Thu, Jun 28, 2018 at 7:12 AM Jim Lloyd  wrote:

> [...]
> But if I make a trivial project that simply includes yaml-cpp as a
> dependency, the generated compile commands use `-isystem` to include the
> yaml-cpp headers.
>
> Is this a bug in CMake?
>
> Also, is there any way I may be able to work around this problem with
> CMake 3.10? I would be happy to globally force the use of `-I` for all
> include directories.
>

I think the question and a potential work around are covered by
https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#include-directories-and-usage-requirements
Specifically the paragraph close to the end starting with "When the
INTERFACE_INCLUDE_DIRECTORIES of an imported target...".

Basically include directories inherited from imported targets are
implicitly "SYSTEM" by default.

Nils
-- 

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