Re: [CMake] target_sources vs. PUBLIC_HEADER for libraries

Hello! After some look into target installation, I've devised the following abomination . It is ugly and not the way it should be done, but it works and only requires some discipline at copying and pasting he

Re: [CMake] target_sources vs. PUBLIC_HEADER for libraries

Hi, On Fri, Oct 11, 2019 at 9:33 PM Michael Ellery wrote: > I’d like to make sure I understand two different aspects of header files > management for libraries: > > (1) typically you can add header files to target_sources, but it’s only > helpful for IDEs..so that the IDE will show the header fi

Re: [CMake] target_sources vs. PUBLIC_HEADER for libraries

On Fri, Oct 11, 2019, at 3:33 PM, Michael Ellery wrote: > I’d like to make sure I understand two different aspects of header files > management for libraries: > > (1) typically you can add header files to target_sources, but it’s only > helpful for IDEs..so that the IDE will show the header fi

[CMake] target_sources vs. PUBLIC_HEADER for libraries

I’d like to make sure I understand two different aspects of header files management for libraries: (1) typically you can add header files to target_sources, but it’s only helpful for IDEs..so that the IDE will show the header files in its sources list, correct?. In theory, cmake does not actual

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin wrote: > The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, > COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped." This is by far the most likely reason. We added this restriction because we don't want files that have different

[CMake] Error because of MSVC_RUNTIME_LIBRARY value

*Here is my root CMakeLists.txt file:* cmake_minimum_required(VERSION 3.15) cmake_policy(SET CMP0091 NEW) project(test_masm) set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$:Debug>") add_subdirectory(src) *Here is the src/CMakeLists.txt file:* enable_language(ASM_MASM) add_executable(test_execu

Re: [CMake] Unity builds vs. compile_commands.json

On 10/10/19 6:53 PM, Paul Smith wrote: > Is there an intent to address this before the 3.16 release? > > Or is this a known limitation, which may or may not be addressed in > some future version of CMake? > > If the latter it should probably be added to the release notes and/or > documentation