Re: [CMake] target_sources vs. PUBLIC_HEADER for libraries

[Innokentiy Alaytsev]

Hello!

After some look into target installation, I've devised  the following
abomination
<https://gitlab.com/UtilityToolKit/utk.cmake/blob/master/utk_cmake_install.cmake#L357>
 
. It is ugly and not the way it should be done, but it works and only
requires some discipline at copying and pasting header files listing code.
The function expects the files that are to be installed to be listed with
BUILD_INTERFACE and INSTALL_INTERFACE generator expressions. 

I only use it for headers because I don't know how to separate file lists
into components (i.e. Dev for headers and Runtime for resource files
required at runtime). I use the following code for listing target header
files:

set (HEADERS
  # List of files here
  )

file(RELATIVE_PATH PREFIX
  ${PROJECT_SOURCE_DIR}
  ${CMAKE_CURRENT_LIST_DIR})


foreach (HEADER IN LISTS HEADERS)
  target_sources (my_target(s)
PRIVATE
$
$)
endforeach (HEADER IN HEADERS)

Hope that will somewhat help and won't hurt anyone's fillings and mind.

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] 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

Re: [CMake] Appending to CMAKE_CXX_FLAGS

[Innokentiy Alaytsev]

Hello!

Did you consider adding the flag manually during project configuration? I do
not know you use case, but after some thinking about the best way of
achieving multiprocess compilation under MSVS with CMake I decided, that the
simplest, most portable and flexible is to just add this flag manually. One
of the reasons for such a decision is that I do not know how the project may
be built and multiprocess compilation may cause problems under some hardware
configurations.

Best regards,
Innokentiy



--
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] ExternalProject, continuous integration and caching builds

[Innokentiy Alaytsev]

Hello!

You may try to perform some kind of "caching" actions yourself: store a
checksum for the downloaded dependency archive and only build it if its
checksum changes or the dependency with this checksum hasn't been already
built. You may only store the checksum for the archive download link if it
is possible to guarantee that the link is different for different versions
of the dependency.

Here

  
you may find an ugly implementation of a similar logic.

Best regards,
Innokentiy



--
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] ExternalProject, continuous integration and caching builds

[Innokentiy Alaytsev]

Hello!

You may try to perform some "caching" actions yourself: store some kind of a
checksum for the archive with the downloaded sources and only build
ExternalProject if the checksum changes or if there is no previously built
ExternalProject with the same checksum. It is also possible to only store
checksum for the archive link if it is guaranteed to be different for
different dependency versions.

Here

  
is an ugly implementation of a similar logic for downloaded project.

Best regards,
Innokentiy



--
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] Development Workflow with CMake and VS2017

[Innokentiy Alaytsev]

Hello!

I usually just download prebuild binaries if they are available or build the
required dependency from sources. There are some libraries (and other
software) that are not Windows-friendly (These products are still considered
cross-platform and usually are free in the way fanatics from FSF understand
freedom, i.e. freedom is the thing that should be enforced). In the case
where it is impossible or hard to build something on Windows with MSVC, I
try to find some alternative.

The reason for trying to build everything with MSVC is simple -
unfortunately, it is the official compiler for the platform and some things
can only be built with it for Windows.

Sticking to Cygwin or MSYS2 may be fine unless you need some things like Qt
with WebEngine support or, probably, CUDA (I am not sure if it officially
works with anything else but MSVC).



--
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] Boost + CMake + Windows + Sanity -> Possible?

[Innokentiy Alaytsev]

Hello!

First of all, I suggest you use Boost imported targets instead of
Boost_INCLUDE_DIRS and Boost_LIBRARY_DIRS and the
target_include_directories() and target_link_libraries() functions. Al this
is to better support exporting CMake package if you need it. If you do not
produce CMake package for use in some other projects, then just ignore this
advice.

Second, just use  pre-built Boost binaries
<https://dl.bintray.com/boostorg/release/1.67.0/binaries/>  . They are just
fine. If your Windows Defender finds something in them then it's the problem
in Windows Defender.

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] [Error] While compiling as a pre requirement of a software

[Innokentiy Alaytsev]

Hello!

Did you try just to install CMake in your virtual machine?

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] 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

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

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 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 <https://github.com/Crascit/DownloadProject>   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
<https://cmake.org/cmake/help/v3.5/command/add_library.html#object-libraries> 
. 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] How can I compile and link modular code into a single DLL with MSVC?

[Innokentiy Alaytsev]

Hello!I've looked through the sources in your repo. I don't have CMake 3.12
right now, so I could not build it (Object library target "module1" may not
link to anything). But that's not important.I don't quite understand why are
you using object libraries all over the project. If those modules are not
intended to be used outside of the final shader library, then why not to
make them static libraries? (Sorry me, please, for just asking without
trying)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.Unfortunately, I don't have any example
for you. 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).
This seems rather close to what you want to me because dependency of the
main project is built into a separate library that is linked to the final
artefact.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!

First of all, a side note:


Jason Heeris wrote
> (Not shown: the macros to create the declspec declaration that MSVC needs
> to know what to export in the DLL. It's a type in moduleN and some
> functions in common.)

Do you create declspec declaration by hand? It may worth looking at the 
GenerateExportHeader
<https://cmake.org/cmake/help/v3.7/module/GenerateExportHeader.html>   CMake
module that provides the function generate_export_header(). If you need to
generate some additional macros you can use CUSTOM_CONTENT_FROM_VARIABLE
argument that is supported since CMake 3.7.

Now, let me clarify something:



Jason Heeris wrote
> This is already possible with existing build scripts, but these are
> becoming unmaintainable. The existing scripts compile each individual
> module into an .obj file and finally link them all into a DLL, as in:
> 
> cl.exe [args] common\common.c (creates common.obj)
> cl.exe [args] modules\module1\module1.c (creates module1.obj)
> ...
> cl.exe [args] modules\moduleN\ moduleN.c (creates moduleN.obj)
> 
> link.exe [args] common.obj module1.obj [...] moduleN.obj (creates
> moduleN.dll)

Is it the code that you use in your CMake build script or just a
representation of the general idea?

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] Why does INTERFACE type targets only support whitelisted properties?

[Innokentiy Alaytsev]

Yves Frederix wrote
> Hi all,
> 
> Motivated by my own struggles with targets of type INTERFACE and a
> recent post on this list, I was wondering what is the rationale behind
> allowing only a whitelisted set of properties on targets of this type.
> I understand that one of the use cases for INTERFACE libraries is to
> have a way to work with header-only libraries in a more or less
> standard way. Yes, the current implementation is far from optimal on
> more than one aspect, but I never understood the reason for the
> whitelisting (also google didn't make me any wiser). What am I
> missing? Wouldn't INTERFACE targets be easier to use without these
> restrictions (or alternatively by switching to blacklisting of some
> properties to protect a user from having wrong expectations)?
> 
> Thanks!
> Yves


Hello!

Sorry for necroposting.

I had a problem with the same limitations for the INTERFACE_LIBRARY targets'
properties. However, there is an interesting feature of this type of
targets: according to the  documentation
<https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries>
 
, properties matching INTERFACE_* are allowed to be set. I don't know
whether it is a bug or a feature, but this works not only for standard CMake
target properties but for user-defined properties as well.

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