Re: [CMake] Problem with AUTOMOC on WIN32

[Innokentiy Alaytsev]

Hello!

Are the header files of the shared library (DLL) listed as INTERFACE_SOURCES
for the library target? AFAIK, the only reason for header files to be
processed by AUTOMOC is to be part of the project. The only way that I know
of for adding library headers to the consuming project is by declaring them
as INTERFACE sources of the library target.

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-commits] CMake branch, master, updated. v3.15.0-rc1-105-gc9f284c

[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  c9f284c73634b7935a12c1912dbb8eae71650ae5 (commit)
  from  0a104224182565645b6bb8a1f81031c5afdc67ed (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=c9f284c73634b7935a12c1912dbb8eae71650ae5
commit c9f284c73634b7935a12c1912dbb8eae71650ae5
Author: Kitware Robot 
AuthorDate: Wed Jun 19 00:01:05 2019 -0400
Commit: Kitware Robot 
CommitDate: Wed Jun 19 00:01:05 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 9bef298..e9e4c29 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 15)
-set(CMake_VERSION_PATCH 20190618)
+set(CMake_VERSION_PATCH 20190619)
 #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 to specify debug version of CRT library for Visual Studio generator?

[Robert Maynard]

Just a heads up, CMake 3.15 is introducing policy 91 which removes the
runtime library from the default set of flags, and instead has targets
establish what runtime they want.

For more information see:
https://cmake.org/cmake/help/v3.15/prop_tgt/MSVC_RUNTIME_LIBRARY.html

On Tue, Jun 18, 2019 at 10:06 AM Eric Dönges  wrote:
>
> On 18.06.19 12:53, David Aldrich wrote:
> > I have a simple CMake project that builds an executable using Visual
> > Studio 2017:
>
>
> >
> >  Files 
> > #   --   Add files to project.   --   #
> > ###
> >
> > file(GLOB SRC_FILES
> > ${CPP_DIR_1}/*.cpp
> > ${CPP_DIR_2}/*.cpp
> > ${CPP_DIR_3}/*.cpp
> > ${CPP_DIR_4}/*.cpp
> > ${HEADER_DIR_1}/*.h
> > )
> >
> > # Add executable to build.
> > add_executable(${PROJECT_NAME}
> >${SRC_FILES}
> > )
> >
> > if(MSVC)
> >target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> > endif(MSVC)
> >
> > #=
> >
> > The Release build succeeds but the Debug build fails with linker errors
> > such as:
> >
> > [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> > __imp___CrtDbgReport
> >
> > I think this is because the linker is not using the debug version of CRT
> > (C Run-time Library).
> >
> > Should CMake select the debug build of CRT automatically or do I need to
> > specify it manually? If so, should I do so using CMAKE_EXE_LINKER_FLAGS?
> >
>
> CMake will select the correct CRT automatically if you let it (unless
> you want the static CRT, in which case you have to override CMake's
> default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG incorrectly:
>
> > if(MSVC)
> >#set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> > /MD /Od /Zi /EHsc")
> >set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> > /Oi /Gy /Zi /EHsc")
> >set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> > /GL /Od /Oi /Gy /Zi /EHsc")
> > endif(MSVC)
>
> In case of the setting you've commented out, you are explicitly telling
> CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
> since you append the /MD, that is what the compiler will actually use.
>
> For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
> to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
> you want (and also specifies /MD).
>
> I would suggest looking at what flags CMake sets by default (look at the
> Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
> only setting those flags that CMake doesn't already. For version 3.14,
> CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
> default (assuming you are using MVSC >= 1310, no Clang toolset):
>
> /MDd /Zi /Ob0 /Od /GR /EHSC
>
> So in your case, it would probably be enough to
>
> string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")
>
> As a final recommendation, use string(APPEND  ...) (or list(APPEND
>  ...), if the variable is interpreted as a list) when appending
> values to existing variables. This makes your intent clearer.
>
>
>  - when appending compiler flags, use the "string(APPEND ...)" command
> to make is clearer what you are doing).
> --
>
> 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] How to specify debug version of CRT library for Visual Studio generator?

[Eric Dönges]

On 18.06.19 12:53, David Aldrich wrote:
> I have a simple CMake project that builds an executable using Visual
> Studio 2017:


> 
>  Files 
> #   --   Add files to project.   --   #
> ###
> 
> file(GLOB SRC_FILES
>     ${CPP_DIR_1}/*.cpp
>     ${CPP_DIR_2}/*.cpp
>     ${CPP_DIR_3}/*.cpp
>     ${CPP_DIR_4}/*.cpp
>     ${HEADER_DIR_1}/*.h
> )
> 
> # Add executable to build.
> add_executable(${PROJECT_NAME}
>    ${SRC_FILES}
> )
> 
> if(MSVC)
>    target_link_libraries(${PROJECT_NAME} ws2_32.lib )
> endif(MSVC)
> 
> #=
> 
> The Release build succeeds but the Debug build fails with linker errors
> such as:
> 
> [build] CPlaneTest.obj : error LNK2001: unresolved external symbol
> __imp___CrtDbgReport
> 
> I think this is because the linker is not using the debug version of CRT
> (C Run-time Library).  
> 
> Should CMake select the debug build of CRT automatically or do I need to
> specify it manually? If so, should I do so using CMAKE_EXE_LINKER_FLAGS?
> 

CMake will select the correct CRT automatically if you let it (unless
you want the static CRT, in which case you have to override CMake's
default settings). You are setting your CMAKE_CXX_FLAGS_DEBUG incorrectly:

> if(MSVC)
>#set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3
> /MD /Od /Zi /EHsc")
>set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od
> /Oi /Gy /Zi /EHsc")
>set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3
> /GL /Od /Oi /Gy /Zi /EHsc")
> endif(MSVC)

In case of the setting you've commented out, you are explicitly telling
CMake to use /MD. CMAKE_CXX_FLAGS_DEBUG should already contain /MDd, but
since you append the /MD, that is what the compiler will actually use.

For the setting that is not commented out, you set CMAKE_CXX_FLAGS_DEBUG
to the contents of CMAKE_CXX_FLAGS_RELEASE - which is certainly not what
you want (and also specifies /MD).

I would suggest looking at what flags CMake sets by default (look at the
Windows-MSVC.cmake file in CMake's 'Modules/Platform' directory) and
only setting those flags that CMake doesn't already. For version 3.14,
CMake should be setting the following flags for CMAKE_CXX_FLAGS_DEBUG by
default (assuming you are using MVSC >= 1310, no Clang toolset):

/MDd /Zi /Ob0 /Od /GR /EHSC

So in your case, it would probably be enough to

string(APPEND CMAKE_CXX_FLAGS_DEBUG " /D_DEBUG /W3")

As a final recommendation, use string(APPEND  ...) (or list(APPEND
 ...), if the variable is interpreted as a list) when appending
values to existing variables. This makes your intent clearer.


 - when appending compiler flags, use the "string(APPEND ...)" command
to make is clearer what you are doing).
-- 

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] CMake now available to Linux users as a snap

[Craig Scott]

Hi all. For those of you working on Linux, I'm pleased to announce that
CMake is now available as a snap. This can be a great way to conveniently
keep up with the latest CMake releases, even on Linux distributions that
are no longer updating their own CMake packages. You can find a brief blog
post about it here:

https://crascit.com/2019/06/18/cmake-now-available-as-a-snap/

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

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

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, release, updated. v3.15.0-rc1-27-ge2b4fa1

[Kitware Robot]

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

The branch, release has been updated
   via  e2b4fa114184a0a8eeec9c8005e09f70a8ae6832 (commit)
   via  8a08d0c0926a9f950ff49d5547b374c0bd282440 (commit)
  from  dad271e8b7eec9ce781bccb9e7e7c9ed4f55003c (commit)

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

- Log -
---

Summary of changes:
 Help/variable/CMAKE_PROJECT_INCLUDE.rst  |  9 ++---
 Help/variable/CMAKE_PROJECT_INCLUDE_BEFORE.rst   |  9 ++---
 Help/variable/CMAKE_PROJECT_PROJECT-NAME_INCLUDE.rst | 10 +++---
 3 files changed, 19 insertions(+), 9 deletions(-)


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

[Cmake-commits] CMake branch, master, updated. v3.15.0-rc1-104-g0a10422

[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  0a104224182565645b6bb8a1f81031c5afdc67ed (commit)
   via  7af2dedc0895e0ba685b49092c7ec48b3468e833 (commit)
   via  1b5a7adf5e5b9343f6f6dc608b1dee0b17316af8 (commit)
   via  cc7f1be54e923a8459279638594238650c9a0529 (commit)
   via  a45f061296f6646c263fa034758dd23783d5 (commit)
   via  e2b4fa114184a0a8eeec9c8005e09f70a8ae6832 (commit)
   via  9c7ea95ab0961d6f0b6b317a45fbde9cb65dab1b (commit)
   via  2746c61e6d36f3d49744b11259395a8684007e9f (commit)
   via  8a08d0c0926a9f950ff49d5547b374c0bd282440 (commit)
   via  63bf207cd67972785fba5d48533022e0945f0bd7 (commit)
   via  68dcbeee01a301876011a8310509e3860cbb9b34 (commit)
   via  34a7e5ab587f5441ed5854b6ad9a159f3af88365 (commit)
  from  db7fc1e04507fc18475c0af0dacd7b45b4f69389 (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=0a104224182565645b6bb8a1f81031c5afdc67ed
commit 0a104224182565645b6bb8a1f81031c5afdc67ed
Merge: 7af2ded 63bf207
Author: Brad King 
AuthorDate: Tue Jun 18 11:58:39 2019 +
Commit: Kitware Robot 
CommitDate: Tue Jun 18 07:59:46 2019 -0400

Merge topic 'cxx_lambda_init_captures_document_why_not_supported_on_gcc48'

63bf207cd6 CompileFeatures: document why lambda_init_captures requires GCC 
4.9

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7af2dedc0895e0ba685b49092c7ec48b3468e833
commit 7af2dedc0895e0ba685b49092c7ec48b3468e833
Merge: 1b5a7ad 68dcbee
Author: Brad King 
AuthorDate: Tue Jun 18 11:58:21 2019 +
Commit: Kitware Robot 
CommitDate: Tue Jun 18 07:58:48 2019 -0400

Merge topic 'implicit_lapack_library'

68dcbeee01 FindLAPACK: Test for implicitly linked LAPACK libraries

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b5a7adf5e5b9343f6f6dc608b1dee0b17316af8
commit 1b5a7adf5e5b9343f6f6dc608b1dee0b17316af8
Merge: cc7f1be 2746c61
Author: Brad King 
AuthorDate: Tue Jun 18 11:57:46 2019 +
Commit: Kitware Robot 
CommitDate: Tue Jun 18 07:57:56 2019 -0400

Merge topic 'library-search-paths'

2746c61e6d Swift: Add library search paths for dependencies

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc7f1be54e923a8459279638594238650c9a0529
commit cc7f1be54e923a8459279638594238650c9a0529
Merge: a45f061 e2b4fa1
Author: Brad King 
AuthorDate: Tue Jun 18 07:57:33 2019 -0400
Commit: Brad King 
CommitDate: Tue Jun 18 07:57:33 2019 -0400

Merge branch 'release-3.15'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a45f061296f6646c263fa034758dd23783d5
commit a45f061296f6646c263fa034758dd23783d5
Merge: 9c7ea95 8a08d0c
Author: Brad King 
AuthorDate: Tue Jun 18 11:55:49 2019 +
Commit: Kitware Robot 
CommitDate: Tue Jun 18 07:56:08 2019 -0400

Merge topic 'doc-project-include'

8a08d0c092 Help: Document what project() calls use CMAKE_PROJECT_INCLUDE 
and friends

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c7ea95ab0961d6f0b6b317a45fbde9cb65dab1b
commit 9c7ea95ab0961d6f0b6b317a45fbde9cb65dab1b
Merge: db7fc1e 34a7e5a
Author: Brad King 
AuthorDate: Tue Jun 18 11:54:27 2019 +
Commit: Kitware Robot 
CommitDate: Tue Jun 18 07:54:39 2019 -0400

Merge topic 'tutorial-fix-version'

34a7e5ab58 Tests/Tutorial: Fix version displayed in tutorial executable

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2746c61e6d36f3d49744b11259395a8684007e9f
commit 2746c61e6d36f3d49744b11259395a8684007e9f
Author: Saleem Abdulrasool 
AuthorDate: Sun Jun 9 12:51:00 2019 -0700
Commit: Brad King 
CommitDate: Mon Jun 17 14:09:15 2019 -0400

Swift: Add library search paths for dependencies

When building Swift executables and libraries which import a module, an
implicit link will be added by the driver.  Because this links by name
rather than path, the library search path needs to be provided to
indicate where to find the library.  For all local dependencies, add the
library paths for the targets when linking.  This ensures that you can
link against local libraries without explicitly setting a library path.

Fixes: #19304

diff --git a/Source/cmLinkLineComputer.cxx b/Source/cmLinkLineComputer.cxx
index 2a8bee6..469faca 100644
--- a/Source/cmLinkLineComputer.cxx
+++ 

Re: [cmake-developers] target_link_libraries links mathlib as -lm rather than /libm.so, why?

[Brad King]

On 6/17/19 11:22 PM, Alan W. Irwin wrote:
> target_link_libraries(  /usr/lib/x86_64-linux-gnu/libm.so)
> 
> results in an actual link option "-lm".

Thanks.  I can reproduce that and have opened an issue with an explanation:

  https://gitlab.kitware.com/cmake/cmake/issues/19399

It occurs when the `.so` is a GNU ld script instead of an actual binary.

-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] How to specify debug version of CRT library for Visual Studio generator?

[David Aldrich]

I have a simple CMake project that builds an executable using Visual Studio
2017:

#==

cmake_minimum_required(VERSION 3.5 FATAL_ERROR)

### Variables. 
# Change if you want modify path or other values. #
###

set(PROJECT_NAME CPlaneTest)
# Output Variables
set(OUTPUT_DEBUG Debug/bin)
set(OUTPUT_RELEASE Release/bin)
# Folders files
set(CPP_DIR_1 ./)
set(CPP_DIR_2 ./)
set(CPP_DIR_3 ./)
set(CPP_DIR_4 ./)
set(HEADER_DIR_1 )

## CMake Project 
#The main options of project#
#

project(${PROJECT_NAME} CXX)

# Define Release by default.
if(NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE "Release")
  message(STATUS "Build type not specified: Use Release by default.")
endif(NOT CMAKE_BUILD_TYPE)

# Definition of Macros
add_definitions(
   -D_CONSOLE
   -DUNICODE
   -D_UNICODE
)

## Artefacts Output #
# Defines outputs , depending Debug or Release. #
#

if(CMAKE_BUILD_TYPE STREQUAL "Debug")
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
  set(CMAKE_EXECUTABLE_OUTPUT_DIRECTORY
"${CMAKE_BINARY_DIR}/${OUTPUT_DEBUG}")
else()
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
  set(CMAKE_EXECUTABLE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${OUTPUT_REL}")
endif()

# Flags 
# Defines Flags for Windows and Linux. #


if(MSVC)
   #set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /D _DEBUG /W3 /MD
/Od /Zi /EHsc")
   set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /W3 /GL /Od /Oi
/Gy /Zi /EHsc")
   set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_RELEASE} /D _DEBUG /W3 /GL
/Od /Oi /Gy /Zi /EHsc")
endif(MSVC)
if(NOT MSVC)
   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
   if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
   set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
   endif()
endif(NOT MSVC)

 Files 
#   --   Add files to project.   --   #
###

file(GLOB SRC_FILES
${CPP_DIR_1}/*.cpp
${CPP_DIR_2}/*.cpp
${CPP_DIR_3}/*.cpp
${CPP_DIR_4}/*.cpp
${HEADER_DIR_1}/*.h
)

# Add executable to build.
add_executable(${PROJECT_NAME}
   ${SRC_FILES}
)

if(MSVC)
   target_link_libraries(${PROJECT_NAME} ws2_32.lib )
endif(MSVC)

#=

The Release build succeeds but the Debug build fails with linker errors
such as:

[build] CPlaneTest.obj : error LNK2001: unresolved external symbol
__imp___CrtDbgReport

I think this is because the linker is not using the debug version of CRT (C
Run-time Library).

Should CMake select the debug build of CRT automatically or do I need to
specify it manually? If so, should I do so using CMAKE_EXE_LINKER_FLAGS?
-- 

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] Problem with AUTOMOC on WIN32

[Michael Wild]

Dear all

It's a very long time I last posted here, so please be kind :-)

I currently am having a very hard time to get AUTOMOC to work properly
on WIN32 for the case where I have some Qt classes in a DLL that I
link to an executable. In this case, the header gets included by both,
the corresponding *.cpp file in the DLL and the importing *.cpp file
in the executable. The problem is now that the AUTOMOC feature runs
moc twice on the same header, once for the DLL and once for the
executable, resulting in an inconsistent linkage because for the DLL
the moc'ed sources are dllexport but for the executable they are
dllimport.

I put together a minimal example exhibiting the problem:
https://github.com/themiwi/qt_cmake_automoc_test/

Is this a bug in CMake? IMHO moc should be only run on headers for
targets where the corresponding source file is compiled in. Or am I
just being incredibly stupid and completely miss an obvious point?

Of course I could revert to qt5_wrap_cpp() as demonstrated in the
develop branch of above example, but I'd rather not because that adds
considerable complexity and makes configuration much slower in a
real-world project.

Cheers

Michael
-- 

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