From sancelot at numalliance.com  Wed May  2 02:47:40 2018
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Wed, 2 May 2018 08:47:40 +0200
Subject: [CMake] using ExternalProject_Add when cmake is launched
Message-ID: <c221a91f-5f4f-0a71-06cc-52d2fe8cf71f@numalliance.com>

Hi,

I have got some win32 libraries dependencies stored in a project .

Then I added ExternalProject_Add at beginning of my cmakelists file in 
order to clone this dependency to be available.

and then provide the root path as follow:

SET(CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc
${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/JPEGLIB/jpegsrc-9c
${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/zlib-1.2.3-lib
${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/libpng-1.2.37-lib
${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/ftgl-binary
${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/freetype-dev_2.4.2-1
${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/iconv-1.9.2.1
 ??? ??? ??? ??? ??? ??? )


unfortunately, the project is not cloned when cmake is launched and the 
next dependencies don't find the packages :-(

What Can I do ?

Regards,

S.Ancelot

From kai.wolf at gmail.com  Wed May  2 03:32:34 2018
From: kai.wolf at gmail.com (Kai Wolf)
Date: Wed, 2 May 2018 09:32:34 +0200
Subject: [CMake] using ExternalProject_Add when cmake is launched
In-Reply-To: <c221a91f-5f4f-0a71-06cc-52d2fe8cf71f@numalliance.com>
References: <c221a91f-5f4f-0a71-06cc-52d2fe8cf71f@numalliance.com>
Message-ID: <CAEOrzjq57x__t0e_f503CSbpvOZB1zj_SsdmDZaVbb3zeMsGYQ@mail.gmail.com>

You probably need to manually add a dependency from your ExternalProject to
your target that needs the libraries.
For instance

    ExternalProject_Add(fetch_win32_libs ...)
    add_library(your_other_target ...)
    add_dependencies(your_other_target fetch_win32_libs)

Greetings

Kai Wolf

http://kai-wolf.me/
kai.wolf at gmail.com

2018-05-02 8:47 GMT+02:00 St?phane Ancelot <sancelot at numalliance.com>:

> Hi,
>
> I have got some win32 libraries dependencies stored in a project .
>
> Then I added ExternalProject_Add at beginning of my cmakelists file in
> order to clone this dependency to be available.
>
> and then provide the root path as follow:
>
> SET(CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/JPEGLIB/jpegsrc-9c
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/zlib-1.2.3-lib
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/libpng-1.2.37-lib
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/ftgl-binary
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/freetype-dev_2.4.2-1
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/iconv-1.9.2.1
>                         )
>
>
> unfortunately, the project is not cloned when cmake is launched and the
> next dependencies don't find the packages :-(
>
> What Can I do ?
>
> Regards,
>
> S.Ancelot
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180502/5dd23f82/attachment.html>

From sancelot at numalliance.com  Wed May  2 04:31:47 2018
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Wed, 2 May 2018 10:31:47 +0200
Subject: [CMake] using ExternalProject_Add when cmake is launched
In-Reply-To: <CAEOrzjq57x__t0e_f503CSbpvOZB1zj_SsdmDZaVbb3zeMsGYQ@mail.gmail.com>
References: <c221a91f-5f4f-0a71-06cc-52d2fe8cf71f@numalliance.com>
 <CAEOrzjq57x__t0e_f503CSbpvOZB1zj_SsdmDZaVbb3zeMsGYQ@mail.gmail.com>
Message-ID: <4d9229ab-063a-9627-cd8a-3dc01f80f9b6@numalliance.com>

include(ExternalProject)

ExternalProject_Add(
 ??? WIN32DEPSV2
 ??? PREFIX ${CMAKE_CURRENT_BINARY_DIR}/WIN32DEPSV2
 ??? DOWNLOAD_DIR .
 ??? STAMP_DIR ./stamps
 ??? SOURCE_DIR?? WIN32DEPSV2
 ??? GIT_REPOSITORY git at numagit.numalliance.com:THIRD_PARTIES/WIN32DEPS.git
 ??? CONFIGURE_COMMAND ""
 ??? BUILD_COMMAND ""
 ??? BUILD_IN_SOURCE 1
 ??? INSTALL_COMMAND ""
)

add_library(your_other_target ...)

add_dependencies(your_other_target WIN32DEPSV2)

find_package(Freetype REQUIRED QUIET)


Launching cmake does not clone the git folder , but continues and fails 
with the find_package command

CMake Error at 
/usr/local/cmake-3.10.3-Linux-x86_64/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 
(message):
 ? Could NOT find Freetype (missing: FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS)
Call Stack (most recent call first):
/usr/local/cmake-3.10.3-Linux-x86_64/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
/usr/local/cmake-3.10.3-Linux-x86_64/share/cmake-3.10/Modules/FindFreetype.cmake:157 
(find_package_handle_standard_args)
 ? FOX64/CMakeLists.txt:919 (find_package)

Le 02/05/2018 ? 09:32, Kai Wolf a ?crit?:
> You probably need to manually add a dependency from your 
> ExternalProject to your target that needs the libraries.
> For instance
>
> ExternalProject_Add(fetch_win32_libs ...)
> add_library(your_other_target ...)
>
>
> Greetings
>
> Kai Wolf
>
> http://kai-wolf.me/
> kai.wolf at gmail.com <mailto:kai.wolf at gmail.com>
>
> 2018-05-02 8:47 GMT+02:00 St?phane Ancelot <sancelot at numalliance.com 
> <mailto:sancelot at numalliance.com>>:
>
>     Hi,
>
>     I have got some win32 libraries dependencies stored in a project .
>
>     Then I added ExternalProject_Add at beginning of my cmakelists
>     file in order to clone this dependency to be available.
>
>     and then provide the root path as follow:
>
>     SET(CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc
>     ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/JPEGLIB/jpegsrc-9c
>     ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/zlib-1.2.3-lib
>     ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/libpng-1.2.37-lib
>     ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/ftgl-binary
>     ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/freetype-dev_2.4.2-1
>     ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/iconv-1.9.2.1
>     ??? ??? ??? ??? ??? ??? )
>
>
>     unfortunately, the project is not cloned when cmake is launched
>     and the next dependencies don't find the packages :-(
>
>     What Can I do ?
>
>     Regards,
>
>     S.Ancelot
>     -- 
>
>     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
>     <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
>     <http://cmake.org/cmake/help/support.html>
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     <http://cmake.org/cmake/help/consulting.html>
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>     <http://cmake.org/cmake/help/training.html>
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>     <http://www.kitware.com/opensource/opensource.html>
>
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
>     <https://cmake.org/mailman/listinfo/cmake>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180502/f19d6d0f/attachment.html>

From petr.kmoch at gmail.com  Wed May  2 04:47:00 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 2 May 2018 10:47:00 +0200
Subject: [CMake] using ExternalProject_Add when cmake is launched
In-Reply-To: <4d9229ab-063a-9627-cd8a-3dc01f80f9b6@numalliance.com>
References: <c221a91f-5f4f-0a71-06cc-52d2fe8cf71f@numalliance.com>
 <CAEOrzjq57x__t0e_f503CSbpvOZB1zj_SsdmDZaVbb3zeMsGYQ@mail.gmail.com>
 <4d9229ab-063a-9627-cd8a-3dc01f80f9b6@numalliance.com>
Message-ID: <CAKohaZdh9HfqEg2bkRNdpjPu5CPTji5suLUyrFLMVJ5=MbzE1Q@mail.gmail.com>

Hi Stephane.

ExternalProject is designed to run at *build* time, not at *CMake* time. It
is not really intended for mixing with normal, non-ExternalProject targets
(such as those created by add_library).

When using ExternalProject, the canonical form of operation is a
SuperBuild-style project: your master CMakeLists.txt will contain only
ExternalProject_Add() calls, *including one for your normal project.* Your
normal project becomes just another project managed by the SuperBuild. The
SuperBuild's purpose is to download, configure, build, etc., all the
subprojects. So you generate the SuperBuild and then build it once to get
all the dependencies in place. The you switch to using just the YourProject
"child" of the SuperBuild and do normal development there.

I think googling "CMake ExternalProject_Add superbuild" will give you
enough details to get you going.

Petr

On 2 May 2018 at 10:31, St?phane Ancelot <sancelot at numalliance.com> wrote:

> include(ExternalProject)
>
> ExternalProject_Add(
>     WIN32DEPSV2
>     PREFIX ${CMAKE_CURRENT_BINARY_DIR}/WIN32DEPSV2
>     DOWNLOAD_DIR .
>     STAMP_DIR ./stamps
>     SOURCE_DIR   WIN32DEPSV2
>     GIT_REPOSITORY git at numagit.numalliance.com:THIRD_PARTIES/WIN32DEPS.git
>     CONFIGURE_COMMAND ""
>     BUILD_COMMAND ""
>     BUILD_IN_SOURCE 1
>     INSTALL_COMMAND ""
> )
>
> add_library(your_other_target ...)
>
> add_dependencies(your_other_target WIN32DEPSV2)
>
> find_package(Freetype REQUIRED QUIET)
>
> Launching cmake does not clone the git folder , but continues and fails
> with the find_package command
>
> CMake Error at /usr/local/cmake-3.10.3-Linux-x86_64/share/cmake-3.10/
> Modules/FindPackageHandleStandardArgs.cmake:137 (message):
>   Could NOT find Freetype (missing: FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS)
> Call Stack (most recent call first):
>   /usr/local/cmake-3.10.3-Linux-x86_64/share/cmake-3.10/Modules/
> FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
>   /usr/local/cmake-3.10.3-Linux-x86_64/share/cmake-3.10/Modules/FindFreetype.cmake:157
> (find_package_handle_standard_args)
>   FOX64/CMakeLists.txt:919 (find_package)
>
> Le 02/05/2018 ? 09:32, Kai Wolf a ?crit :
>
> You probably need to manually add a dependency from your ExternalProject
> to your target that needs the libraries.
> For instance
>
>     ExternalProject_Add(fetch_win32_libs ...)
>     add_library(your_other_target ...)
>
>
> Greetings
>
> Kai Wolf
>
> http://kai-wolf.me/
> kai.wolf at gmail.com
>
> 2018-05-02 8:47 GMT+02:00 St?phane Ancelot <sancelot at numalliance.com>:
>
>> Hi,
>>
>> I have got some win32 libraries dependencies stored in a project .
>>
>> Then I added ExternalProject_Add at beginning of my cmakelists file in
>> order to clone this dependency to be available.
>>
>> and then provide the root path as follow:
>>
>> SET(CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc
>> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/JPEGLIB/jpegsrc-9c
>> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/zlib-1.2.3-lib
>> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/libpng-1.2.37-lib
>> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/ftgl-binary
>> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/freetype-dev_2.4.2-1
>> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/iconv-1.9.2.1
>>                         )
>>
>>
>> unfortunately, the project is not cloned when cmake is launched and the
>> next dependencies don't find the packages :-(
>>
>> What Can I do ?
>>
>> Regards,
>>
>> S.Ancelot
>> --
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180502/f7fa3579/attachment-0001.html>

From rsberger1 at hotmail.com  Wed May  2 12:08:00 2018
From: rsberger1 at hotmail.com (Bob Berger)
Date: Wed, 2 May 2018 16:08:00 +0000
Subject: [CMake] CTest: running script failing returning: -1
Message-ID: <BN6PR13MB11211AE04D526620270BCFB6FA800@BN6PR13MB1121.namprd13.prod.outlook.com>

Hi,


I have been using CTest to successfully run continuous builds for several years, but my continuous builds have been failing since I moved them from a Windows Server 2008 R2 machine to a Windows Server 2012 R2 machine. To diagnose the problem, I added the --debug option to the CTest command-line,  and even built a debug version of the CMake source code (I'm running CMake 3.9). The output from the --debug option ends with this line:


D:\temp\cmake-3.9.0\Source\cmCTest.cxx:2182 running script failing returning: -1


Can anyone tell my what might cause CTest to return -1? How would one go about finding the underlying cause?


I can post my full output log if necessary, but it shows no errors before this one, and this one occurs just after it's successfully retrieved a revision number from my Subversion source code repository.


It's worth noting that I also moved CTest-based nightly builds from the old machine to the new, and the nightly builds run fine on the new machine. Since my nightly and continuous builds are very similar, it's surprising that one works and the other doesn't.


Thanks for any assistance,

Bob


Sent from Outlook<http://aka.ms/weboutlook>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180502/9d7370a0/attachment.html>

From mellery451 at gmail.com  Wed May  2 12:45:14 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Wed, 2 May 2018 09:45:14 -0700
Subject: [CMake] advice for resolving errors with CMake 3.8
Message-ID: <AD7BEA85-C4DE-4F13-A7C3-4CA8417FB046@gmail.com>

I generally develop on a latest cmake (provided by homebrew) and that works well for me. Unfortunately, I also need to support Visual Studio builds and it looks like the cmake that is bundled with VS is 3.8. I?m apparently using bleeding-edge features related to IMPORTED libraries, judging by these errors:

||   Cannot specify include directories for imported target ?some_lib?.

||   add_library cannot create ALIAS target ?NIH::some_lib" because target
||   ?some_lib" is IMPORTED.

||   Cannot specify compile options for imported target ?some_lib".
|| 

What is the recommended way to deal with include dirs and compile settings for IMPORTED targets with pre-3.11? 

Thanks,
Mike



From irwin at beluga.phys.uvic.ca  Wed May  2 18:55:34 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Wed, 2 May 2018 15:55:34 -0700 (PDT)
Subject: [CMake] advice for resolving errors with CMake 3.8
In-Reply-To: <AD7BEA85-C4DE-4F13-A7C3-4CA8417FB046@gmail.com>
References: <AD7BEA85-C4DE-4F13-A7C3-4CA8417FB046@gmail.com>
Message-ID: <alpine.DEB.2.11.1805021540200.10037@enira.zlyna.ubzr>

On 2018-05-02 09:45-0700 Michael Ellery wrote:

> I generally develop on a latest cmake (provided by homebrew) and that works well for me. Unfortunately, I also need to support Visual Studio builds and it looks like the cmake that is bundled with VS is 3.8. I?m apparently using bleeding-edge features related to IMPORTED libraries, judging by these errors:
>
> ||   Cannot specify include directories for imported target ?some_lib?.
>
> ||   add_library cannot create ALIAS target ?NIH::some_lib" because target
> ||   ?some_lib" is IMPORTED.
>
> ||   Cannot specify compile options for imported target ?some_lib".
> ||
>
> What is the recommended way to deal with include dirs and compile settings for IMPORTED targets with pre-3.11?

Hi Michael:

Just in case nobody comes up with a simple solution for your question
about taking the backward step (in my opinion) of making your build
system compatible with CMake-3.8, have you tried to download and
install CMake version 3.11 from KitWare for Windows to see if that
works well for your VS platform?  (My guess is you would merely need
to change the PATH so that CMake version 3.11 rather than CMake
version 3.8 was used, but I don't have any VS experience so it might
be more complicated than that.) Anyhow, I thought this idea was worth
a shot since it allows you to stick with CMake-3.11 compatibility for
your build system.

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
__________________________

From mellery451 at gmail.com  Wed May  2 19:12:18 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Wed, 2 May 2018 16:12:18 -0700
Subject: [CMake] advice for resolving errors with CMake 3.8
In-Reply-To: <alpine.DEB.2.11.1805021540200.10037@enira.zlyna.ubzr>
References: <AD7BEA85-C4DE-4F13-A7C3-4CA8417FB046@gmail.com>
 <alpine.DEB.2.11.1805021540200.10037@enira.zlyna.ubzr>
Message-ID: <A8887A95-3374-408B-9A56-CCA91ED6E172@gmail.com>


> On May 2, 2018, at 3:55 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> 
> On 2018-05-02 09:45-0700 Michael Ellery wrote:
> 
>> I generally develop on a latest cmake (provided by homebrew) and that works well for me. Unfortunately, I also need to support Visual Studio builds and it looks like the cmake that is bundled with VS is 3.8. I?m apparently using bleeding-edge features related to IMPORTED libraries, judging by these errors:
>> 
>> ||   Cannot specify include directories for imported target ?some_lib?.
>> 
>> ||   add_library cannot create ALIAS target ?NIH::some_lib" because target
>> ||   ?some_lib" is IMPORTED.
>> 
>> ||   Cannot specify compile options for imported target ?some_lib".
>> ||
>> 
>> What is the recommended way to deal with include dirs and compile settings for IMPORTED targets with pre-3.11?
> 
> Hi Michael:
> 
> Just in case nobody comes up with a simple solution for your question
> about taking the backward step (in my opinion) of making your build
> system compatible with CMake-3.8, have you tried to download and
> install CMake version 3.11 from KitWare for Windows to see if that
> works well for your VS platform?  (My guess is you would merely need
> to change the PATH so that CMake version 3.11 rather than CMake
> version 3.8 was used, but I don't have any VS experience so it might
> be more complicated than that.) Anyhow, I thought this idea was worth
> a shot since it allows you to stick with CMake-3.11 compatibility for
> your build system.
> 
> Alan

HI Alan, 

Thanks for your suggestion. I wish it were that easy, but the bundled VS CMake is pretty tightly coupled and you can?t easily replace it. I believe they also rely on one or two features they might have added or enabled in their build of cmake - so they are currently maintaining a divergent fork that hopefully will eventually get mainlined (?).

In the meantime, it looks like I just need to switch to set_target_properties for 3.8 instead of trying to use target_include_directories on an IMPORTED target. This seems to be working so far.

Thanks,
Mike


From erkam.murat.bozkurt at gmail.com  Wed May  2 19:30:18 2018
From: erkam.murat.bozkurt at gmail.com (Erkam Murat Bozkurt)
Date: Thu, 3 May 2018 02:30:18 +0300
Subject: [CMake] ThreadStack Project: a new innovative open source software
 for multi-thread computing
Message-ID: <CA+oH3ZOWZALTJieJGCrMG4RrMaOU52dViVSYQX2GrVPuyXmt0Q@mail.gmail.com>

I have developed a new open source software as a result of a scientific
research and I want to share my study with scientists and/or software
developers.

ThreadStack is an innovative software which produces a class library for
C++ multi-thread programming and the outcome of the ThreadStack acts as an
autonomous management system for the thread synchronization tasks.
ThreadStack has a nice and useful graphical user interface and includes a
short tutorial and code examples. ThreadStack offers a new way for
multi-thread computing and it uses a meta program in order to produce an
application specific thread synchronization library. Therefore, the
programmer must read the tutorial to be able to use the software. The
tutorial includes the main designs of the program.

Not surprisingly, application development with the ThreadStack is much more
easy than the classical C++ threading libraries thanks to the its
autonomous management system. Currently, ThreadStack runs only on Linux
based operating systems. In the near future, it will be runnable for the
other operating systems. An academic journal submission has been performed
for the study and the scientific introduction of the project will be
readable from an academic journal as soon as possible.

I believe that I can improve my knowledge and my software may be better
with your advices. ThreadStack can be downloaded from sourcefource and link
is given in below.


https://sourceforge.net/projects/threadstack/


threadstack.help at gmail.com

I am waiting your valuable comments.

Thanks and best regards.

Erkam Murat Bozkurt,

M. Sc Control Systems Engineering.

Istanbul / Turkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180503/5542bca0/attachment-0001.html>

From mailinglists at xgm.de  Thu May  3 03:36:03 2018
From: mailinglists at xgm.de (Florian Lindner)
Date: Thu, 3 May 2018 09:36:03 +0200
Subject: [CMake] Cache variables from module
Message-ID: <74ac274d-f4f7-125f-4b40-eab9b23b2413@xgm.de>

Hello,

I have a third party FindPETSc.cmake module:

https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake

The problem I have, is that variable PETSC_VERSION is not set when cmake is run for a second time

https://github.com/jedbrown/cmake-modules/issues/28

What is best way to deal with that?

Can an entire function be cached, e.g. petsc_get_version or is adding CACHE to the set calls of PETSC_VERSION the best way?

Adding CACHE INTERNAL gives me error messages:

set (PETSC_VERSION "${PETSC_VERSION_MAJOR}.${PETSC_VERSION_MINOR}.${PETSC_VERSION_SUBMINOR}" CACHE INTERNAL "PETSc
version" PARENT_SCOPE)


CMake Error at tools/cmake-modules/FindPETSc.cmake:314 (if):
  if given arguments:

    "3.8.4" "CACHE" "INTERNAL" "PETSc version" "VERSION_LESS" "3.1"

  Unknown arguments specified



Thanks!
Florian

From sjm324 at cornell.edu  Thu May  3 10:02:49 2018
From: sjm324 at cornell.edu (Stephen McDowell)
Date: Thu, 03 May 2018 14:02:49 +0000
Subject: [CMake] advice for resolving errors with CMake 3.8
In-Reply-To: <A8887A95-3374-408B-9A56-CCA91ED6E172@gmail.com>
References: <AD7BEA85-C4DE-4F13-A7C3-4CA8417FB046@gmail.com>
 <alpine.DEB.2.11.1805021540200.10037@enira.zlyna.ubzr>
 <A8887A95-3374-408B-9A56-CCA91ED6E172@gmail.com>
Message-ID: <CAJGuVd-nB=je2X5+4gkNjX-T-fc5q-PKNt9PApiK3Ut7X4BGHQ@mail.gmail.com>

If you don't want to have to keep switching to Windows and back to test,
the most reliable way to know with absolute certainty is to install CMake
3.8 on OSX and use that.

Fortunately building cmake is actually quite easy, you can even use the
newer cmake from brew to configure the older one (use cmake to build
cmake!).

Make sure you set CMAKE_INSTALL_PREFIX to somewhere you know about (e.g.
/opt/cmake-3.8). When you need to test this project, update your path to
point there

export PATH="/opt/cmake-3.8/bin:$PATH"

You need to run that export command for every terminal, or put it in your
~/.bashrc while developing this project.

If you don't set CMAKE_INSTAL_PREFIX, `make install` will put it in
/usr/local by default which will make it more challenging to uninstall in
the future when you want to use cmake 3.11 from brew. Putting it in /opt
makes it so you can just delete that entire /opt/cmake-3.8 folder and/or
comment out the export command in your ~/.bashrc (making sure to launch a
new terminal and verify cmake --version after editing your ~/.bashrc).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180503/8fc243f2/attachment.html>

From isaiah.norton at gmail.com  Thu May  3 10:39:31 2018
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Thu, 3 May 2018 10:39:31 -0400
Subject: [CMake] Cache variables from module
In-Reply-To: <74ac274d-f4f7-125f-4b40-eab9b23b2413@xgm.de>
References: <74ac274d-f4f7-125f-4b40-eab9b23b2413@xgm.de>
Message-ID: <CADFtqorJ+MSjHR-UOiFzby6G2NUZKVq_8xvQSaerZtRjqzstWA@mail.gmail.com>

PARENT_SCOPE and CACHE can't be used in the same call, presumably because
cache is global. So cmake doesn't recognize those arguments, and instead
sets the variable PETSC_VERSION to a list containing all the following
arguments except PARENT_SCOPE (which does still apply). Perhaps a newer
cmake version will give an error.
Try:

    set (PETSC_VERSION "${PETSC_VERSION_MAJOR}.${PETS
C_VERSION_MINOR}.${PETSC_VERSION_SUBMINOR}" CACHE INTERNAL "PETSc
version")

(possibly also with `FORCE`, though it probably doesn't make sense for a
user to ever set that manually)

On Thu, May 3, 2018 at 3:36 AM, Florian Lindner <mailinglists at xgm.de> wrote:

> Hello,
>
> I have a third party FindPETSc.cmake module:
>
> https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake
>
> The problem I have, is that variable PETSC_VERSION is not set when cmake
> is run for a second time
>
> https://github.com/jedbrown/cmake-modules/issues/28
>
> What is best way to deal with that?
>
> Can an entire function be cached, e.g. petsc_get_version or is adding
> CACHE to the set calls of PETSC_VERSION the best way?
>
> Adding CACHE INTERNAL gives me error messages:
>
> set (PETSC_VERSION "${PETSC_VERSION_MAJOR}.${PETSC_VERSION_MINOR}.${PETSC_VERSION_SUBMINOR}"
> CACHE INTERNAL "PETSc
> version" PARENT_SCOPE)
>
>
> CMake Error at tools/cmake-modules/FindPETSc.cmake:314 (if):
>   if given arguments:
>
>     "3.8.4" "CACHE" "INTERNAL" "PETSc version" "VERSION_LESS" "3.1"
>
>   Unknown arguments specified
>
>
>
> Thanks!
> Florian
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180503/0b5b1c8f/attachment.html>

From isaiah.norton at gmail.com  Thu May  3 10:44:46 2018
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Thu, 3 May 2018 10:44:46 -0400
Subject: [CMake] Cache variables from module
In-Reply-To: <CADFtqorJ+MSjHR-UOiFzby6G2NUZKVq_8xvQSaerZtRjqzstWA@mail.gmail.com>
References: <74ac274d-f4f7-125f-4b40-eab9b23b2413@xgm.de>
 <CADFtqorJ+MSjHR-UOiFzby6G2NUZKVq_8xvQSaerZtRjqzstWA@mail.gmail.com>
Message-ID: <CADFtqortGD5tZtjKPCUD14SjCBR58G9H_SQVKkU1qK7ttAvjTg@mail.gmail.com>

>
> Perhaps a newer cmake version will give an error.
>

Just tested with 3.11 -- sadly not. But the suggested fix does work.

On Thu, May 3, 2018 at 10:39 AM, Isaiah Norton <isaiah.norton at gmail.com>
wrote:

> PARENT_SCOPE and CACHE can't be used in the same call, presumably because
> cache is global. So cmake doesn't recognize those arguments, and instead
> sets the variable PETSC_VERSION to a list containing all the following
> arguments except PARENT_SCOPE (which does still apply). Perhaps a newer
> cmake version will give an error.
> Try:
>
>     set (PETSC_VERSION "${PETSC_VERSION_MAJOR}.${PETS
> C_VERSION_MINOR}.${PETSC_VERSION_SUBMINOR}" CACHE INTERNAL "PETSc
> version")
>
> (possibly also with `FORCE`, though it probably doesn't make sense for a
> user to ever set that manually)
>
> On Thu, May 3, 2018 at 3:36 AM, Florian Lindner <mailinglists at xgm.de>
> wrote:
>
>> Hello,
>>
>> I have a third party FindPETSc.cmake module:
>>
>> https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake
>>
>> The problem I have, is that variable PETSC_VERSION is not set when cmake
>> is run for a second time
>>
>> https://github.com/jedbrown/cmake-modules/issues/28
>>
>> What is best way to deal with that?
>>
>> Can an entire function be cached, e.g. petsc_get_version or is adding
>> CACHE to the set calls of PETSC_VERSION the best way?
>>
>> Adding CACHE INTERNAL gives me error messages:
>>
>> set (PETSC_VERSION "${PETSC_VERSION_MAJOR}.${PETS
>> C_VERSION_MINOR}.${PETSC_VERSION_SUBMINOR}" CACHE INTERNAL "PETSc
>> version" PARENT_SCOPE)
>>
>>
>> CMake Error at tools/cmake-modules/FindPETSc.cmake:314 (if):
>>   if given arguments:
>>
>>     "3.8.4" "CACHE" "INTERNAL" "PETSc version" "VERSION_LESS" "3.1"
>>
>>   Unknown arguments specified
>>
>>
>>
>> Thanks!
>> Florian
>> --
>>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180503/a1b6e10a/attachment-0001.html>

From bill.hoffman at kitware.com  Thu May  3 11:29:26 2018
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Thu, 3 May 2018 11:29:26 -0400
Subject: [CMake] using ExternalProject_Add when cmake is launched
In-Reply-To: <CAKohaZdh9HfqEg2bkRNdpjPu5CPTji5suLUyrFLMVJ5=MbzE1Q@mail.gmail.com>
References: <c221a91f-5f4f-0a71-06cc-52d2fe8cf71f@numalliance.com>
 <CAEOrzjq57x__t0e_f503CSbpvOZB1zj_SsdmDZaVbb3zeMsGYQ@mail.gmail.com>
 <4d9229ab-063a-9627-cd8a-3dc01f80f9b6@numalliance.com>
 <CAKohaZdh9HfqEg2bkRNdpjPu5CPTji5suLUyrFLMVJ5=MbzE1Q@mail.gmail.com>
Message-ID: <39122a44-2576-54a2-0efd-74d06f472e79@kitware.com>

On 5/2/2018 4:47 AM, Petr Kmoch wrote:
> Hi Stephane.
>
> ExternalProject is designed to run at *build* time, not at *CMake* 
> time. It is not really intended for mixing with normal, 
> non-ExternalProject targets (such as those created by add_library).
>
> When using ExternalProject, the canonical form of operation is a 
> SuperBuild-style project: your master CMakeLists.txt will contain only 
> ExternalProject_Add() calls, *including one for your normal project.* 
> Your normal project becomes just another project managed by the 
> SuperBuild. The SuperBuild's purpose is to download, configure, build, 
> etc., all the subprojects. So you generate the SuperBuild and then 
> build it once to get all the dependencies in place. The you switch to 
> using just the YourProject "child" of the SuperBuild and do normal 
> development there.
>
> I think googling "CMake ExternalProject_Add superbuild" will give you 
> enough details to get you going.

Another option can be found in the most recent CMake 3.11:

https://cmake.org/cmake/help/git-stage/module/FetchContent.html

That should do what you want. It can not build or configure like 
external project, but it can download at cmake time.

-Bill





From aaron at assonance.org  Thu May  3 13:52:03 2018
From: aaron at assonance.org (remleduff)
Date: Thu, 3 May 2018 10:52:03 -0700 (MST)
Subject: [CMake] C library export management,
 please critique and improve and tell me if there's a better way
Message-ID: <1525369923959-0.post@n2.nabble.com>

Hello!

I'm converting a legacy C code base with a slightly unusual problem, but one
that I've seen elsewhere occasionally. Basically, the libraries were not
written with any concept of namespace cleanliness, and when they are linked
together there are many symbol conflicts. Worse, there are symbol conflicts
in object files with the same name, which apparently silently link
successfully without warning!

The legacy build system used some scripting to process all libraries and
object files through objcopy, and I'm attempting to do something similar in
cmake.

I'd appreciate any critique and improvements for this code. Particularly,
I'm not sure why using
"${TARGET_PROPERTY:${target},INTERFACE_LINK_LIBRARIES>" doesn't work. I'd
also love help simplifying the two custom commands.


The approach I'm taking is to define a new target: ${target}-doexport which
renames all symbols in the library except for the exported ones. I then
create an INTERFACE library named ${target}-export which copies the
INTERFACE properties from the orginal target and uses output that has been
properly prefixed. FInally, I create an alias target to the new library,
which is what is actually used in the rest of the codebase to link against.


It's expect to be used like so:
add_library(foo bar.c)
target_link_libraries(foo PUBLIC Threads::Threads)
target_include_directories(foo PUBLIC inc)
target_export_symbols(foo project::foo
   symbol1
   another_symbol
   )

#or refer to symbols in another file
target_export_symbols(foo project::foo
   INTERFACE foo_exports
   )

function(target_export_symbols target export_target)
    set(options)
    set(oneValueArgs INTERFACE)
    set(multiValueArgs)
    cmake_parse_arguments(PARSE_ARGV 2
            export
            "${options}"
            "${oneValueArgs}"
            "${multiValueArgs}")

    set(name "${CMAKE_CURRENT_BINARY_DIR}/lib${target}.a")
    set(export_name "${CMAKE_CURRENT_BINARY_DIR}/lib${target}-export.a")
    set(stamp ${CMAKE_CURRENT_BINARY_DIR}/${target}-export.stamp)
    set(prefix ${target}_)
    set(exports ${CMAKE_CURRENT_BINARY_DIR}/${target}-exported_symbols)
    set(renames ${CMAKE_CURRENT_BINARY_DIR}/${target}-renamed_symbols)

    if(export_INTERFACE AND EXISTS
${CMAKE_CURRENT_SOURCE_DIR}/${export_INTERFACE})
        set(interface ${CMAKE_CURRENT_SOURCE_DIR}/${export_INTERFACE})
        set(interface_cmd "`cat ${interface}`")
    else()
        set(interface)
        set(interface_cmd)
    endif()

    add_custom_command(OUTPUT ${exports}
            DEPENDS "${interface}" ${CMAKE_CURRENT_LIST_FILE}
            COMMAND echo ${interface_cmd} ${export_UNPARSED_ARGUMENTS} |
perl -lane \'print \"\$$_\\$$\" for @F\' > ${exports}
            )

    add_custom_command(OUTPUT ${stamp} ${export_name}
        COMMENT "Unexporting symbols from ${target}"
        DEPENDS ${exports} ${target}
        COMMAND nm --defined-only -g ${name} | grep -v -e\'^ W\' -e\'^ V\'
-f ${exports} | awk \'NF>2 { print \$$3 \" ${prefix}\" \$$3 }\' | sort -u >
${renames}
        COMMAND objcopy --redefine-syms=${renames} ${name} ${export_name}
        COMMAND cmake -E touch ${stamp}
    )
    add_library(${target}-export INTERFACE)
    add_custom_target(${target}-doexport DEPENDS ${stamp})
    add_dependencies(${target}-export ${target} ${target}-doexport)

    foreach(prop INTERFACE_COMPILE_DEFINITIONS INTERFACE_COMPILE_OPTIONS
INTERFACE_LINK_LIBRARIES INTERFACE_INCLUDE_DIRECTORIES)
        set(val "$<TARGET_PROPERTY:${target},${prop}>")
# INTERFACE_LINK_LIBRARIES causes linker failures when used with above
generator expression...
        if (${prop} MATCHES INTERFACE_LINK_LIBRARIES)
            get_target_property(val ${target} ${prop})
            if (NOT val)
                set(val "")
            endif()
            list(APPEND val ${export_name})
        endif()
        if(val)
            set_target_properties(${target}-export PROPERTIES "${prop}"
"${val}")
        endif()
    endforeach()
    add_library(${export_target} ALIAS ${target}-export)

endfunction()



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

From rozelak at volny.cz  Fri May  4 07:25:23 2018
From: rozelak at volny.cz (rozelak at volny.cz)
Date: Fri, 04 May 2018 13:25:23 +0200
Subject: [CMake] =?utf-8?q?Install_libraries_defined_in_INTERFACE_targets?=
Message-ID: <20180504132523.2CC5D5E3@volny.cz>

Hello,
I build a project which consists of several "modules" with various mutual dependencies. Each module defines its OBJECT target as:
?
?
? ? # Module 1:
? ? add_library(Module1 OBJECT ....)
? ? target_include_directories(Module1 PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
?
? ? add_library(Module1_LIBRARIES INTERFACE)
? ? target_link_libraries(Module1_LIBRARIES INTERFACE $<BUILD_INTERFACE:....>)
?
?
? ? # Module 2:
? ? add_library(Module2 OBJECT ....)
? ? target_include_directories(Module2 PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>)
?
? ? add_library(Module2_LIBRARIES INTERFACE)
? ? target_link_libraries(Module2_LIBRARIES INTERFACE $<BUILD_INTERFACE:....> $<BUILD_INTERFACE:Module1_LIBRARIES>)
?
? ? add_library(Module2_INCLUDES? INTERFACE)
? ? target_include_directories(Module2_INCLUDES? INTERFACE $<TARGET_PROPERTY:Module2,INCLUDE_DIRECTORIES>)
? ? target_sources(Module2_INCLUDES? INTERFACE ....)
?
? ? add_library(Module_CONFFILE? INTERFACE)
? ? target_sources(Module2_CONFFILE? INTERFACE Module.config)
?
?
And when building a final product (or one of the final products), I use the individual targets:
?
? ? add_library(Product1 STATIC $<TARGET_OBJECTS:Module1> $<TARGET_OBJECTS:Module2> ...)
? ? target_link_libraries(Product1 LINK_INTERFACE_LIBRARIES $<BUILD_INTERFACE:Module1_LIBRARIES> $<BUILD_INTERFACE:Module2_LIBRARIES> ...)
?
?
?
It works perfectly, the library is built using all the sources. Even when defining INSTALL, all the properties of the targets (include files, config files, etc.) can be accessed and are installed correctly
?
? ? install(TARGETS Product1? DESTINATION "./" EXPORT "libProduct1")
? ? install(FILES $<TARGET_PROPERTY:Module2_CONFFILE,INTERFACE_SOURCES>? ? ? ? ? DESTINATION "./config")
? ? install(FILES $<TARGET_PROPERTY:Module2_INCLUDES,INTERFACE_SOURCES>? ? ? ? ? DESTINATION "./include")
?
? ??
The problem starts when I want to export a CMake file listing all the libraries which were defined by the individual modules (and are accessed by $<BUILD_INTERFACE:Module2_LIBRARIES>) since they know what they need (how they were configured).
?
When building a static library (which is shown here), I need to export a list of additional libraries necessary to link the Product1 correctly. But using $<BUILD_INTERFACE:Module[]_LIBRARIES> in the INSTALL() command does not work, neither works something like:
?
? ? install(EXPORT "llibProduct1" DESTINATION "." EXPORT_LINK_INTERFACE_LIBRARIES)
?
?
So the question is: how to export the libraries defined by the individual modules to an CMake file which would be installed together with the Product1 library and header files?
?
?
Thank you very much,
Dan
?
P.S. I use CMake 3.6.2.

From francis.giraldeau at gmail.com  Fri May  4 11:33:44 2018
From: francis.giraldeau at gmail.com (Francis Giraldeau)
Date: Fri, 04 May 2018 15:33:44 +0000
Subject: [CMake] Why isn't target_link_libraries not enough in some
 cases?
Message-ID: <CAC6yHM6gO-i2VpSGqNE6N_F5tD1LBCGsSAcuYq00tySHm_LUfw@mail.gmail.com>

> Hi,
>
> I am fetching and building SDL2 using FetchContent and then using
> target_link_libraries(MyExe SDL2) in the hopes that the required include
> directories and libraries will be added populated properly. The example
> project can be found here:
>
> https://github.com/samaursa/cmake_fetch_content_SDL2
>
> Unfortunately, it seems that I have to manually specify the include
> directories. Although target_link_directories(...) does take care of the
> linking against the correct libraries. When it comes to my own CMake
> enabled libraries, I do not have to specify the include directories.

The SDL add_library() only specify the include directory for install
target:

  target_link_libraries(SDL2 ${EXTRA_LIBS} ${EXTRA_LDFLAGS})
  target_include_directories(SDL2 PUBLIC $<INSTALL_INTERFACE:include/SDL2>)

They themselves include directories using the old global includes instead
of target specific includes:

  include_directories(${SDL2_BINARY_DIR}/include ${SDL2_SOURCE_DIR}/include)

There should be a target_include_directories(SDL2 PUBLIC
<$BUILD_INTERFACE:${SDL2_SOURCE_DIR}/include), but that must be in the same
CMakeLists that defines the library, which require changing the SDL's
CMakeLists.

So, one solution could be to create an imported target to attach this path
and l ink to it instead:

  add_library(SDL2x INTERFACE IMPORTED)
  set_target_properties(SDL2x PROPERTIES INTERFACE_INCLUDE_DIRECTORIES
"${sdl2_SOURCE_DIR}/include")
  set_target_properties(SDL2x PROPERTIES INTERFACE_LINK_LIBRARIES SDL2)

Tested with CMake 3.11. However, to make it work, I had to add OpenGL:

  find_package(OpenGL REQUIRED)
  target_link_libraries(testExe SDL2x OpenGL::GL)

Install fails, but that's another issue (the symlink is created in the
wrong directory) and this should be reported to SDL I guess.

CMake Error at _deps/sdl2-build/cmake_install.cmake:188 (file):
  file INSTALL cannot find
  "[...]/build/_deps/sdl2-build/libSDL2.so".
Call Stack (most recent call first):
  cmake_install.cmake:42 (include)

Francis
-- 
Francis Giraldeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180504/02528906/attachment.html>

From kim.walisch at gmail.com  Fri May  4 13:48:31 2018
From: kim.walisch at gmail.com (Kim Walisch)
Date: Fri, 4 May 2018 19:48:31 +0200
Subject: [CMake] Linking programs with Clang & OpenMP fails
Message-ID: <CAE_DJ11my+ROmE1QapU=JG=89PDEyGAKsHCetn2CpxJaCMvGzg@mail.gmail.com>

Hi,

The latest Clang-6.0 compiler finally enables OpenMP by default on
Linux (e.g. Ubuntu-18 x86_64).

But OpenMP programs using Clang-6.0/CMake-3.10 fail to compile:

[100%] Linking CXX executable primecount
libprimecount.a(P2.cpp.o): In function `.omp_outlined..7':
P2.cpp:(.text+0x2194): undefined reference to `__atomic_load'
P2.cpp:(.text+0x21ef): undefined reference to `__atomic_compare_exchange'
CMakeFiles/primecount.dir/build.make:148: recipe for target 'primecount'
failed
make[2]: *** [primecount] Error 1

The problem is that:

target_link_libraries(myprogram OpenMP::OpenMP_CXX)

does not add libatomic to the linker options which LLVM/Clang's OpenMP
library depends upon. When I manually add -latomic to the linker
options my OpenMP programs compile & link fine using Clang-6.0/CMake-3.10.

Regards,
Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180504/c407b58b/attachment.html>

From gartung at fnal.gov  Fri May  4 14:16:10 2018
From: gartung at fnal.gov (Patrick E Gartung)
Date: Fri, 4 May 2018 18:16:10 +0000
Subject: [CMake] Memory usage and configuration time for large project
In-Reply-To: <CAAD4mYj-Bu2usBUy0VWGf8R_zF62E4zZ3YdUvS39mjC89pHsUA@mail.gmail.com>
References: <ABC8A9FA-9573-4622-938E-5C3694F49C56@fnal.gov>
 <CAAD4mYj-Bu2usBUy0VWGf8R_zF62E4zZ3YdUvS39mjC89pHsUA@mail.gmail.com>
Message-ID: <277602CF-2D9A-4273-A93B-33F9449BB1C0@fnal.gov>

Just to be clear, the memory and time used are just to configure and generate the makefiles or Ninja file. The build itself can take several hours.

?On 4/30/18, 4:55 PM, "R0b0t1" <r030t1 at gmail.com> wrote:

    On Mon, Apr 30, 2018 at 4:44 PM, Patrick E Gartung <gartung at fnal.gov> wrote:
    >  Hi,
    >
    > We have a large c/c++/fortran project, CMSSW, that is built with a custom tool, scram. 
    >
    > https://github.com/cms-sw/cmssw
    >
    > The project might move to a cmake based build in the future. The scripts to convert to CmakeLists.tx has been written
    >
    > https://github.com/cms-sw/cmssw2cmake
    >
    > Tests show that with the cmake files generated with this script, configuring the project uses up to 1.5GB of ram and takes 11 minutes when using -GMakefiles. Using -GNinja and using the latest cmake, this time can be reduced to 8 minutes.
    >
    > The project builds 14k object files, 2.2k libraries, ~600 binaries, 500 generated source files with links to ~100 external libraries.
    >
    > Is this amount of memory usage and time typical for a project of this size?
    >
    
    I'm inclined to say "yes" as many builds such as Firefox, its
    supporting libraries, and Chrome all take lots of time and memory.
    Chrome uses Ninja, I might add. But the issue is not CMake itself.
    CMake tends to produce better builds.
    
    As I am not intimately familiar with your project, I can't make good
    concrete suggestions. You may enjoy reading
    https://news.ycombinator.com/item?id=14733829 and searching for build
    optimization strategies.
    
    Keep in mind a lot of the blame falls on C++ and Windows, should you
    be using Windows. If you aren't using Windows, then the advice in the
    comments above should still be relevant, and give you something to go
    on.
    
    Cheers,
         R0b0t1
    
    > Patrick Gartung
    > Fermilab
    >
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2799 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20180504/55e64509/attachment.bin>

From craig.scott at crascit.com  Fri May  4 17:59:00 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 5 May 2018 07:59:00 +1000
Subject: [CMake] Why isn't target_link_libraries not enough in some
 cases?
In-Reply-To: <CAC6yHM6gO-i2VpSGqNE6N_F5tD1LBCGsSAcuYq00tySHm_LUfw@mail.gmail.com>
References: <CAC6yHM6gO-i2VpSGqNE6N_F5tD1LBCGsSAcuYq00tySHm_LUfw@mail.gmail.com>
Message-ID: <CA+dygYkwwZ+V=6AN0q2RQnTG6z5oDvYs_0QQ+th2xyEJgTf7tw@mail.gmail.com>

On Sat, May 5, 2018 at 1:33 AM, Francis Giraldeau <
francis.giraldeau at gmail.com> wrote:

> > Hi,
> >
> > I am fetching and building SDL2 using FetchContent and then using
> > target_link_libraries(MyExe SDL2) in the hopes that the required include
> > directories and libraries will be added populated properly. The example
> > project can be found here:
> >
> > https://github.com/samaursa/cmake_fetch_content_SDL2
> >
> > Unfortunately, it seems that I have to manually specify the include
> > directories. Although target_link_directories(...) does take care of the
> > linking against the correct libraries. When it comes to my own CMake
> > enabled libraries, I do not have to specify the include directories.
>
> The SDL add_library() only specify the include directory for install
> target:
>
>   target_link_libraries(SDL2 ${EXTRA_LIBS} ${EXTRA_LDFLAGS})
>   target_include_directories(SDL2 PUBLIC $<INSTALL_INTERFACE:include/
> SDL2>)
>
> They themselves include directories using the old global includes instead
> of target specific includes:
>
>   include_directories(${SDL2_BINARY_DIR}/include
> ${SDL2_SOURCE_DIR}/include)
>
> There should be a target_include_directories(SDL2 PUBLIC
> <$BUILD_INTERFACE:${SDL2_SOURCE_DIR}/include), but that must be in the
> same CMakeLists that defines the library, which require changing the SDL's
> CMakeLists.
>


That's not actually true. You can call target_include_directories() on any
target, not just those created in the current scope. In fact, all of the
target_...() commands except target_link_libraries() can do this (and it
was recently agreed
<https://gitlab.kitware.com/cmake/cmake/issues/17943#note_405237> that we
should remove the restriction on target_link_libraries() too). This means
if a project like SDL fails to set INTERFACE properties for header search
paths, compiler defines, etc. you can add them yourself from outside the
project. Obviously it's better if the project itself can be updated to do
it, but in the meantime your own project can add the missing things.



>
> So, one solution could be to create an imported target to attach this path
> and l ink to it instead:
>
>   add_library(SDL2x INTERFACE IMPORTED)
>   set_target_properties(SDL2x PROPERTIES INTERFACE_INCLUDE_DIRECTORIES
> "${sdl2_SOURCE_DIR}/include")
>   set_target_properties(SDL2x PROPERTIES INTERFACE_LINK_LIBRARIES SDL2)
>
> Tested with CMake 3.11. However, to make it work, I had to add OpenGL:
>
>   find_package(OpenGL REQUIRED)
>   target_link_libraries(testExe SDL2x OpenGL::GL)
>

> Install fails, but that's another issue (the symlink is created in the
> wrong directory) and this should be reported to SDL I guess.
>
> CMake Error at _deps/sdl2-build/cmake_install.cmake:188 (file):
>   file INSTALL cannot find
>   "[...]/build/_deps/sdl2-build/libSDL2.so".
> Call Stack (most recent call first):
>   cmake_install.cmake:42 (include)
>
>
-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180505/657a1ebb/attachment.html>

From kim.walisch at gmail.com  Fri May  4 18:17:39 2018
From: kim.walisch at gmail.com (Kim Walisch)
Date: Sat, 5 May 2018 00:17:39 +0200
Subject: [CMake] Linking programs with Clang & OpenMP fails
In-Reply-To: <CAE_DJ11my+ROmE1QapU=JG=89PDEyGAKsHCetn2CpxJaCMvGzg@mail.gmail.com>
References: <CAE_DJ11my+ROmE1QapU=JG=89PDEyGAKsHCetn2CpxJaCMvGzg@mail.gmail.com>
Message-ID: <CAE_DJ10MoxW+Ye-UaUMsqX8LN3oPK4NEZ8C4Ckq21Tw-ObrBfg@mail.gmail.com>

Hi,

I have figured out what the problem is:

LLVM/Clang with OpenMP requires linking against libatomic only when
using 128-bit integers. The following program fails to compile using
Clang-6.0 on Ubuntu 18 x86_64 using:

$ clang++ -fopenmp=libomp test.cpp

#include <omp.h>

int main() {
    __int128_t sum = 0;

    #pragma omp parallel for reduction(+: sum)
    for (int i = 0; i < 100; i++)
        sum += i;

    return 0;
}

But it compiles fine when adding -latomic:
clang++ -fopenmp=libomp test.cpp -latomic

For me, this is neither a CMake bug nor an LLVM/Clang bug but it is
still very confusing as GCC does not require linking against libatomic.

Regards,
Kim

On Fri, May 4, 2018 at 7:48 PM, Kim Walisch <kim.walisch at gmail.com> wrote:

> Hi,
>
> The latest Clang-6.0 compiler finally enables OpenMP by default on
> Linux (e.g. Ubuntu-18 x86_64).
>
> But OpenMP programs using Clang-6.0/CMake-3.10 fail to compile:
>
> [100%] Linking CXX executable primecount
> libprimecount.a(P2.cpp.o): In function `.omp_outlined..7':
> P2.cpp:(.text+0x2194): undefined reference to `__atomic_load'
> P2.cpp:(.text+0x21ef): undefined reference to `__atomic_compare_exchange'
> CMakeFiles/primecount.dir/build.make:148: recipe for target 'primecount'
> failed
> make[2]: *** [primecount] Error 1
>
> The problem is that:
>
> target_link_libraries(myprogram OpenMP::OpenMP_CXX)
>
> does not add libatomic to the linker options which LLVM/Clang's OpenMP
> library depends upon. When I manually add -latomic to the linker
> options my OpenMP programs compile & link fine using Clang-6.0/CMake-3.10.
>
> Regards,
> Kim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180505/45c844dd/attachment-0001.html>

From isaiah.norton at gmail.com  Fri May  4 19:51:26 2018
From: isaiah.norton at gmail.com (Isaiah Norton)
Date: Fri, 4 May 2018 19:51:26 -0400
Subject: [CMake] Memory usage and configuration time for large project
In-Reply-To: <277602CF-2D9A-4273-A93B-33F9449BB1C0@fnal.gov>
References: <ABC8A9FA-9573-4622-938E-5C3694F49C56@fnal.gov>
 <CAAD4mYj-Bu2usBUy0VWGf8R_zF62E4zZ3YdUvS39mjC89pHsUA@mail.gmail.com>
 <277602CF-2D9A-4273-A93B-33F9449BB1C0@fnal.gov>
Message-ID: <CADFtqor_Dckfd0ApYGT6+ip4-JjRg0E6yfnyTVTp_zSjPD06+Q@mail.gmail.com>

As one ballpark datapoint: a "superbuild" of 3D Slicer (slicer.org) has a
similar object and library count:

macbook-pro:s5nj inorton$ find ./ -name *.o | wc -l
>    14127

macbook-pro:s5nj inorton$ find ./ -name *.dylib -or -name *.so | wc -l
>     2158


Based on a few quick tests, the aggregate cmake time is probably about 6-8
minutes for the ninja generator, over the multi-hour build (each dependency
is configured and built as a separate sub-project via CMake's
ExternalProject mechanism) -- with the caveat that each of those cmake runs
is doing lengthy checks that should only be done once if your project
strictly uses `add_subdirectory`.

As a more concrete point of comparison, building VTK generates 5747 object
files, and a clean configure on my 2-core macbook takes about 90s.

Isaiah



On Fri, May 4, 2018 at 2:16 PM, Patrick E Gartung <gartung at fnal.gov> wrote:

> Just to be clear, the memory and time used are just to configure and
> generate the makefiles or Ninja file. The build itself can take several
> hours.
>
> ?On 4/30/18, 4:55 PM, "R0b0t1" <r030t1 at gmail.com> wrote:
>
>     On Mon, Apr 30, 2018 at 4:44 PM, Patrick E Gartung <gartung at fnal.gov>
> wrote:
>     >  Hi,
>     >
>     > We have a large c/c++/fortran project, CMSSW, that is built with a
> custom tool, scram.
>     >
>     > https://github.com/cms-sw/cmssw
>     >
>     > The project might move to a cmake based build in the future. The
> scripts to convert to CmakeLists.tx has been written
>     >
>     > https://github.com/cms-sw/cmssw2cmake
>     >
>     > Tests show that with the cmake files generated with this script,
> configuring the project uses up to 1.5GB of ram and takes 11 minutes when
> using -GMakefiles. Using -GNinja and using the latest cmake, this time can
> be reduced to 8 minutes.
>     >
>     > The project builds 14k object files, 2.2k libraries, ~600 binaries,
> 500 generated source files with links to ~100 external libraries.
>     >
>     > Is this amount of memory usage and time typical for a project of
> this size?
>     >
>
>     I'm inclined to say "yes" as many builds such as Firefox, its
>     supporting libraries, and Chrome all take lots of time and memory.
>     Chrome uses Ninja, I might add. But the issue is not CMake itself.
>     CMake tends to produce better builds.
>
>     As I am not intimately familiar with your project, I can't make good
>     concrete suggestions. You may enjoy reading
>     https://news.ycombinator.com/item?id=14733829 and searching for build
>     optimization strategies.
>
>     Keep in mind a lot of the blame falls on C++ and Windows, should you
>     be using Windows. If you aren't using Windows, then the advice in the
>     comments above should still be relevant, and give you something to go
>     on.
>
>     Cheers,
>          R0b0t1
>
>     > Patrick Gartung
>     > Fermilab
>     >
>
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180504/cb1f820a/attachment.html>

From kristianonline28 at gmail.com  Sat May  5 10:02:49 2018
From: kristianonline28 at gmail.com (Kristian)
Date: Sat, 5 May 2018 16:02:49 +0200
Subject: [CMake] PreprocessToFile
Message-ID: <CAO5HUhPWN8cs=1F1-pYYN3SfKFiU9TddcZDucyT_-9NfxYK=FA@mail.gmail.com>

Hi,

I have a Visual Studio 2015 Solution with some C++ projects in it. I
try to generate the same solution and the projects with CMake. Now,
there is a part, where I do not know how to solve this.

In a vcxproj file, there is something like this written:

=====
<ClCompile Include="abc.cpp">

  <PreprocessToFile Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
    false
  </PreprocessToFile>

  <PreprocessKeepComments
Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
    false
  <PreprocessKeepComments>
</ClCompile>
=====

So, now my question: Is it possible, to get the same result with CMake here?

From d3ck0r at gmail.com  Sat May  5 10:31:32 2018
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 5 May 2018 07:31:32 -0700
Subject: [CMake] PreprocessToFile
In-Reply-To: <CAO5HUhPWN8cs=1F1-pYYN3SfKFiU9TddcZDucyT_-9NfxYK=FA@mail.gmail.com>
References: <CAO5HUhPWN8cs=1F1-pYYN3SfKFiU9TddcZDucyT_-9NfxYK=FA@mail.gmail.com>
Message-ID: <CAA2GJqX0rq5bkSfQb4xpEEtjihYCPsdpbQNv7omZTQfxhqQofg@mail.gmail.com>

On Sat, May 5, 2018 at 7:02 AM, Kristian <kristianonline28 at gmail.com> wrote:

> Hi,
>
> I have a Visual Studio 2015 Solution with some C++ projects in it. I
> try to generate the same solution and the projects with CMake. Now,
> there is a part, where I do not know how to solve this.
>
> In a vcxproj file, there is something like this written:
>
> =====
> <ClCompile Include="abc.cpp">
>
>   <PreprocessToFile Condition="'$(Configuration)|$
> (Platform)'=='Release|x64'">
>     false
>   </PreprocessToFile>
>
>   <PreprocessKeepComments
> Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
>     false
>   <PreprocessKeepComments>
> </ClCompile>
> =====
>
> So, now my question: Is it possible, to get the same result with CMake
> here?
> --
>

Yes; and you don't need to do anything; cmake doesn't preprocess to a file
by default (or by any option I know of).
So what you have indicated... 'false' 'false' is what cmake generates.


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180505/634003f2/attachment.html>

From kristianonline28 at gmail.com  Sat May  5 12:57:45 2018
From: kristianonline28 at gmail.com (KK)
Date: Sat, 5 May 2018 18:57:45 +0200
Subject: [CMake] PreprocessToFile
In-Reply-To: <CAA2GJqX0rq5bkSfQb4xpEEtjihYCPsdpbQNv7omZTQfxhqQofg@mail.gmail.com>
References: <CAO5HUhPWN8cs=1F1-pYYN3SfKFiU9TddcZDucyT_-9NfxYK=FA@mail.gmail.com>
 <CAA2GJqX0rq5bkSfQb4xpEEtjihYCPsdpbQNv7omZTQfxhqQofg@mail.gmail.com>
Message-ID: <a0d9c2d2-a03a-0616-8e6f-bfe0d747f9b8@gmail.com>

Oh, maybe you misunderstood me. I know, that CMake does no 
preprocessing. This is done by the preprocessor.

But, what I want, is that the generated solution/VS-project with CMake 
gives me the result like in the part I've pasted below. This should be 
part of the generated files. And my question is, is it possible to 
generate this and if, how?

=====
<ClCompile Include="abc.cpp">

<PreprocessToFile Condition="'$(Configuration)|(Platform)'=='Release|x64'">

false

</PreprocessToFile>

<PreprocessKeepComments 
Condition="'$(Configuration)|$(Platform)'=='Release|x64'">

false

<PreprocessKeepComments>

</ClCompile>

=====


Am 05.05.2018 um 16:31 schrieb J Decker:
>
>
> On Sat, May 5, 2018 at 7:02 AM, Kristian <kristianonline28 at gmail.com 
> <mailto:kristianonline28 at gmail.com>> wrote:
>
>     Hi,
>
>     I have a Visual Studio 2015 Solution with some C++ projects in it. I
>     try to generate the same solution and the projects with CMake. Now,
>     there is a part, where I do not know how to solve this.
>
>     In a vcxproj file, there is something like this written:
>
>     =====
>     <ClCompile Include="abc.cpp">
>
>     ? <PreprocessToFile
>     Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
>     ? ? false
>     ? </PreprocessToFile>
>
>     ? <PreprocessKeepComments
>     Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
>     ? ? false
>     ? <PreprocessKeepComments>
>     </ClCompile>
>     =====
>
>     So, now my question: Is it possible, to get the same result with
>     CMake here?
>     -- 
>
>
> Yes; and you don't need to do anything; cmake doesn't preprocess to a 
> file by default (or by any option I know of).
> So what you have indicated... 'false' 'false' is what cmake generates.
>
>
>     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
>     <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
>     <http://cmake.org/cmake/help/support.html>
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     <http://cmake.org/cmake/help/consulting.html>
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>     <http://cmake.org/cmake/help/training.html>
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>     <http://www.kitware.com/opensource/opensource.html>
>
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
>     <https://cmake.org/mailman/listinfo/cmake>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180505/fe04aa80/attachment.html>

From d3ck0r at gmail.com  Sat May  5 13:05:40 2018
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 5 May 2018 10:05:40 -0700
Subject: [CMake] PreprocessToFile
In-Reply-To: <a0d9c2d2-a03a-0616-8e6f-bfe0d747f9b8@gmail.com>
References: <CAO5HUhPWN8cs=1F1-pYYN3SfKFiU9TddcZDucyT_-9NfxYK=FA@mail.gmail.com>
 <CAA2GJqX0rq5bkSfQb4xpEEtjihYCPsdpbQNv7omZTQfxhqQofg@mail.gmail.com>
 <a0d9c2d2-a03a-0616-8e6f-bfe0d747f9b8@gmail.com>
Message-ID: <CAA2GJqXuuMWtRQruxdwVh0ELvLMGjBczQ9arpOB+VjfqP3u7_Q@mail.gmail.com>

On Sat, May 5, 2018 at 9:57 AM, KK <kristianonline28 at gmail.com> wrote:

> Oh, maybe you misunderstood me. I know, that CMake does no preprocessing.
> This is done by the preprocessor.
>
Right; that's not what I was saying; it doesn't generte projects with
preprocesssing enabled, so the options ARE false already in the generated
projects.

> But, what I want, is that the generated solution/VS-project with CMake
> gives me the result like in the part I've pasted below. This should be part
> of the generated files. And my question is, is it possible to generate this
> and if, how?
>
It does.
Oh I see, it doesn't actually write that out; but the default IS false...
so it shouldn't have to.
I did some testing, and setting a project to preprocess to a file,
it(visual studio)   writes <PreprocessToFile>true</PreprocessToFile>
If I reset that back to default/inhert from project; it deletes that entry
entirely from the project.
So; unless you want it ENABLED correct behavior should be to not write it
(which, like I said, cmake already does (or rather doesn't do))



> =====
> <ClCompile Include="abc.cpp">
>
> <PreprocessToFile Condition="'$(Configuration)|(
> Platform)'=='Release|x64'">
>
> false
>
> </PreprocessToFile>
>
> <PreprocessKeepComments Condition="'$(Configuration)|$
> (Platform)'=='Release|x64'">
>
> false
>
> <PreprocessKeepComments>
>
> </ClCompile>
>
> =====
>
> Am 05.05.2018 um 16:31 schrieb J Decker:
>
>
>
> On Sat, May 5, 2018 at 7:02 AM, Kristian <kristianonline28 at gmail.com>
> wrote:
>
>> Hi,
>>
>> I have a Visual Studio 2015 Solution with some C++ projects in it. I
>> try to generate the same solution and the projects with CMake. Now,
>> there is a part, where I do not know how to solve this.
>>
>> In a vcxproj file, there is something like this written:
>>
>> =====
>> <ClCompile Include="abc.cpp">
>>
>>   <PreprocessToFile Condition="'$(Configuration)|$
>> (Platform)'=='Release|x64'">
>>     false
>>   </PreprocessToFile>
>>
>>   <PreprocessKeepComments
>> Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
>>     false
>>   <PreprocessKeepComments>
>> </ClCompile>
>> =====
>>
>> So, now my question: Is it possible, to get the same result with CMake
>> here?
>> --
>>
>
> Yes; and you don't need to do anything; cmake doesn't preprocess to a file
> by default (or by any option I know of).
> So what you have indicated... 'false' 'false' is what cmake generates.
>
>
>>
>> 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
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180505/69237312/attachment.html>

From bozmoz at gmail.com  Sat May  5 14:21:47 2018
From: bozmoz at gmail.com (Christofer Jennings)
Date: Sat, 5 May 2018 11:21:47 -0700
Subject: [CMake] include restbed in my project
Message-ID: <CADkJUyEVDMT3sTPpsxfbnmGA5BvOM+Ji-8wtN+8aju0eT5oqmA@mail.gmail.com>

Hi All,

How do you use a 3rd party dependency like restbed in a cmake build?

Total nube here. First dive into CMake and haven't done C++ for a long long
time. So forgive my ignorance :) This could just as easily be an "I forgot
C++" as an "I don't know CMake"...

I'm trying to use restbed. I've got it to compile and self test with
`cmake, `make install`, and `make test` as directed on the site:
https://github.com/Corvusoft/restbed#build
It makes a `distribution` folder with `include` and `library` sub-folders.
The `library` has .a and .so or .dylib files. The `include` folder just has
headers, and a `restbed` file with #includes in it.

I'm using the example on the same page as starting point:
https://github.com/Corvusoft/restbed#example

... I could list out my failed attempts but I don't think it'd help.
Basically find_package doesn't find it, and other things I've tried don't
work. I'm digging around online but so far nothing seems to fit--which
makes me think it's something really really simple that I just don't
understand.

Thanks!
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180505/a85a38f5/attachment-0001.html>

From d3ck0r at gmail.com  Sat May  5 15:09:02 2018
From: d3ck0r at gmail.com (J Decker)
Date: Sat, 5 May 2018 12:09:02 -0700
Subject: [CMake] include restbed in my project
In-Reply-To: <CADkJUyEVDMT3sTPpsxfbnmGA5BvOM+Ji-8wtN+8aju0eT5oqmA@mail.gmail.com>
References: <CADkJUyEVDMT3sTPpsxfbnmGA5BvOM+Ji-8wtN+8aju0eT5oqmA@mail.gmail.com>
Message-ID: <CAA2GJqWGfAdtuyguWsT0pJxZkVZ5KH8RrO20ffjy_ogAgboH1w@mail.gmail.com>

for such things I often include the sources in my tree and just
'add_subdirectory( "extra/restbed" )'
it's cleaner to do a external project rule...
which can download/checkout sources and then build those and the output is
findable by other projects just by referencing the targets.
https://cmake.org/cmake/help/latest/module/ExternalProject.html

On Sat, May 5, 2018 at 11:21 AM, Christofer Jennings <bozmoz at gmail.com>
wrote:

> Hi All,
>
> How do you use a 3rd party dependency like restbed in a cmake build?
>
> Total nube here. First dive into CMake and haven't done C++ for a long
> long time. So forgive my ignorance :) This could just as easily be an "I
> forgot C++" as an "I don't know CMake"...
>
> I'm trying to use restbed. I've got it to compile and self test with
> `cmake, `make install`, and `make test` as directed on the site:
> https://github.com/Corvusoft/restbed#build
> It makes a `distribution` folder with `include` and `library` sub-folders.
> The `library` has .a and .so or .dylib files. The `include` folder just has
> headers, and a `restbed` file with #includes in it.
>
> I'm using the example on the same page as starting point:
> https://github.com/Corvusoft/restbed#example
>
> ... I could list out my failed attempts but I don't think it'd help.
> Basically find_package doesn't find it, and other things I've tried don't
> work. I'm digging around online but so far nothing seems to fit--which
> makes me think it's something really really simple that I just don't
> understand.
>
> Thanks!
> -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:
> https://cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180505/cd8d37f1/attachment.html>

From andrew.e.brownsword at gmail.com  Sun May  6 11:00:14 2018
From: andrew.e.brownsword at gmail.com (Andrew Brownsword)
Date: Sun, 6 May 2018 08:00:14 -0700
Subject: [CMake] -std=c++17 vs -std=c++1y
Message-ID: <3F24E24D-6647-4D18-AF86-60AA1D72BDAD@gmail.com>

Hi,

Is there a way to get cmake 3.11 to emit 17 vs 1y when setting CMAKE_CXX_STANDARD?  I?m finding that it seems to be a common practice to use the value of the preprocessor define __cplusplus (which is a date), and the value differs depending on whether 17 or 1y is used (at least with CLang).  I haven?t figured out how to get cmake to emit -std=c++17, it always seems to use 1y, which is causing problems with code that assumes the __cplusplus date reflects the c++17 standardization date.

Thanks,
   Andrew


From eike at sf-mail.de  Sun May  6 11:12:34 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Sun, 06 May 2018 17:12:34 +0200
Subject: [CMake] -std=c++17 vs -std=c++1y
In-Reply-To: <3F24E24D-6647-4D18-AF86-60AA1D72BDAD@gmail.com>
References: <3F24E24D-6647-4D18-AF86-60AA1D72BDAD@gmail.com>
Message-ID: <2676412.Zk6p3WfLyx@daneel.sf-tec.de>

Am Sonntag, 6. Mai 2018, 08:00:14 schrieb Andrew Brownsword:
> Hi,
> 
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
> CMAKE_CXX_STANDARD?  I?m finding that it seems to be a common practice to
> use the value of the preprocessor define __cplusplus (which is a date), and
> the value differs depending on whether 17 or 1y is used (at least with
> CLang).  I haven?t figured out how to get cmake to emit -std=c++17, it
> always seems to use 1y, which is causing problems with code that assumes
> the __cplusplus date reflects the c++17 standardization date.

My bet is: that code is wrong. For every compiler I have seen the rules have 
been:

-std=c++AA is used as long as the standard is not fixed

-afterwards std=c++YY is introduced, and -std=c++AA is an alias for that

So it does not matter which flag you use when the compiler supports both, but 
you can't of course properly test on the value of __cplusplus in older 
compilers because you don't know in which year/month the standard will be 
released.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake/attachments/20180506/c11fa9ca/attachment.sig>

From jeanmichael.celerier at gmail.com  Sun May  6 12:05:32 2018
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Sun, 6 May 2018 18:05:32 +0200
Subject: [CMake] -std=c++17 vs -std=c++1y
In-Reply-To: <3F24E24D-6647-4D18-AF86-60AA1D72BDAD@gmail.com>
References: <3F24E24D-6647-4D18-AF86-60AA1D72BDAD@gmail.com>
Message-ID: <CAE1uMrUCJH3mJFAj+TzwZwbCYMRWD_Hc99g52sETK=iNLvduFA@mail.gmail.com>

Note that c++17 is c++1z. c++1y was C++14.



-------
Jean-Micha?l Celerier
http://www.jcelerier.name

On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <
andrew.e.brownsword at gmail.com> wrote:

> Hi,
>
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
> CMAKE_CXX_STANDARD?  I?m finding that it seems to be a common practice to
> use the value of the preprocessor define __cplusplus (which is a date), and
> the value differs depending on whether 17 or 1y is used (at least with
> CLang).  I haven?t figured out how to get cmake to emit -std=c++17, it
> always seems to use 1y, which is causing problems with code that assumes
> the __cplusplus date reflects the c++17 standardization date.
>
> Thanks,
>    Andrew
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180506/624a355e/attachment.html>

From andrew.e.brownsword at gmail.com  Sun May  6 13:34:49 2018
From: andrew.e.brownsword at gmail.com (Andrew Brownsword)
Date: Sun, 6 May 2018 10:34:49 -0700
Subject: [CMake] -std=c++17 vs -std=c++1y
In-Reply-To: <CAE1uMrUCJH3mJFAj+TzwZwbCYMRWD_Hc99g52sETK=iNLvduFA@mail.gmail.com>
References: <3F24E24D-6647-4D18-AF86-60AA1D72BDAD@gmail.com>
 <CAE1uMrUCJH3mJFAj+TzwZwbCYMRWD_Hc99g52sETK=iNLvduFA@mail.gmail.com>
Message-ID: <F36DF6E1-3477-4418-B0FF-028859A405C6@gmail.com>

Well, I am specifying:

set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_EXTENSIONS ON)

and the compiler line contains ?-std=gnu++1y?.  I?m using a very recent source build of CLang and libc++.  Any idea why cmake would fall back to 1y in this case?





> On May 6, 2018, at 9:05 AM, Jean-Micha?l Celerier <jeanmichael.celerier at gmail.com> wrote:
> 
> Note that c++17 is c++1z. c++1y was C++14.
> 
> 
> 
> -------
> Jean-Micha?l Celerier
> http://www.jcelerier.name <http://www.jcelerier.name/>
> On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <andrew.e.brownsword at gmail.com <mailto:andrew.e.brownsword at gmail.com>> wrote:
> Hi,
> 
> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting CMAKE_CXX_STANDARD?  I?m finding that it seems to be a common practice to use the value of the preprocessor define __cplusplus (which is a date), and the value differs depending on whether 17 or 1y is used (at least with CLang).  I haven?t figured out how to get cmake to emit -std=c++17, it always seems to use 1y, which is causing problems with code that assumes the __cplusplus date reflects the c++17 standardization date.
> 
> Thanks,
>    Andrew
> 
> -- 
> 
> 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 <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 <http://cmake.org/cmake/help/support.html>
> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake <https://cmake.org/mailman/listinfo/cmake>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180506/beea516d/attachment.html>

From dblaikie at gmail.com  Sun May  6 19:49:51 2018
From: dblaikie at gmail.com (David Blaikie)
Date: Sun, 06 May 2018 23:49:51 +0000
Subject: [CMake] Experiments in CMake support for Clang (header &
 standard) modules
In-Reply-To: <2a2abd48-dee2-dc1a-b5e6-33e89d9b1472@gmail.com>
References: <CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com>
 <2a2abd48-dee2-dc1a-b5e6-33e89d9b1472@gmail.com>
Message-ID: <CAENS6Et0JNc0Mm3_AB6Zg5O07FVXNJRznSQhVEZXaOjKOQAiAA@mail.gmail.com>

On Mon, Apr 30, 2018 at 3:30 PM Stephen Kelly <steveire at gmail.com> wrote:

> On 04/20/2018 01:39 AM, David Blaikie wrote:
>
> Hi there,
>
> I'm experimenting with creating examples (& potential changes to CMake
> itself, if needed/useful) of building clang modules (currently using the
> semi-backwards compatible "header modules", with the intent of also/moving
> towards supporting pre-standard C++ modules in development in Clang).
>
>
> Great! Thanks for reaching out. Sorry it has taken me a while to respond.
>

No worries - thanks for getting back to me!


> Have you had other response off-list?
>

Nah - chatted a little with coworkers (fellow Clang/LLVM developers -
mostly Richard Smith & Chandler Carruth) off-list, but nothing much more.

> The basic commands required are:
>
>   clang++ -fmodules -xc++ -Xclang -emit-module -Xclang -fmodules-codegen
> -fmodule-name=foo foo.modulemap -o foo.pcm
>   clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp
>   clang++ -c foo.pcm
>   clang++ foo.o use.o -o a.out
>
>
> Ok. Fundamentally, I am suspicious of having to have a
> -fmodule-file=foo.pcm for every 'import foo' in each cpp file. I shouldn't
> have to manually add that each time I add a new import to my cpp file. Even
> if it can be automated (eg by CMake), I shouldn't have to have my
> buildsystem be regenerated each time I add an import to my cpp file either.
>
> That's something I mentioned in the google groups post I made which you
> linked to. How will that work when using Qt or any other library?
>

- My understanding/feeling is that this would be similar to how a user has
to change their link command when they pick up a new dependency.

Nope, scratch that ^ I had thought that was the case, but talking more with
Richard Smith it seems there's an expectation that modules will be
somewhere between header and library granularity (obviously some small
libraries today have one or only a few headers, some (like Qt) have many -
maybe those on the Qt end might have slightly fewer modules than the have
headers - but still several modules to one library most likely, by the
sounds of it)


Now, admittedly, external dependencies are a little more complicated than
internal (within a single project consisting of multiple libraries) - which
is why I'd like to focus a bit on the simpler internal case first.


> Today, a beginner can find a random C++ book, type in a code example from
> chapter one and put `g++ -I/opt/book_examples prog1.cpp` into a terminal
> and get something compiling and running. With modules, they'll potentially
> have to pass a whole list of module files too.
>

Yeah, there's some talk of supporting a mode that doesn't explicitly
build/use modules in the filesystem, but only in memory for the purpose of
preserving the isolation semantics of modules. This would be used in simple
direct-compilation cases like this. Such a library might need a
configuration file or similar the compiler can parse to discover the
parameters (warning flags, define flags, whatever else) needed to build the
BMI.


> Lots of people manually maintain Makefile-based buildsystems today, and
> most other companies I've been inside of have their own custom tool or
> bunch of python scripts, or both. Manually changing such buildsystems to
> add -fmodule-file or -fmodule-map-file each time an import is added is a
> significant barrier.
>
> Will my project have to compile the modules files for all of my
> dependencies?
>

Yes - and that's where the external dependencies get complicated.


> Even more complication for my buildsystem. Do I have to wait for my
> dependencies to modularize bottom-up before I can benefit from modules?
>

There are some ideas about how to handle that ('legacy headers'/modules in
Richard's work/proposed amendment to the TS), but I'm trying to focus on a
few of the simpler cases first.


> If my dependency does add 'module foo' to their header files, or whatever
> the current syntax is, can I continue to #include <foo> or is that a source
> incompatible change?
>

I believe it'd be a source incompatible change. You could continue to
provide a header for your module separately. They'd likely have different
extensions anyway.


> I raised some of these issues a few years ago regarding the clang
> implementation with files named exactly module.modulemap:
>
>
> http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html
>
>
> http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html
>
> Interestingly, GCC is taking a directory-centric approach in the driver
> (-fmodule-path=<dir>) as opposed to the 'add a file to your compile line
> for each import' that Clang and MSVC are taking:
>
>  http://gcc.gnu.org/wiki/cxx-modules
>
> Why is Clang not doing a directory-centric driver-interface? It seems to
> obviously solve problems. I wonder if modules can be a success without
> coordination between major compiler and buildsystem developers. That's why
> I made the git repo - to help work on something more concrete to see how
> things scale.
>

'We' (myself & other Clang developers) are/will be talking to GCC folks to
try to get consistency here, in one direction or another (maybe some 3rd
direction different from Clang or LLVM's). As you noted in a follow-up,
there is a directory-based flag in Clang now, added by Boris as he's been
working through adding modules support to Build2.


> Having just read all of my old posts again, I still worry things like this
> will hinder modules 'too much' to be successful. The more (small) barriers
> exist, the less chance of success. If modules aren't successful, then
> they'll become a poisoned chalice and no one will be able to work on fixing
> them. That's actually exactly what I expect to happen, but I also still
> hope I'm just missing something :). I really want to see a committee
> document from the people working on modules which actually explores the
> problems and barriers to adoption and concludes with 'none of those things
> matter'. I think it's fixable, but I haven't seen anyone interested enough
> to fix the problems (or even to find out what they are).
>

Indeed - hence my desire to talk through these things, get some practical
experience, document them to the committee in perhaps a less-ranty, more
concrete form along with pros/cons/unknowns/etc to hopefully find some
consistency, maybe write up a document of "this is how we expect build
systems to integrate with this C++ feature", etc.


>
> Anyway, you are not here for my rants.
>
>
> My current very simplistic prototype, to build a module file, its
> respective module object file, and include those in the library/link for
> anything that depends on this library:
>
>   add_custom_command(
>           COMMAND ${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -xc++ -c
> -Xclang -emit-module -fmodules -fmodule-name=Hello
> ${CMAKE_CURRENT_SOURCE_DIR}/module.modulemap -o
> ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm -Xclang -fmodules-codegen
>           DEPENDS module.modulemap hello.h
>
>
> Why does this command depend on hello.h?
>

Because it builds the binary module interface (hello_module.pcm) that is a
serialized form of the compiler's internal representation of the contents
of module.modulemap which refers to hello.h (the modulemap lists the header
files that are part of the module). This is all using Clang's current
backwards semi-compatible "header modules" stuff. In a "real" modules
system, ideally there wouldn't be any modulemap. Just a .cppm file, and any
files it depends on (discovered through the build system scanning the
module imports, or a compiler-driven .d file style thing).

Perhaps it'd be better for me to demonstrate something closer to the actual
modules reality, rather than this retro header modules stuff that clang
supports.


> If that is changed and module.modulemap is not, what will happen?
>

If hello.h is changed and module.modulemap is not changed? The
hello_module.pcm does need to be rebuilt.

Ideally all of this would be implicit (maybe with some flag/configuration,
or detected based on new file extensions for C++ interface definitions) in
the add_library - taking, let's imagine, the .ccm (let's say, for
argument's sake*) file listed in the add_library's inputs and using it to
build a .pcm (BMI), building that .pcm as an object file along with all the
normal .cc files,


* alternatively, maybe they'll all just be .cc files & a build system would
be scanning the .cc files to figure out dependencies & could notice that
one of them is the blessed module interface definition based on the first
line in the file.


>
>
>           OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm
>           COMMENT "Generating hello_module.pcm"
>   )
>   add_library (Hello hello.cxx
> ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm)
>   target_include_directories(Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
>   target_compile_options(Hello PUBLIC -fmodules -Xclang
> -fmodule-file=${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm)
>
> (this is based on the example in the CMake docs using Hello/Demo)
>
>
> Good that you got something working.
>
>
> This also required one modification to CMake itself to classify a pcm file
> as a C++ file that needs to be compiled (to execute the 3rd line in the
> basic command list shown above).
>
>
> An alternative to patching CMake might be
>
>  set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm
> PROPERTIES LANGUAGE CXX)
>
> though hopefully that is also temporary.
>

Ah, thanks! I'll give that a go.

So I suppose the more advanced question: Is there a way I can extend
handling of existing CXX files (and/or define a new kind of file, say,
CXXM?) specified in a cc_library. If I want to potentially check if a .cc
file is a module, discover its module dependencies, add new rules about how
to build those, etc. Is that do-able within my cmake project, or would that
require changes to cmake itself? (I'm happy to poke around at what those
changes might look like)


>
>
> But this isn't ideal - I don't /think/ I've got the dependencies quite
> right & things might not be rebuilding at the right times.
> Also it involves hardcoding a bunch of things like the pcm file names,
> header files, etc.
>
>
> Indeed. I think part of that comes from the way modules have been
> designed. The TS has similar issues.
>

Sure - but I'd still be curious to understand how I might go about
modifying the build system to handle this. If there are obvious things I
have gotten wrong about the dependencies, etc, that would cause this not to
rebuild on modifications to any of the source/header files - I'd love any
tips you've got.

& if there are good paths forward for ways to prototype changes to the
build system to handle, say, specifying a switch/setting a property/turning
on a feature that I could implement that would collect all the .ccm files
in an add_library rule and use them to make a .pcm file - I'd be happy to
try prototyping that.

> Ideally, at least for a simplistic build, I wouldn't mind generating a
> modulemap from all the .h files (& have those headers listed in the
> add_library command - perhaps splitting public and private headers in some
> way, only including the public headers in the module file, likely).
> Eventually for the standards-proposal version, it's expected that there
> won't be any modulemap file, but maybe all headers are included in the
> module compilation (just pass the headers directly to the compiler).
>
>
> In a design based on passing directories instead of files, would those
> directories be redundant with the include directories?
>

I'm not sure I understand the question, but if I do, I think the answer
would be: no, they wouldn't be redundant. The system will not have
precompiled modules available to use - because binary module definitions
are compiler (& compiler version, and to some degree, compiler flags (eg:
are you building this for x86 32 bit or 64 bit?)) dependent.


> One of the problems modules adoption will hit is that all the compilers
> are designing fundamentally different command line interfaces for them.
>

*nod* We'll be working amongst GCC and Clang at least to try to converge on
something common.


> Buildsystems will have to be rewritten to take advantage of modules, and
> they will be annoying to use and adopt.
>

I'm hoping to minimize any rewriting - but also potentially provide recipes
for CMake (& other users) as well as patches to CMake itself to help
facilitate this.

> This also doesn't start to approach the issue of how to build modules for
> external libraries - which I'm happy to discuss/prototype too, though
> interested in working to streamline the inter-library but intra-project
> (not inter-project) case first.
>
>
> Yes, there are many aspects to consider.
>
> Are you interested in design of a CMake abstraction for this stuff? I have
> thoughts on that, but I don't know if your level of interest stretches that
> far.
>

Not sure how much work it'd be - at the moment my immediate interest is to
show as much real-world/can-actually-run prototype with cmake as possible,
either with or without changes to cmake itself (or a combination of minimal
cmake changes plus project-specific recipes of how to write a user's cmake
files to work with this stuff) or also showing non-working/hypothetical
prototypes of what ideal user cmake files would look like with
reasonable/viable (but not yet implemented) cmake support.

> Stephen - I saw you were asking some questions about this here (
> https://groups.google.com/a/isocpp.org/forum/#!topic/modules/sDIYoU8Uljw &
> https://github.com/steveire/ModulesExperiments - didn't really understand
> how this example applied/worked, though - I guess maybe it's a prototype
> syntax proposal?)
>
>
> It is a set of pre-modules libraries, some of which depend on one another
> and with some transitive dependencies in the headers.
>
> I made it to be 'a few steps above trivial' in the hope that someone would
> show me how to port it to modules-ts (even if the result does not build).
> So far, no one has.
>

Ah, OK.


> Can you help? It would really help my understanding of where things
> currently stand with modules.
>

I can certainly have a go, for sure.


> For example, is there only one way to port the contents of the cpp files?
>

Much like header grouping - how granular headers are (how many headers you
have for a given library) is up to the developer to some degree (certain
things can't be split up), similarly with modules - given a set of C++
definitions, it's not 100% constrained how those definitions are exposed as
modules - the developer has some freedom over how the declarations of those
entities are grouped into modules.


> After that, is there one importable module per class or one per shared
> library (which I think would make more sense for Qt)?
>

Apparently (this was a surprise to me - since I'd been thinking about this
based on the Clang header modules (backwards compatibility stuff, not the
standardized/new language feature modules)) the thinking is probably
somewhere between one-per-class and one-per-shared-library. But for me, in
terms of how a build file would interact with this, more than
one-per-shared-library is probably the critical tipping point. If it was
just one per shared library, then I'd feel like the dependency/flag
management would be relatively simple. You have to add a flag to the linker
commandline to link in a library, so you have to add a flag to the compile
step to reference a module, great. But, no, bit more complicated than that
given the finer granularity that's expected here.


> And is transitive dependency expressed in the header files after porting?
> I think that last one is dealt with by the 'export import' syntax
>

If you mean one module exposing things from modules it depends on - yes,
you can export import. (but by default your imports are just accessible to
the implementation of the module)


> The git repo is an attempt to make the discussion concrete because it
> would show how multiple classes and multiple libraries with dependencies
> could interact in a modules world. I'm interested in what it would look
> like ported to modules-ts, because as far as I know, clang-modules and
> module maps would not need porting of the cpp files at all.
>

Right, clang header-modules is a backwards compatibility feature. It does
require a constrained subset of C++ to be used to be effective (ie:
basically your headers need to be what we think of as ideal/canonical
headers - reincludable, independent, complete, etc). So if you've got
good/isolated headers, you can port them to Clang's header modules by
adding the module maps & potentially not doing anything else - though, if
you rely on not changing your build system, then that presents some
problems if you want to scale (more cores) or distribute your build.
Because the build system doesn't know about these  dependencies - so if you
have, say, two .cc files that both include foo.h then bar.h - well, the
build system runs two compiles, both compiles try to implicitly build the
foo.h module - one blocks waiting for the other to complete, then they
continue and block again waiting for bar.h module to be built. If the build
system knew about these dependencies (what Google uses - what we call
"explicit (header)modules") then it could build the foo.h module and the
bar.h module in parallel, then build the two .cc files in parallel.


>
>
> Basically: What do folks think about supporting these sort of features in
> CMake C++ Builds? Any pointers on how I might best implement this with or
> without changes to CMake?
>
>
> I think some design is needed up front. I expect CMake would want to have
> a first-class (on equal footing with include directories or compile
> definitions and with particular handling) concept for modules, extending
> the install(TARGET) command to install module binary files etc.
>

Module binary files wouldn't be installed in the sense of being part of the
shipped package of a library - because module binary files are
compiler/flag/etc specific.


> To do that kind of design, I at least would need to be able to experiment
> or conceptualize examples which are not totally trivial, such as the
> starting point in my repo.
>
> On the CMake side, I think something like this should be the target (note
> that no compiler command line interface works like this today, which I
> think is a barrier to adoption):
>
>  add_library(foo foo.cpp)
>
>  # Target property to enable modules for the target
>  set_property(TARGET foo PROPERTY USE_CXX_MODULES ON)
>
>  # Note: Use target_include_directories to specify module search
>  # paths (how GCC and MSVC work)
>  # Also note: compilers should use the -I paths as a module path search
> list so
>  # that CMake does not have to pass the same list as both -I and as
> -fmodule-path=
>  # or similar entries.
>  # Also note: This is source compatible with the cmake code that already
> exists!
>  # The existance of /opt/bar/bing.<ext> makes 'import bing;' work.
>  target_include_directories(foo PRIVATE /opt/bar)
>
>  # Possibly need a new command to specify headers (there is
>  # other motivation for this in CMake, so use a generic name without
> 'modules' in it)
>  # Because foo has USE_CXX_MODULES ON, foo.h is processed as a module
>  # and a binary representation is created for import. Other properties can
>  # be set on foo.h with set_source_files_properties() to pass other
> command line
>  # options when generating the module.
>  target_headers(foo PRIVATE foo.h)
>
> Also - in the right design, CMake does not have to regenerate
> -fmodule-file or whatever into the compile line any time the user adds
> 'import something;', which is the case with clang now afaik. Please correct
> me if that is not correct.
>
> I know some people at Kitware have been thinking about modules though, so
> I'd be interested in any other insights from there. Brad, can you comment?
>
> Here's some other reading material for anyone else following along:
>
> https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html
> https://build2.org/article/cxx-modules-misconceptions.xhtml
>

Thanks for the links & questions/ideas!

- Dave


>
>
>
> Thanks,
>
> Stephen.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180506/c6f4832c/attachment-0001.html>

From mailinglists at xgm.de  Mon May  7 05:28:18 2018
From: mailinglists at xgm.de (Florian Lindner)
Date: Mon, 7 May 2018 11:28:18 +0200
Subject: [CMake] CMake does not find module, though it's in MODULE_PATH
Message-ID: <2be05656-4df8-24c0-b5dc-311080c6063f@xgm.de>

Hello,

my CMake 3.6.2 complains about not finding FindEigen3.cmake

CMake Error at CMakeLists.txt:62 (find_package):
  By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Eigen3", but
  CMake did not find one.

  Could not find a package configuration file provided by "Eigen3" with any
  of the following names:

    Eigen3Config.cmake
    eigen3-config.cmake

  Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
  "Eigen3_DIR" to a directory containing one of the above files.  If "Eigen3"
  provides a separate development package or SDK, be sure it has been
  installed.

However, it's clearly there in ls $CMAKE_MODULE_PATH/FindEigen3.cmake

I try to use it like find_package(Eigen3 REQUIRED)

What else could be wrong there?

Thanks!

Florian

From Andreas-Naumann at gmx.net  Mon May  7 09:45:00 2018
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Mon, 7 May 2018 15:45:00 +0200
Subject: [CMake] CMake does not find module, though it's in MODULE_PATH
In-Reply-To: <2be05656-4df8-24c0-b5dc-311080c6063f@xgm.de>
References: <2be05656-4df8-24c0-b5dc-311080c6063f@xgm.de>
Message-ID: <trinity-3ce61037-a8ca-4bcc-aa8b-f9807cc4ce9e-1525700700556@3c-app-gmx-bs27>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180507/7dee5bde/attachment.html>

From mailinglists at xgm.de  Tue May  8 08:51:39 2018
From: mailinglists at xgm.de (Florian Lindner)
Date: Tue, 8 May 2018 14:51:39 +0200
Subject: [CMake] cmake finds libxml2 but still says its missing
Message-ID: <c63d8d2e-2c03-f067-effb-cf22ff73e29a@xgm.de>

Hello,

I try to compile my software like

cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -DBUILD_SHARED_LIBS=off ../..

> cat ../../toolchain.cmake
SET(CMAKE_SYSTEM_NAME Hazelhen)
SET(CMAKE_C_COMPILER       cc)
SET(CMAKE_CXX_COMPILER     CC)
SET(CMAKE_Fortran_COMPILER ftn)

which gives me the error:

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES) (found version "2.9.4")
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindLibXml2.cmake:69 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:73 (find_package)


I am a bit puzzled, because it says it found libxml 2.9.4, but then again does not set the $LIBXML2_LIBRARIES.

Usage is

find_package(LibXml2 REQlesUIRED)
include_directories(${LIBXML2_INCLUDE_DIR})

and later

target_link_libraries(foobar PUBLIC ${LIBXML2_LIBRARIES})

cmake version 3.5.2

Thanks!
Florian

From eike at sf-mail.de  Tue May  8 09:12:45 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Tue, 08 May 2018 15:12:45 +0200
Subject: [CMake] cmake finds libxml2 but still says its missing
In-Reply-To: <c63d8d2e-2c03-f067-effb-cf22ff73e29a@xgm.de>
References: <c63d8d2e-2c03-f067-effb-cf22ff73e29a@xgm.de>
Message-ID: <5717e80d0181b3a70a790b6117f78ecf@sf-mail.de>

Am 2018-05-08 14:51, schrieb Florian Lindner:
> Hello,
> 
> I try to compile my software like
> 
> cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake 
> -DBUILD_SHARED_LIBS=off ../..
> 
>> cat ../../toolchain.cmake
> SET(CMAKE_SYSTEM_NAME Hazelhen)
> SET(CMAKE_C_COMPILER       cc)
> SET(CMAKE_CXX_COMPILER     CC)
> SET(CMAKE_Fortran_COMPILER ftn)
> 
> which gives me the error:
> 
> CMake Error at
> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148
> (message):
>   Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES) (found version 
> "2.9.4")
> Call Stack (most recent call first):
>   /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388
> (_FPHSA_FAILURE_MESSAGE)
>   /usr/share/cmake/Modules/FindLibXml2.cmake:69
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>   CMakeLists.txt:73 (find_package)

It can determine the version, e.g. because it can ask pkg-config or 
finds the header, but it does not find the library to link to.

> I am a bit puzzled, because it says it found libxml 2.9.4, but then
> again does not set the $LIBXML2_LIBRARIES.
> 
> Usage is
> 
> find_package(LibXml2 REQlesUIRED)

sure?

Eike

From j.kreuzberger at procitec.de  Tue May  8 10:47:03 2018
From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=)
Date: Tue, 8 May 2018 16:47:03 +0200
Subject: [CMake] =?utf-8?q?Skipping_Tests_if_FIXTURES=5FSETUP_is_skipped?=
Message-ID: <kcim.5af1b867.400f.0a70242d6e83bc71@kopano.procitec.de>

Hi!

I'm working with the FIXTURES feature of the ctest's and find it very usefull.

I want to skip certain tests if the setup test is skipped

so i added a tests with SKIP_RETURN_CODE feature and set it as FIXTURES_SETUP "tty" (just calling command tty -s on unix)
my assumption is that now all tests with FIXTURES_REQUIRED "tty" are also skipped.
but it does not seem so. The setup test is skipped, but all tests are executed (and fail)

The documentation only says the if the SETUP tests FAILS, the tests requiring the FIXTURES_SETUP are not executed,
but then the setup test itself goes into FAIL count, i want it to be skipped

It this a bug or are there better solutions than my hack? I now generate files in setup test and add them as REQUIRED_FILES in the dependent tests.


Any help appreciated,
Joerg


From robert.maynard at kitware.com  Tue May  8 12:27:00 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 08 May 2018 16:27:00 +0000
Subject: [CMake] Help Accommodating Ninja when including
 CMAKE_CURRENT_BINARY_DIR
In-Reply-To: <CAJGuVd-_7E2DCOYRR5k1d-u4G_Da0G62Pa2PZ1-mwQZXRCBakA@mail.gmail.com>
References: <0608528B-90C0-4FCE-915D-8398D202DD14@cornell.edu>
 <2124A2DE-7EB1-4856-9720-BC524137B9CE@cornell.edu>
 <CAFzjYVpyxCb4ZhuqQRWSbyPPpvFoZuAjUBNrt7h5WiY32mRyUQ@mail.gmail.com>
 <CAJGuVd-_7E2DCOYRR5k1d-u4G_Da0G62Pa2PZ1-mwQZXRCBakA@mail.gmail.com>
Message-ID: <CAFzjYVpQJmqGdfGS7QWZkiDK2+-AsGDJxwqOAxA45cWf55DExQ@mail.gmail.com>

Here is how I would do this (
https://github.com/robertmaynard/Sandbox/tree/master/CMakeCustomCommandAfterTarget).
In my example the executable is the target I want to have a custom
PRE_BUILD step for.
On Sat, Apr 28, 2018 at 5:02 AM Stephen McDowell <sjm324 at cornell.edu> wrote:


> After much deliberation, I was never successful in getting a synthetic
target to work as expected.  The dilemma is that `add_custom_command`
cannot specify both `TARGET` and `OUTPUT`, the work flow was something like

> add_custom_target(resource-dependency)
> add_custom_command(TARGET resource-dependency ... PRE_BUILD)
> add_custom_command(OUTPUT <files that are generated> DEPENDS
resource-dependency)
> ...
> add_library(actual-obj-library OBJECt <files that are generated> ...
others ...)
> add_dependencies(actual-obj-library resource-dependency)

> I'm sure that's a flawed approach, but in the end I realized I can
actually generate these files at *configure* time <3  The
add_custom_command was just a call to ${CMAKE_COMMAND} ...
resources/bin2c.cmake.  So in the end, it's actually a lot cleaner for us
to just include(resources/bin2c.cmake).

> I doubt this solution will be widely applicable to many projects, but if
you ever find yourself in a situation where you are doing
add_custom_command, where the custom command is calling ${CMAKE_COMMAND},
don't rely on PRE_BUILD because it's not a guarantee.  If you can, just
execute the script at configure time via an include(...) call.

From Kris.Malfettone at sig.com  Tue May  8 16:24:32 2018
From: Kris.Malfettone at sig.com (Malfettone, Kris)
Date: Tue, 8 May 2018 20:24:32 +0000
Subject: [CMake] Memory usage and configuration time for large project
In-Reply-To: <CADFtqor_Dckfd0ApYGT6+ip4-JjRg0E6yfnyTVTp_zSjPD06+Q@mail.gmail.com>
References: <ABC8A9FA-9573-4622-938E-5C3694F49C56@fnal.gov>
 <CAAD4mYj-Bu2usBUy0VWGf8R_zF62E4zZ3YdUvS39mjC89pHsUA@mail.gmail.com>
 <277602CF-2D9A-4273-A93B-33F9449BB1C0@fnal.gov>
 <CADFtqor_Dckfd0ApYGT6+ip4-JjRg0E6yfnyTVTp_zSjPD06+Q@mail.gmail.com>
Message-ID: <06b18441125b4ca5a0c1de3dd7fe21b2@msx.bala.susq.com>

I manage a very large project using CMake that I have done significant restructuring to lower the CMake configure times.  I will say the one thing that surprised me the most is that for one piece of it where we have repeated work done say ?for each folder in this subdir build 11 executables with a ton of code generation.?  If I structure the build as such:

One top level CMakeLists.txt and one single line CMakeLists.txt in each subdir containing do_work(${SUBDIR}):
foreach( SUBDIR ${LIST_OF_SUBDIRS} )
   add_subdirectory(${SUBDIR})
endforeach()

Versus:

One top level CMakeLists.txt:
foreach( SUBDIR ${LIST_OF_SUBDIRS} )
   do_work(${SUBDIR})
endforeach()

In short, the decision to do all the work in the same CMakeLists.txt file or do I enter and leave a CMakeLists.txt for each directory causes a dramatic performance and memory difference.

The add_subdirectory method saves many Gigs of RAM and reduces our configure time from 30 minutes to 5 minutes.  Please note I am writing this from memory so my numbers may be a bit off but scale is accurate.

I don?t know if this is applicable to your case but it was the biggest saving in my project and took a long time to figure out.

-Kris

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Isaiah Norton
Sent: Friday, May 04, 2018 7:51 PM
To: Patrick E Gartung <gartung at fnal.gov>
Cc: cmake at cmake.org
Subject: Re: [CMake] Memory usage and configuration time for large project

As one ballpark datapoint: a "superbuild" of 3D Slicer (slicer.org<http://slicer.org>) has a similar object and library count:

macbook-pro:s5nj inorton$ find ./ -name *.o | wc -l
   14127
macbook-pro:s5nj inorton$ find ./ -name *.dylib -or -name *.so | wc -l
    2158

Based on a few quick tests, the aggregate cmake time is probably about 6-8 minutes for the ninja generator, over the multi-hour build (each dependency is configured and built as a separate sub-project via CMake's ExternalProject mechanism) -- with the caveat that each of those cmake runs is doing lengthy checks that should only be done once if your project strictly uses `add_subdirectory`.

As a more concrete point of comparison, building VTK generates 5747 object files, and a clean configure on my 2-core macbook takes about 90s.

Isaiah



On Fri, May 4, 2018 at 2:16 PM, Patrick E Gartung <gartung at fnal.gov<mailto:gartung at fnal.gov>> wrote:
Just to be clear, the memory and time used are just to configure and generate the makefiles or Ninja file. The build itself can take several hours.

?On 4/30/18, 4:55 PM, "R0b0t1" <r030t1 at gmail.com<mailto:r030t1 at gmail.com>> wrote:

    On Mon, Apr 30, 2018 at 4:44 PM, Patrick E Gartung <gartung at fnal.gov<mailto:gartung at fnal.gov>> wrote:
    >  Hi,
    >
    > We have a large c/c++/fortran project, CMSSW, that is built with a custom tool, scram.
    >
    > https://github.com/cms-sw/cmssw
    >
    > The project might move to a cmake based build in the future. The scripts to convert to CmakeLists.tx has been written
    >
    > https://github.com/cms-sw/cmssw2cmake
    >
    > Tests show that with the cmake files generated with this script, configuring the project uses up to 1.5GB of ram and takes 11 minutes when using -GMakefiles. Using -GNinja and using the latest cmake, this time can be reduced to 8 minutes.
    >
    > The project builds 14k object files, 2.2k libraries, ~600 binaries, 500 generated source files with links to ~100 external libraries.
    >
    > Is this amount of memory usage and time typical for a project of this size?
    >

    I'm inclined to say "yes" as many builds such as Firefox, its
    supporting libraries, and Chrome all take lots of time and memory.
    Chrome uses Ninja, I might add. But the issue is not CMake itself.
    CMake tends to produce better builds.

    As I am not intimately familiar with your project, I can't make good
    concrete suggestions. You may enjoy reading
    https://news.ycombinator.com/item?id=14733829 and searching for build
    optimization strategies.

    Keep in mind a lot of the blame falls on C++ and Windows, should you
    be using Windows. If you aren't using Windows, then the advice in the
    comments above should still be relevant, and give you something to go
    on.

    Cheers,
         R0b0t1

    > Patrick Gartung
    > Fermilab
    >

--

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


________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180508/faab4967/attachment-0001.html>

From espakm at gmail.com  Tue May  8 19:45:59 2018
From: espakm at gmail.com (Miklos Espak)
Date: Tue, 08 May 2018 23:45:59 +0000
Subject: [CMake] include directories not found for object library
Message-ID: <CAOVq=oOnhC86JRnuEkmU4H7wHBzj47b0B4NDDG1_55wqXQP2Yw@mail.gmail.com>

Hi,

I have an abstract class that I want to compile into many applications.
Something like this:

baseapp.h
baseapp.cpp
app1.h
app1.cpp
app2.h
app2.cpp
...

I thought of making an object library from baseapp because I want to
compile it only once and it is used only internally.

However, baseapp depends on other libraries, e.g. dcmjpeg, mylib1 and
mylib2, and the include directories of these of these libraries are not
found. For regular libraries and executables, the include directories are
picked up from the target property of the linked libraries, but for object
libraries you cannot specify target link libraries.

I came up with this:

add_library(baseapp OBJECT baseapp.h baseapp.cpp)
target_include_directories(baseapp PUBLIC
  $<TARGET_PROPERTY:dcmjpeg,INCLUDE_DIRECTORIES>
  $<TARGET_PROPERTY:mylib1,INCLUDE_DIRECTORIES>
  $<TARGET_PROPERTY:mylib2,INCLUDE_DIRECTORIES>)

This works, but it does not look too pretty to me.

I am wondering if there is a more elegant way.

E.g. would it be a good idea to propagate the include dirs with the
add_dependencies command? E.g. instead of the above, one could write:

add_dependencies(baseapp dcmjpeg mylib1 mylib2)

Cheers,
Miklos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180508/a6b9133c/attachment.html>

From Nils.Rathmann at dwd.de  Wed May  9 04:42:12 2018
From: Nils.Rathmann at dwd.de (Nils Rathmann)
Date: Wed, 9 May 2018 10:42:12 +0200
Subject: [CMake] rebuild_cache does not fully rebuild the cache information
Message-ID: <0dfe2143-8fc2-93f9-153c-8f5250c97c01@exch.dwd.de>

Hi,
when I change the installation of external dependencies, which are 
located by find_packages, it seems, that it is not enough to run 
rebuild_cache. The information about external software is not thrown 
away and rebuild. I have to delete the CMakeCache.txt and rebuild again.
It this intended? And why is it intended?

I work with cmake 3.9.1.

Thank you,
Nils

From job at noorman.info  Wed May  9 08:51:22 2018
From: job at noorman.info (Job Noorman)
Date: Wed, 9 May 2018 14:51:22 +0200
Subject: [CMake] Forcing a target to be built if another target is built
Message-ID: <5ad84f70-1bcd-f095-6ca9-5cf1958e977a@noorman.info>

Hi all,

We have a large codebase consisting of 200+ modules. Each module is 
defined in its own subdirectory and compiled as a static library.

These modules are not final products on their own but are combined to 
create "projects". We have about 15 projects that all use a subset of 
the modules to implement their functionality. The projects are 
independent in the sense that they cannot be built together; when 
running cmake, we select the project to build.

To ensure that only the modules that are needed by the selected project 
are built, we took the following approach: all modules have a common 
root directory which is included using add_subdirectory with the 
EXCLUDE_FROM_ALL flag. Then, the current project's root directory is 
added without this flag. This ensures that the targets defined by the 
project and the modules that they need (but no other) are added to the 
build system. This works very well and is much nicer than having to 
define options for all optional modules to be able to disable them.

There is one catch, however: each module defines an executable that runs 
its unit tests. What should happen is that if a module is built by a 
project, its unit tests are also built. However, there seems to be no 
way to define this relationship in CMake. What we would like to express 
is that "if library A is built, then executable ATest should also be 
built". Since ATest obviously links against A, we cannot use 
add_dependencies(A ATest) since this creates a circular dependency 
between an executable and a library.

Note that the "option" approach briefly mentioned above would allow us 
to express this but this would be completely unwieldy in our case.

Is there currently a way in CMake to express this relation between a 
library and an executable?

If not, would the following suggestion make sense?: A target property 
"INTERFACE_DEPENDENCIES" could be added that would set the 
MANUALLY_ADDED_DEPENDENCIES target property of dependents. Setting this 
property on A with ATest as value would then solve my problem (note that 
I proposed adding this property for a different use case here: 
https://gitlab.kitware.com/cmake/cmake/issues/14633).

Regards,
Job


From robert.maynard at kitware.com  Wed May  9 09:08:12 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 09 May 2018 13:08:12 +0000
Subject: [CMake] -std=c++17 vs -std=c++1y
In-Reply-To: <F36DF6E1-3477-4418-B0FF-028859A405C6@gmail.com>
References: <3F24E24D-6647-4D18-AF86-60AA1D72BDAD@gmail.com>
 <CAE1uMrUCJH3mJFAj+TzwZwbCYMRWD_Hc99g52sETK=iNLvduFA@mail.gmail.com>
 <F36DF6E1-3477-4418-B0FF-028859A405C6@gmail.com>
Message-ID: <CAFzjYVo4VcoLKfWaTWo6ETOLW_KMxw_XcDLHGmtWj8xPcUMObQ@mail.gmail.com>

If you have standard required enabled the compiler version shouldn't decay
down to 14 when asking for 17.

I recommend having a small test repo and using cmake --trace/--trace-expand
to determine where the gnu++1y is coming from. It is not clear when looking
at Modules/Compiler/Clang-CXX.cmake how gnu++1y would be used unless CMake
is thinking you are asking for C++14 on clang 3.5.
On Sun, May 6, 2018 at 1:35 PM Andrew Brownsword <
andrew.e.brownsword at gmail.com> wrote:

> Well, I am specifying:

> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> set(CMAKE_CXX_STANDARD 17)
> set(CMAKE_CXX_EXTENSIONS ON)

> and the compiler line contains ?-std=gnu++1y?.  I?m using a very recent
source build of CLang and libc++.  Any idea why cmake would fall back to 1y
in this case?





> On May 6, 2018, at 9:05 AM, Jean-Micha?l Celerier <
jeanmichael.celerier at gmail.com> wrote:

> Note that c++17 is c++1z. c++1y was C++14.



> -------
> Jean-Micha?l Celerier
> http://www.jcelerier.name

> On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <
andrew.e.brownsword at gmail.com> wrote:

>> Hi,

>> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
CMAKE_CXX_STANDARD?  I?m finding that it seems to be a common practice to
use the value of the preprocessor define __cplusplus (which is a date), and
the value differs depending on whether 17 or 1y is used (at least with
CLang).  I haven?t figured out how to get cmake to emit -std=c++17, it
always seems to use 1y, which is causing problems with code that assumes
the __cplusplus date reflects the c++17 standardization date.

>> Thanks,
>>     Andrew

>> --

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

From mailinglists at xgm.de  Wed May  9 10:47:05 2018
From: mailinglists at xgm.de (Florian Lindner)
Date: Wed, 9 May 2018 16:47:05 +0200
Subject: [CMake] cmake finds libxml2 but still says its missing
In-Reply-To: <5717e80d0181b3a70a790b6117f78ecf@sf-mail.de>
References: <c63d8d2e-2c03-f067-effb-cf22ff73e29a@xgm.de>
 <5717e80d0181b3a70a790b6117f78ecf@sf-mail.de>
Message-ID: <62185b00-e40d-db79-21d1-45738a1008da@xgm.de>



Am 08.05.2018 um 15:12 schrieb Rolf Eike Beer:
> Am 2018-05-08 14:51, schrieb Florian Lindner:
>> Hello,
>>
>> I try to compile my software like
>>
>> cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -DBUILD_SHARED_LIBS=off ../..
>>
>>> cat ../../toolchain.cmake
>> SET(CMAKE_SYSTEM_NAME Hazelhen)
>> SET(CMAKE_C_COMPILER?????? cc)
>> SET(CMAKE_CXX_COMPILER???? CC)
>> SET(CMAKE_Fortran_COMPILER ftn)
>>
>> which gives me the error:
>>
>> CMake Error at
>> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148
>> (message):
>> ? Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES) (found version "2.9.4")
>> Call Stack (most recent call first):
>> ? /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388
>> (_FPHSA_FAILURE_MESSAGE)
>> ? /usr/share/cmake/Modules/FindLibXml2.cmake:69
>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>> ? CMakeLists.txt:73 (find_package)
> 
> It can determine the version, e.g. because it can ask pkg-config or finds the header, but it does not find the library
> to link to.

Ok, is there any way to get more information on that? CMakeOutput.log contains no reference at all to "xml".

The library files are there:

> ls /usr/lib/libxml*
/usr/lib/libxml2.so.2  /usr/lib/libxml2.so.2.9.4

>> I am a bit puzzled, because it says it found libxml 2.9.4, but then
>> again does not set the $LIBXML2_LIBRARIES.
>>
>> Usage is
>>
>> find_package(LibXml2 REQlesUIRED)
> 
> sure?

Haha, not really. Obviously was typing in the wrong window, in the file it's REQUIRED, of course.

> Eike

Best,
Florian



From eike at sf-mail.de  Wed May  9 10:49:51 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Wed, 09 May 2018 16:49:51 +0200
Subject: [CMake] cmake finds libxml2 but still says its missing
In-Reply-To: <62185b00-e40d-db79-21d1-45738a1008da@xgm.de>
References: <c63d8d2e-2c03-f067-effb-cf22ff73e29a@xgm.de>
 <5717e80d0181b3a70a790b6117f78ecf@sf-mail.de>
 <62185b00-e40d-db79-21d1-45738a1008da@xgm.de>
Message-ID: <795cd91e48426b047b7c9aab348d8195@sf-mail.de>

Florian Lindner wrote:
> Am 08.05.2018 um 15:12 schrieb Rolf Eike Beer:
>> Am 2018-05-08 14:51, schrieb Florian Lindner:
>>> Hello,
>>> 
>>> I try to compile my software like
>>> 
>>> cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake 
>>> -DBUILD_SHARED_LIBS=off ../..
>>> 
>>>> cat ../../toolchain.cmake
>>> SET(CMAKE_SYSTEM_NAME Hazelhen)
>>> SET(CMAKE_C_COMPILER?????? cc)
>>> SET(CMAKE_CXX_COMPILER???? CC)
>>> SET(CMAKE_Fortran_COMPILER ftn)
>>> 
>>> which gives me the error:
>>> 
>>> CMake Error at
>>> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148
>>> (message):
>>> ? Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES) (found version 
>>> "2.9.4")
>>> Call Stack (most recent call first):
>>> ? /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:388
>>> (_FPHSA_FAILURE_MESSAGE)
>>> ? /usr/share/cmake/Modules/FindLibXml2.cmake:69
>>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>> ? CMakeLists.txt:73 (find_package)
>> 
>> It can determine the version, e.g. because it can ask pkg-config or 
>> finds the header, but it does not find the library
>> to link to.
> 
> Ok, is there any way to get more information on that? CMakeOutput.log
> contains no reference at all to "xml".
> 
> The library files are there:
> 
>> ls /usr/lib/libxml*
> /usr/lib/libxml2.so.2  /usr/lib/libxml2.so.2.9.4

So they are indeed not. The module is looking for libxml2.so, which 
usually comes with the -dev or -devel package.

Eike

From Marek.Vojtko at firaxis.com  Wed May  9 11:49:10 2018
From: Marek.Vojtko at firaxis.com (Marek Vojtko (Firaxis))
Date: Wed, 9 May 2018 15:49:10 +0000
Subject: [CMake] target_link_libraries and Custom Properties
Message-ID: <DM5PR14MB1450EB52CEC2E754ACD4F6B896990@DM5PR14MB1450.namprd14.prod.outlook.com>

Hi,

I have multiple library targets that each provide shader files and headers. I also have multiple executable targets that each depend on a different set of these library targets. The executable targets need to collect the shader files and headers of only the libraries they depend on in order to compile them.

The ideal solution would be to reproduce the transitive dependency behavior controlled by target_link_libraries on a custom target property [0], but as far as I can tell define_property does not do that - it just creates a property on a target that can be queried but is not part of the dependency chain. I also wasn't able to find a way to get a list of targets a given target depends on, so that I could run through it and query each dependent target's custom property manually.

Variables do not solve this problem, because different executables depend on different libraries. Each library would need to know a) about all executables, and b) whether a particular executable depended on said library in order to be able to add the shader files and headers to a per-executable variable.

Is there a way to achieve this in CMake?

[0] CMake has a set of properties that get propagated according to the transitive dependency rules (PRIVATE, INTERFACE, PUBLIC) using target_link_libraries (e.g. COMPILE_DEFINITIONS, COMPILE_OPTIONS, INCLUDE_DIRECTORIES, etc.). I would like to add a custom property, for example SHADER_SOURCES, and have it propagate the same way, i.e. target A that depends on targets B, C, and D would have the INTERFACE_SHADER_SOURCES of targets B, C, and D in its SHADER_SOURCES property.
--
Marek Vojtko
mail: marek.vojtko at firaxis.com
phone: (+1) 410-229-2519


From bill.hoffman at kitware.com  Wed May  9 16:33:30 2018
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Wed, 9 May 2018 16:33:30 -0400
Subject: [CMake] rebuild_cache does not fully rebuild the cache
 information
In-Reply-To: <0dfe2143-8fc2-93f9-153c-8f5250c97c01@exch.dwd.de>
References: <0dfe2143-8fc2-93f9-153c-8f5250c97c01@exch.dwd.de>
Message-ID: <69e8777e-43ca-7344-5e5c-9d24730453b1@kitware.com>

On 5/9/2018 4:42 AM, Nils Rathmann wrote:
> Hi,
> when I change the installation of external dependencies, which are 
> located by find_packages, it seems, that it is not enough to run 
> rebuild_cache. The information about external software is not thrown 
> away?and?rebuild.?I?have?to?delete?the?CMakeCache.txt?and?rebuild?again.
> It?this?intended??And?why?is?it?intended?
> 
> I?work?with?cmake?3.9.1.
rebuild_cache basically just re-runs cmake on the project. It does not 
re-check find_package information.

-Bill


From bozmoz at gmail.com  Wed May  9 19:10:33 2018
From: bozmoz at gmail.com (Christofer Jennings)
Date: Wed, 09 May 2018 23:10:33 +0000
Subject: [CMake] include restbed in my project
In-Reply-To: <CAA2GJqWGfAdtuyguWsT0pJxZkVZ5KH8RrO20ffjy_ogAgboH1w@mail.gmail.com>
References: <CADkJUyEVDMT3sTPpsxfbnmGA5BvOM+Ji-8wtN+8aju0eT5oqmA@mail.gmail.com>
 <CAA2GJqWGfAdtuyguWsT0pJxZkVZ5KH8RrO20ffjy_ogAgboH1w@mail.gmail.com>
Message-ID: <CADkJUyH5VOf64NcdM5kPLrFTW2Z2M3cvfmgv-oQdwDA=u22ibw@mail.gmail.com>

Thanks for the reply. I haven't figured out how to use add_subdirectories
like you suggested but I was able to get it working based on this
https://github.com/josesj/rest-json-cpp-boilerplate

It uses find_package and etc. ... maybe a little overkill, I don't know.
But at least I got off the ground. :)

On Sat, May 5, 2018 at 12:09 PM J Decker <d3ck0r at gmail.com> wrote:

> for such things I often include the sources in my tree and just
> 'add_subdirectory( "extra/restbed" )'
> it's cleaner to do a external project rule...
> which can download/checkout sources and then build those and the output is
> findable by other projects just by referencing the targets.
> https://cmake.org/cmake/help/latest/module/ExternalProject.html
>
> On Sat, May 5, 2018 at 11:21 AM, Christofer Jennings <bozmoz at gmail.com>
> wrote:
>
>> Hi All,
>>
>> How do you use a 3rd party dependency like restbed in a cmake build?
>>
>> Total nube here. First dive into CMake and haven't done C++ for a long
>> long time. So forgive my ignorance :) This could just as easily be an "I
>> forgot C++" as an "I don't know CMake"...
>>
>> I'm trying to use restbed. I've got it to compile and self test with
>> `cmake, `make install`, and `make test` as directed on the site:
>> https://github.com/Corvusoft/restbed#build
>> It makes a `distribution` folder with `include` and `library`
>> sub-folders. The `library` has .a and .so or .dylib files. The `include`
>> folder just has headers, and a `restbed` file with #includes in it.
>>
>> I'm using the example on the same page as starting point:
>> https://github.com/Corvusoft/restbed#example
>>
>> ... I could list out my failed attempts but I don't think it'd help.
>> Basically find_package doesn't find it, and other things I've tried don't
>> work. I'm digging around online but so far nothing seems to fit--which
>> makes me think it's something really really simple that I just don't
>> understand.
>>
>> Thanks!
>> -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:
>> https://cmake.org/mailman/listinfo/cmake
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180509/48224256/attachment.html>

From d3ck0r at gmail.com  Wed May  9 19:17:49 2018
From: d3ck0r at gmail.com (J Decker)
Date: Wed, 9 May 2018 16:17:49 -0700
Subject: [CMake] include restbed in my project
In-Reply-To: <CADkJUyH5VOf64NcdM5kPLrFTW2Z2M3cvfmgv-oQdwDA=u22ibw@mail.gmail.com>
References: <CADkJUyEVDMT3sTPpsxfbnmGA5BvOM+Ji-8wtN+8aju0eT5oqmA@mail.gmail.com>
 <CAA2GJqWGfAdtuyguWsT0pJxZkVZ5KH8RrO20ffjy_ogAgboH1w@mail.gmail.com>
 <CADkJUyH5VOf64NcdM5kPLrFTW2Z2M3cvfmgv-oQdwDA=u22ibw@mail.gmail.com>
Message-ID: <CAA2GJqWPE1QOXN5ywdEq826R-yG=OZ_nzyt+ipkY13hrzHDtOg@mail.gmail.com>

So I have all these third party libraries I keep a copy of...
https://github.com/d3x0r/SACK/tree/master/src/contrib

So libressl for example, has cmakelists.txt

https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L680
add_subdirectory( src/contrib/libressl/${LIBRESSL_VERSION} )

which I aliased a bit for upgrade/migration/regression...

I also link optionally to bullet...

IF( EXISTS ${BULLET_SOURCE}/CMakeLists.txt )
   # setup a bunch of options...
add_subdirectory( ${BULLET_SOURCE} bullet )


In the second case, bullet is outside my source tree, (next to it with
other top level projects), so I have to specify a name to be used in the
CMAKE_BINARY_DIR  (bullet) to use for temporary space to build...

and then just link like any other included target

target_link_libaraies( myThing bullet ssl tls crypto )


it's really not that hard, and if you don't understand add_subdirectory....
well... I can't imagine such a world it's so good for breaking up things
into related funcational groups...


On Wed, May 9, 2018 at 4:10 PM, Christofer Jennings <bozmoz at gmail.com>
wrote:

> Thanks for the reply. I haven't figured out how to use add_subdirectories
> like you suggested but I was able to get it working based on this
> https://github.com/josesj/rest-json-cpp-boilerplate
>
> It uses find_package and etc. ... maybe a little overkill, I don't know.
> But at least I got off the ground. :)
>
> On Sat, May 5, 2018 at 12:09 PM J Decker <d3ck0r at gmail.com> wrote:
>
>> for such things I often include the sources in my tree and just
>> 'add_subdirectory( "extra/restbed" )'
>> it's cleaner to do a external project rule...
>> which can download/checkout sources and then build those and the output
>> is findable by other projects just by referencing the targets.
>> https://cmake.org/cmake/help/latest/module/ExternalProject.html
>>
>> On Sat, May 5, 2018 at 11:21 AM, Christofer Jennings <bozmoz at gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> How do you use a 3rd party dependency like restbed in a cmake build?
>>>
>>> Total nube here. First dive into CMake and haven't done C++ for a long
>>> long time. So forgive my ignorance :) This could just as easily be an "I
>>> forgot C++" as an "I don't know CMake"...
>>>
>>> I'm trying to use restbed. I've got it to compile and self test with
>>> `cmake, `make install`, and `make test` as directed on the site:
>>> https://github.com/Corvusoft/restbed#build
>>> It makes a `distribution` folder with `include` and `library`
>>> sub-folders. The `library` has .a and .so or .dylib files. The `include`
>>> folder just has headers, and a `restbed` file with #includes in it.
>>>
>>> I'm using the example on the same page as starting point:
>>> https://github.com/Corvusoft/restbed#example
>>>
>>> ... I could list out my failed attempts but I don't think it'd help.
>>> Basically find_package doesn't find it, and other things I've tried don't
>>> work. I'm digging around online but so far nothing seems to fit--which
>>> makes me think it's something really really simple that I just don't
>>> understand.
>>>
>>> Thanks!
>>> -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:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180509/db12d09b/attachment-0001.html>

From mateusz at loskot.net  Fri May 11 12:27:47 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Fri, 11 May 2018 18:27:47 +0200
Subject: [CMake] find_package_handle_standard_args for target-only modules
Message-ID: <CABUeae9a-TBAdDOwNkg9jNy2LbreseGnTi5GyXVYT0JuTbhv1A@mail.gmail.com>

Hi,

When writing a new FindX.cmake module following the spirit of Modern CMake,
that is without setting any X_LIBRARY and X_INCLUDE_DIR variables,
what is the strategy regarding use of find_package_handle_standard_args?

Shall I not use find_package_handle_standard_args at all?
If yes, shall I set X_FOUND and issue any related messages myself?

Shall I use it:
   find_package_handle_standard_args(X DEFAULT_MSG X_LIBRARY X_INCLUDE_DIR)
and follow with
   unset(X_LIBRARY)
    unset(X_INCLUDE_DIR)
annoying users of FindX.cmake

Shall I simply forget the Modern CMake and set the legacy style variables?

Or something else?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From suryakiran.gullapalli at gmail.com  Sun May 13 07:12:17 2018
From: suryakiran.gullapalli at gmail.com (Surya Kiran Gullapalli)
Date: Sun, 13 May 2018 16:42:17 +0530
Subject: [CMake] WIN32_EXECUTABLE property with generator expression
Message-ID: <CAKkRBO3ryfG_YKg0rgfCz3qkB_GxBoKFmpq0msgvhq55u7kXgQ@mail.gmail.com>

With Cmake-3.11.1 and Visual Studio 2017 generator, I'm trying to set
WIN32_EXECUTABLE property on executable only for release mode with
generator expression like this

set_target_properties(target PROPERTIES WIN32_EXECUTABLE $<CONFIG:Release>)

The generator expression doesn't seem to be working as I see
/SUBSYSTEM:CONSOLE link flag for both Debug and Release configurations.

set_target_properties(target PROPERTIES WIN32_EXECUTABLE 1)  is working
though.

Please help.
Thanks,
Surya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180513/e72836f4/attachment.html>

From mateusz at loskot.net  Sun May 13 07:31:12 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Sun, 13 May 2018 13:31:12 +0200
Subject: [CMake] FindODBC: Add module to search for ODBC library (MR #2069)
Message-ID: <CABUeae8qtx2f2hKMX-8sxHT1ZS3bz5YzA_7q9BPNK+o1pGK-gw@mail.gmail.com>

Hi,

I've proposed FindODBC.cmake module:
https://gitlab.kitware.com/cmake/cmake/merge_requests/2069

I'll welcome any critique and review.

The module does not set any public variables, but targets only.
it still uses find_package_handle_standard_args and
attempts to hide private variables.
I posted related question earlier in
https://cmake.org/pipermail/cmake/2018-May/067504.html
I'd be interested to know if the technique used in the module is sound
or if there is a better one recommended.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From CraftedCart at outlook.com  Sun May 13 07:41:07 2018
From: CraftedCart at outlook.com (Michael Ho)
Date: Sun, 13 May 2018 11:41:07 +0000
Subject: [CMake] Link against exe on Windows fails - .a file not found
Message-ID: <MM1P12301MB1433F4F7A6BA4A868BA7E70B919D0@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>

Hey there.

I'm trying to make a plugin system for my application, and thus each plugin will need to link with my main application. This is fine on Linux and macOS, as I can just set the ENABLE_EXPORTS property of my executable target (set_target_properties(${PROJECT_NAME} PROPERTIES ENABLE_EXPORTS 1), and plugins will link just fine. On Windows however, clang++ yells at me that it can't find libws2editor.dll.a.

clang++.exe: error: no such file or directory: 'ws2editor/libws2editor.dll.a'

Upon looking over the CMake docs, it says "For DLL platforms an import library will be created for the exported symbols and then used for linking." - This import library file (presumably the .dll.a) never seems to be created though.


After a bit more digging around I came across <https://github.com/Kitware/CMake/blob/master/Tests/Plugin/CMakeLists.txt> https://github.com/Kitware/CMake/blob/master/Tests/Plugin/CMakeLists.txt - When I clone the CMake repo and try and compile that test myself, it also fails with the same error when using clang + ninja! When building with MSVC/msbuild however it compiles just fine (My project fails to configure when generating files for MSVC however, and ideally I'd like to use the same build config across Win/Mac/Linux).

So how can I get the CMake build on Windows to create this file, or otherwise link with an executable?
Thanks.

If you want the full CMake scripts, they're available on GitHub.
The main executable: <https://github.com/CraftedCart/smblevelworkshop2/blob/master/ws2editor/CMakeLists.txt> https://github.com/CraftedCart/smblevelworkshop2/blob/e85c2a0f6f9eb9a00f22b94aa79426b0874ca8e1/ws2editor/CMakeLists.txt
The plugin: https://github.com/CraftedCart/smblevelworkshop2/blob/e85c2a0f6f9eb9a00f22b94aa79426b0874ca8e1/ws2editorplugins/ws2editorexampleplugin/CMakeLists.txt


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180513/f7c2a687/attachment.html>

From petr.kmoch at gmail.com  Sun May 13 08:34:59 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Sun, 13 May 2018 14:34:59 +0200
Subject: [CMake] WIN32_EXECUTABLE property with generator expression
In-Reply-To: <CAKkRBO3ryfG_YKg0rgfCz3qkB_GxBoKFmpq0msgvhq55u7kXgQ@mail.gmail.com>
References: <CAKkRBO3ryfG_YKg0rgfCz3qkB_GxBoKFmpq0msgvhq55u7kXgQ@mail.gmail.com>
Message-ID: <CAKohaZe7r8epomkJ_ng3F4Lq_20YskvOg97t7Nm3OHV8YaEPeg@mail.gmail.com>

Hi Surya.

Generator expressions are not supported universally in CMake; only some
properties support them, and they are all documented as doing so.
WIN32_EXECUTABLE does not support genexes.

As for a workaround, you could create two executable targets, one which
would only be built in Release and one which would be built in other
configurations. Properties such as EXCLUDE_FROM_ALL and
EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG> might come in handy.

However, I find the whole concept somewhat strange. Why is your executable
so fundamentally different between Release and other configurations?
Perhaps there is a different way of achieving your actual goal, without a
need for this.

Petr

On 13 May 2018 at 13:12, Surya Kiran Gullapalli <
suryakiran.gullapalli at gmail.com> wrote:

> With Cmake-3.11.1 and Visual Studio 2017 generator, I'm trying to set
> WIN32_EXECUTABLE property on executable only for release mode with
> generator expression like this
>
> set_target_properties(target PROPERTIES WIN32_EXECUTABLE $<CONFIG:Release>)
>
> The generator expression doesn't seem to be working as I see
> /SUBSYSTEM:CONSOLE link flag for both Debug and Release configurations.
>
> set_target_properties(target PROPERTIES WIN32_EXECUTABLE 1)  is working
> though.
>
> Please help.
> Thanks,
> Surya
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180513/e0bb329f/attachment-0001.html>

From jan.svitok at gmail.com  Sun May 13 19:34:02 2018
From: jan.svitok at gmail.com (Jano Svitok)
Date: Mon, 14 May 2018 01:34:02 +0200
Subject: [CMake] Link against exe on Windows fails - .a file not found
In-Reply-To: <MM1P12301MB1433F4F7A6BA4A868BA7E70B919D0@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>
References: <MM1P12301MB1433F4F7A6BA4A868BA7E70B919D0@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <CAN2u-c7gY_3zpjBR2JJTPdXWWtDfE4O0W6-VfOAnnYy_r+6E9g@mail.gmail.com>

On Sun, May 13, 2018 at 1:41 PM, Michael Ho <CraftedCart at outlook.com> wrote:
>
> Hey there.
>
> I'm trying to make a plugin system for my application, and thus each
plugin will need to link with my main application. This is fine on Linux
and macOS, as I can just set the ENABLE_EXPORTS property of my executable
target (set_target_properties(${PROJECT_NAME} PROPERTIES ENABLE_EXPORTS 1),
and plugins will link just fine. On Windows however, clang++ yells at me
that it can't find libws2editor.dll.a.
>
> clang++.exe: error: no such file or directory:
'ws2editor/libws2editor.dll.a'
>
> Upon looking over the CMake docs, it says "For DLL platforms an import
library will be created for the exported symbols and then used for
linking." - This import library file (presumably the .dll.a) never seems to
be created though.
>
>
> After a bit more digging around I came across
https://github.com/Kitware/CMake/blob/master/Tests/Plugin/CMakeLists.txt -
When I clone the CMake repo and try and compile that test myself, it also
fails with the same error when using clang + ninja! When building with
MSVC/msbuild however it compiles just fine (My project fails to configure
when generating files for MSVC however, and ideally I'd like to use the
same build config across Win/Mac/Linux).
>
> So how can I get the CMake build on Windows to create this file, or
otherwise link with an executable?

You need to 1. mark some/all symbols to export 2. actually export them
ENABLE_EXPORTS does #2. For #1, you need to either mark each symbol to
export as __declspec(dllexport) or mark all symbols with
WINDOWS_EXPORT_ALL_SYMBOLS (see
https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/,
check also comments for possible drawbacks).

https://github.com/Kitware/CMake/blob/master/Tests/Plugin/include/example.h
shows how to use __declspec(dllexport): for each dll you define a macro (
EXAMPLE_EXPORT here) that becomes either export (when #included from dll)
or import (when #included from code linked to dll). Every
class/function/variable you want to use from the plugin must be marked this
way (example_exe_function). For class members, it's enough to mark the
class.
Finally there's a #define (example_exe_EXPORTS here) that controls how is
the macro defined. See
https://cmake.org/cmake/help/git-master/prop_tgt/DEFINE_SYMBOL.html (I
didn't know this until now, we used to manually define the symbol!)

Jano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180514/d19bdfff/attachment.html>

From jan.svitok at gmail.com  Sun May 13 19:36:50 2018
From: jan.svitok at gmail.com (Jano Svitok)
Date: Mon, 14 May 2018 01:36:50 +0200
Subject: [CMake] Link against exe on Windows fails - .a file not found
In-Reply-To: <CAN2u-c7gY_3zpjBR2JJTPdXWWtDfE4O0W6-VfOAnnYy_r+6E9g@mail.gmail.com>
References: <MM1P12301MB1433F4F7A6BA4A868BA7E70B919D0@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>
 <CAN2u-c7gY_3zpjBR2JJTPdXWWtDfE4O0W6-VfOAnnYy_r+6E9g@mail.gmail.com>
Message-ID: <CAN2u-c5vpGa36vUDu1Jhd2zd26EDvR6LVV8AAv9hh4KW_J8CGA@mail.gmail.com>

On Mon, May 14, 2018 at 1:34 AM, Jano Svitok <jan.svitok at gmail.com> wrote:

> ENABLE_EXPORTS does #2.
>

Note: for dlls (aka shared libraries) symbols are enabled automatically.
You need ENABLE_EXPORTS 1 only for exes.
Note2: I use MSVC, I have little experience with clang.

Jano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180514/6198d909/attachment.html>

From ggarra13 at gmail.com  Sun May 13 20:23:29 2018
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Sun, 13 May 2018 21:23:29 -0300
Subject: [CMake] /W1 and resource.rc files
Message-ID: <e9c26287-faa3-fb1e-2159-10b7226c256d@gmail.com>

I have a VC++ project which compiles with ninja.? I add all the sources 
and a rc file into a single executable by placing them in a variable.
I am running into trouble specifying the /W1 flag in add_definitions.
The flag gets passed onto RC and it fails its compilation.
Also, I get warnings of:
cl : Command line warning D9025 : overriding '/W3' with '/W1'
I am unsure what sets /W3.

-- 
Gonzalo Garramu?o


From ggarra13 at gmail.com  Sun May 13 20:24:18 2018
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Sun, 13 May 2018 21:24:18 -0300
Subject: [CMake] /W1 and resource.rc files
Message-ID: <93942d72-ebf1-8603-8abf-43bdda500172@gmail.com>

I have a VC++ project which compiles with ninja.? I add all the sources 
and a rc file into a single executable by placing them in a variable.
I am running into trouble specifying the /W1 flag in add_definitions.
The flag gets passed onto RC and it fails its compilation.
Also, I get warnings of:
cl : Command line warning D9025 : overriding '/W3' with '/W1'
I am unsure what sets /W3.

Does anyone have a suggestion on how to work around the above, with the 
little fuss possible?

-- 
Gonzalo Garramu?o


From ggarra13 at gmail.com  Mon May 14 09:08:07 2018
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Mon, 14 May 2018 10:08:07 -0300
Subject: [CMake] /W1 and resource.rc files
In-Reply-To: <93942d72-ebf1-8603-8abf-43bdda500172@gmail.com>
References: <93942d72-ebf1-8603-8abf-43bdda500172@gmail.com>
Message-ID: <4fc294da-f97b-c1bf-c95a-86b443d30e31@gmail.com>



El 13/05/2018 a las 21:24, Gonzalo Garramu?o escribi?:
> I am running into trouble specifying the /W1 flag in add_definitions.
This was my problem.? I should have been using add_compile_options.

-- 
Gonzalo Garramu?o


From gil.moses at outlook.com  Mon May 14 09:22:58 2018
From: gil.moses at outlook.com (Gil Moses)
Date: Mon, 14 May 2018 13:22:58 +0000
Subject: [CMake] CMake custom target doesn't build
In-Reply-To: <VI1PR06MB3008ADC24E6F3450A2984439A19D0@VI1PR06MB3008.eurprd06.prod.outlook.com>
References: <VI1PR06MB3008ADC24E6F3450A2984439A19D0@VI1PR06MB3008.eurprd06.prod.outlook.com>
Message-ID: <BN4PR10MB0883462C90820C3B3E2539A4F79C0@BN4PR10MB0883.namprd10.prod.outlook.com>



Hi,
I'm posting this after getting no useful reply in StackOverflow: https://stackoverflow.com/questions/50198141/cmake-custom-target-doesnt-build.

Using CMake 2.8.8, I'm building two targets using:
add_library(tgt1 SHARED a.cpp)
add_library(tgt2 SHARED b.cpp)
After both are built, I need to run a post build step that depends on both targets. I tried many combinations of the following but with no success:
add_custom_target(final_tgt DEPENDS tgt1 tgt2)
add_custom_command(TARGET final_tgt POST_BUILD COMMAND <command> ARGS <args>)
The final target would simply not build, even though its build.make contains the custom command.
Tried to use ALL for the custom target, however make attempts to build it first while missing the first targets.
And I can't use an add_library or add_executable for the final target, since they require specifying source files.
What is the correct way to do it?
===================================
Edit: below is a minimal verifiable source code. What it attempts to do is to compile code (for Mac) in two architectures and as a post-build to create a universal binary using lipo:
cmake_minimum_required(VERSION 2.8)
set(icpc_req_path "/usr/local/bin/icpc-16.0.146")

set(CMAKE_CXX_COMPILER "${icpc_req_path}")

project("CMakeTest")
set(SOURCE_FILES a.cpp)

set (TARGET_NAME "TGT")
set(TARGETS "")
set(ARCHITECTURES i386 x86_64)

foreach(ar ${ARCHITECTURES})
    set(CMAKE_CXX_FLAGS_RELEASE "")
    set(CMAKE_CXX_FLAGS_DEBUG "")
    set(CMAKE_CXX_FLAGS "")

    add_library(TGT_${ar} SHARED ${SOURCE_FILES})
    set_target_properties(${TARGET_NAME}_${ar} PROPERTIES COMPILE_FLAGS "-arch ${ar} -xSSE3")
    set_target_properties(${TARGET_NAME}_${ar} PROPERTIES LINK_FLAGS "-arch ${ar}")
    set(TARGETS "${TARGETS};lib${TARGET_NAME}_${ar}.dylib")
endforeach(ar)

message("Targets: ${TARGETS}")
add_custom_target(${TARGET_NAME} DEPENDS ${TARGETS})
add_custom_command(TARGET ${TARGET_NAME} POST_BUILD COMMAND "lipo" ARGS "-create" ${TARGETS} "-output" "${TARGET_NAME}.dylib")

And the contents of a.cpp is:
int main(){}

Thanks,
Gil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180514/14657e49/attachment-0001.html>

From petr.kmoch at gmail.com  Mon May 14 09:28:41 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Mon, 14 May 2018 15:28:41 +0200
Subject: [CMake] CMake custom target doesn't build
In-Reply-To: <BN4PR10MB0883462C90820C3B3E2539A4F79C0@BN4PR10MB0883.namprd10.prod.outlook.com>
References: <VI1PR06MB3008ADC24E6F3450A2984439A19D0@VI1PR06MB3008.eurprd06.prod.outlook.com>
 <BN4PR10MB0883462C90820C3B3E2539A4F79C0@BN4PR10MB0883.namprd10.prod.outlook.com>
Message-ID: <CAKohaZfgjCdLhErcNqFkmP1qxBA1rm4kDsaA9umU6Oa0qkYMAw@mail.gmail.com>

Hi Gil.

The DEPENDS argument of add_custom_target() is for specifying dependency
*files*, not *targets*.

As the docs (
https://cmake.org/cmake/help/latest/command/add_custom_target.html) say,
what you need is add_dependencies().

Also note that you can add the COMMAND directly to the custom target, no
need for a post-build step:

add_custom_target(final_tgt ALL

  COMMAND <command> ARGS <args>

)
add_dependencies(final_tgt tgt1 tgt2)

This way, the custom target will depend on tgt1 and tgt2, and thus only
build (run its command) after they're up to date.

Petr

On 14 May 2018 at 15:22, Gil Moses <gil.moses at outlook.com> wrote:

>
>
>
>
> Hi,
>
> I?m posting this after getting no useful reply in StackOverflow:
> https://stackoverflow.com/questions/50198141/cmake-
> custom-target-doesnt-build.
>
>
>
> Using CMake 2.8.8, I'm building two targets using:
>
> add_library(tgt1 SHARED a.cpp)
>
> add_library(tgt2 SHARED b.cpp)
>
> After both are built, I need to run a post build step that depends on both
> targets. I tried many combinations of the following but with no success:
>
> add_custom_target(final_tgt DEPENDS tgt1 tgt2)
>
> add_custom_command(TARGET final_tgt POST_BUILD COMMAND <command> ARGS
> <args>)
>
> The final target would simply not build, even though its build.make
> contains the custom command.
>
> Tried to use ALL for the custom target, however make attempts to build it
> first while missing the first targets.
>
> And I can't use an add_library or add_executable for the final target,
> since they require specifying source files.
>
> What is the correct way to do it?
>
> ===================================
>
> Edit: below is a minimal verifiable source code. What it attempts to do is
> to compile code (for Mac) in two architectures and as a post-build to
> create a universal binary using lipo:
>
> cmake_minimum_required(VERSION 2.8)
>
> set(icpc_req_path "/usr/local/bin/icpc-16.0.146")
>
>
>
> set(CMAKE_CXX_COMPILER "${icpc_req_path}")
>
>
>
> project("CMakeTest")
>
> set(SOURCE_FILES a.cpp)
>
>
>
> set (TARGET_NAME "TGT")
>
> set(TARGETS "")
>
> set(ARCHITECTURES i386 x86_64)
>
>
>
> foreach(ar ${ARCHITECTURES})
>
>     set(CMAKE_CXX_FLAGS_RELEASE "")
>
>     set(CMAKE_CXX_FLAGS_DEBUG "")
>
>     set(CMAKE_CXX_FLAGS "")
>
>
>
>     add_library(TGT_${ar} SHARED ${SOURCE_FILES})
>
>     set_target_properties(${TARGET_NAME}_${ar} PROPERTIES COMPILE_FLAGS
> "-arch ${ar} -xSSE3")
>
>     set_target_properties(${TARGET_NAME}_${ar} PROPERTIES LINK_FLAGS
> "-arch ${ar}")
>
>     set(TARGETS "${TARGETS};lib${TARGET_NAME}_${ar}.dylib")
>
> endforeach(ar)
>
>
>
> message("Targets: ${TARGETS}")
>
> add_custom_target(${TARGET_NAME} DEPENDS ${TARGETS})
>
> add_custom_command(TARGET ${TARGET_NAME} POST_BUILD COMMAND "lipo" ARGS
> "-create" ${TARGETS} "-output" "${TARGET_NAME}.dylib")
>
>
>
> And the contents of a.cpp is:
>
> int main(){}
>
>
>
> Thanks,
>
> Gil.
>
>
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180514/70027f7a/attachment.html>

From gil.moses at outlook.com  Mon May 14 12:33:41 2018
From: gil.moses at outlook.com (Gil Moses)
Date: Mon, 14 May 2018 16:33:41 +0000
Subject: [CMake] CMake custom target doesn't build
In-Reply-To: <CAKohaZfgjCdLhErcNqFkmP1qxBA1rm4kDsaA9umU6Oa0qkYMAw@mail.gmail.com>
References: <VI1PR06MB3008ADC24E6F3450A2984439A19D0@VI1PR06MB3008.eurprd06.prod.outlook.com>
 <BN4PR10MB0883462C90820C3B3E2539A4F79C0@BN4PR10MB0883.namprd10.prod.outlook.com>
 <CAKohaZfgjCdLhErcNqFkmP1qxBA1rm4kDsaA9umU6Oa0qkYMAw@mail.gmail.com>
Message-ID: <BN4PR10MB0883B6B4A8771D94ADE24106F79C0@BN4PR10MB0883.namprd10.prod.outlook.com>

Petr,
That worked for me, thanks!!!
Gil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180514/8366c387/attachment.html>

From robert.maynard at kitware.com  Tue May 15 11:50:30 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 15 May 2018 11:50:30 -0400
Subject: [CMake] include directories not found for object library
In-Reply-To: <CAOVq=oOnhC86JRnuEkmU4H7wHBzj47b0B4NDDG1_55wqXQP2Yw@mail.gmail.com>
References: <CAOVq=oOnhC86JRnuEkmU4H7wHBzj47b0B4NDDG1_55wqXQP2Yw@mail.gmail.com>
Message-ID: <CAFzjYVp3Pp9htS0vDdAdT+gcKFG0Q+3ExrY+J50MoT5qP-hwFg@mail.gmail.com>

This is scheduled to be fixed in the next release by allowing OBJECT
libraries to be used in target_link_libraries.



On Tue, May 8, 2018 at 7:46 PM Miklos Espak <espakm at gmail.com> wrote:

> Hi,
>
> I have an abstract class that I want to compile into many applications.
> Something like this:
>
> baseapp.h
> baseapp.cpp
> app1.h
> app1.cpp
> app2.h
> app2.cpp
> ...
>
> I thought of making an object library from baseapp because I want to
> compile it only once and it is used only internally.
>
> However, baseapp depends on other libraries, e.g. dcmjpeg, mylib1 and
> mylib2, and the include directories of these of these libraries are not
> found. For regular libraries and executables, the include directories are
> picked up from the target property of the linked libraries, but for object
> libraries you cannot specify target link libraries.
>
> I came up with this:
>
> add_library(baseapp OBJECT baseapp.h baseapp.cpp)
> target_include_directories(baseapp PUBLIC
>   $<TARGET_PROPERTY:dcmjpeg,INCLUDE_DIRECTORIES>
>   $<TARGET_PROPERTY:mylib1,INCLUDE_DIRECTORIES>
>   $<TARGET_PROPERTY:mylib2,INCLUDE_DIRECTORIES>)
>
> This works, but it does not look too pretty to me.
>
> I am wondering if there is a more elegant way.
>
> E.g. would it be a good idea to propagate the include dirs with the
> add_dependencies command? E.g. instead of the above, one could write:
>
> add_dependencies(baseapp dcmjpeg mylib1 mylib2)
>
> Cheers,
> Miklos
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180515/6fa23955/attachment.html>

From robert.maynard at kitware.com  Tue May 15 13:22:28 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 15 May 2018 13:22:28 -0400
Subject: [CMake] target_link_libraries and Custom Properties
In-Reply-To: <DM5PR14MB1450EB52CEC2E754ACD4F6B896990@DM5PR14MB1450.namprd14.prod.outlook.com>
References: <DM5PR14MB1450EB52CEC2E754ACD4F6B896990@DM5PR14MB1450.namprd14.prod.outlook.com>
Message-ID: <CAFzjYVr+RzK8YkrSysqKq=679eiWpxBXc+unSKjCU4ZdqO9P4A@mail.gmail.com>

>  I also wasn't able to find a way to get a list of targets a given target
depends on, so that I could run through it and query each dependent
target's custom property manually.

This isn't currently possible.

> The executable targets need to collect the shader files and headers of
only the libraries they depend on in order to compile them

Have you looked at using `target_sources`? In general target_sources are
transitive and allow you to include source files for compilation for your
consumers, when you combine them generator expressions you make the
inclusion conditional. A great example would be how Qt5 conditionally
includes sources when it encounters an executable on windows (
https://github.com/qt/qtbase/blob/17b73b0d2b8e0d643bdf13b543cc23d657a4b330/src/corelib/Qt5CoreConfigExtras.cmake.in#L160
).

On Wed, May 9, 2018 at 11:55 AM Marek Vojtko (Firaxis) <
Marek.Vojtko at firaxis.com> wrote:

> Hi,
>
> I have multiple library targets that each provide shader files and
> headers. I also have multiple executable targets that each depend on a
> different set of these library targets. The executable targets need to
> collect the shader files and headers of only the libraries they depend on
> in order to compile them.
>
> The ideal solution would be to reproduce the transitive dependency
> behavior controlled by target_link_libraries on a custom target property
> [0], but as far as I can tell define_property does not do that - it just
> creates a property on a target that can be queried but is not part of the
> dependency chain. I also wasn't able to find a way to get a list of targets
> a given target depends on, so that I could run through it and query each
> dependent target's custom property manually.
>
> Variables do not solve this problem, because different executables depend
> on different libraries. Each library would need to know a) about all
> executables, and b) whether a particular executable depended on said
> library in order to be able to add the shader files and headers to a
> per-executable variable.
>
> Is there a way to achieve this in CMake?
>
> [0] CMake has a set of properties that get propagated according to the
> transitive dependency rules (PRIVATE, INTERFACE, PUBLIC) using
> target_link_libraries (e.g. COMPILE_DEFINITIONS, COMPILE_OPTIONS,
> INCLUDE_DIRECTORIES, etc.). I would like to add a custom property, for
> example SHADER_SOURCES, and have it propagate the same way, i.e. target A
> that depends on targets B, C, and D would have the INTERFACE_SHADER_SOURCES
> of targets B, C, and D in its SHADER_SOURCES property.
> --
> Marek Vojtko
> mail: marek.vojtko at firaxis.com
> phone: (+1) 410-229-2519
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180515/a3ef9490/attachment.html>

From rinkuwithsingh at gmail.com  Tue May 15 15:44:50 2018
From: rinkuwithsingh at gmail.com (Ritesh Singh)
Date: Tue, 15 May 2018 12:44:50 -0700
Subject: [CMake] How to update librarian section of project properties for a
 visual studio project using cmake?
Message-ID: <CAJH9HuLh=aJ0pr5PJo06gz36NZ1ewQOUV3L9F+cz1jQaaTAe5Q@mail.gmail.com>

Hi,

I am creating a static library which in turn depends on several other
libraries. So on Windows in Visual studio for my master library I have
updated Librarian section of project properties to add the other libraries
as additional dependencies. If I update Librarian section manually then I
am able to create the master library successfully, but I am not able to
figure out how to update Librarian from cmake. Now I want to do same thing
using the cmake, I tried several options but nothing worked yet.

Any help would be appreciated.

I have posted these couple of questions and still waiting for the response:

How to update Librarian section of project properties for a Visual studio
project using cmake?
https://stackoverflow.com/q/50346060/2657912?sem=2

CMake not linking static library to other static libraries
https://stackoverflow.com/q/50341118/2657912?sem=2

Thank you!

Regards,
Ritesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180515/5ab00c35/attachment.html>

From calebwherry at gmail.com  Tue May 15 16:12:43 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Tue, 15 May 2018 16:12:43 -0400
Subject: [CMake] How to update librarian section of project properties
 for a visual studio project using cmake?
In-Reply-To: <CAJH9HuLh=aJ0pr5PJo06gz36NZ1ewQOUV3L9F+cz1jQaaTAe5Q@mail.gmail.com>
References: <CAJH9HuLh=aJ0pr5PJo06gz36NZ1ewQOUV3L9F+cz1jQaaTAe5Q@mail.gmail.com>
Message-ID: <CAJxY6XpaVnoB291zhDs1OeBeCUiir94YMVqZQ0V3ed=Z-iBRKg@mail.gmail.com>

You are unfortunately out of luck here. CMake does not provide built in
functionality to create "fat" static libs (multiple static libs combined).
Visual Studio allows this quite easily but CMake does not. All static libs
are considered transitive dependencies and get carried through to
executable and shared libs, they cannot be combined into a single static
lib target using the normal add_library and target_link_libraries calls.

It is possible to get a fat lib but you will have to use custom targets and
look into running the archiver directly (see CMAKE_AR). I did this once
upon a time and ran into a bunch of problems because I needed a
cross-platform solution. Things like [1] will get you down the right path
of using a custom target to get this to work.

-Caleb

[1]
https://stackoverflow.com/questions/14199708/cmake-include-library-dependencies-in-static-lib


On Tue, May 15, 2018 at 3:44 PM, Ritesh Singh <rinkuwithsingh at gmail.com>
wrote:

> Hi,
>
> I am creating a static library which in turn depends on several other
> libraries. So on Windows in Visual studio for my master library I have
> updated Librarian section of project properties to add the other libraries
> as additional dependencies. If I update Librarian section manually then I
> am able to create the master library successfully, but I am not able to
> figure out how to update Librarian from cmake. Now I want to do same
> thing using the cmake, I tried several options but nothing worked yet.
>
> Any help would be appreciated.
>
> I have posted these couple of questions and still waiting for the response:
>
> How to update Librarian section of project properties for a Visual studio
> project using cmake?
> https://stackoverflow.com/q/50346060/2657912?sem=2
>
> CMake not linking static library to other static libraries
> https://stackoverflow.com/q/50341118/2657912?sem=2
>
> Thank you!
>
> Regards,
> Ritesh
>
> --
>
> 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
>
>


-- 
J. Caleb Wherry
*Scientific Software Engineer*

<http://www.calebwherry.com>
http://www.calebwherry.com
+1 (615) 708-5651
calebwherry at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180515/01252ca5/attachment-0001.html>

From calebwherry at gmail.com  Tue May 15 16:18:02 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Tue, 15 May 2018 16:18:02 -0400
Subject: [CMake] How to update librarian section of project properties
 for a visual studio project using cmake?
In-Reply-To: <CAJH9HuLh=aJ0pr5PJo06gz36NZ1ewQOUV3L9F+cz1jQaaTAe5Q@mail.gmail.com>
References: <CAJH9HuLh=aJ0pr5PJo06gz36NZ1ewQOUV3L9F+cz1jQaaTAe5Q@mail.gmail.com>
Message-ID: <CAJxY6Xp-MuFB+ctn_TZRBRiRZ=Gm-tg+7XfLs4gte-a7B0S=Pw@mail.gmail.com>

If you want an official CMake response, take it from Brad King himself:

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

His second comment is interesting, I haven't tried the path of trying to
trick it into thinking it is an object file. That might be the way to go!

-Caleb

On Tue, May 15, 2018 at 3:44 PM, Ritesh Singh <rinkuwithsingh at gmail.com>
wrote:

> Hi,
>
> I am creating a static library which in turn depends on several other
> libraries. So on Windows in Visual studio for my master library I have
> updated Librarian section of project properties to add the other libraries
> as additional dependencies. If I update Librarian section manually then I
> am able to create the master library successfully, but I am not able to
> figure out how to update Librarian from cmake. Now I want to do same
> thing using the cmake, I tried several options but nothing worked yet.
>
> Any help would be appreciated.
>
> I have posted these couple of questions and still waiting for the response:
>
> How to update Librarian section of project properties for a Visual studio
> project using cmake?
> https://stackoverflow.com/q/50346060/2657912?sem=2
>
> CMake not linking static library to other static libraries
> https://stackoverflow.com/q/50341118/2657912?sem=2
>
> Thank you!
>
> Regards,
> Ritesh
>
> --
>
> 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
>
>


-- 
J. Caleb Wherry
*Scientific Software Engineer*

<http://www.calebwherry.com>
http://www.calebwherry.com
+1 (615) 708-5651
calebwherry at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180515/bed0274d/attachment.html>

From robert.maynard at kitware.com  Tue May 15 17:29:20 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 15 May 2018 17:29:20 -0400
Subject: [CMake] Forcing a target to be built if another target is built
In-Reply-To: <5ad84f70-1bcd-f095-6ca9-5cf1958e977a@noorman.info>
References: <5ad84f70-1bcd-f095-6ca9-5cf1958e977a@noorman.info>
Message-ID: <CAFzjYVrxBSLEiS_tMksDeFiWvbNsTgZqRbcsLz3DO0knfNh4dw@mail.gmail.com>

Have you thought about not doing anything in the root CMakeLists for your
testing directories but instead inside the active project you use
add_subdirectory ( it supports relative paths to handle directories not
physically nested inside it ).

On Wed, May 9, 2018 at 8:56 AM Job Noorman <job at noorman.info> wrote:

> Hi all,
>
> We have a large codebase consisting of 200+ modules. Each module is
> defined in its own subdirectory and compiled as a static library.
>
> These modules are not final products on their own but are combined to
> create "projects". We have about 15 projects that all use a subset of
> the modules to implement their functionality. The projects are
> independent in the sense that they cannot be built together; when
> running cmake, we select the project to build.
>
> To ensure that only the modules that are needed by the selected project
> are built, we took the following approach: all modules have a common
> root directory which is included using add_subdirectory with the
> EXCLUDE_FROM_ALL flag. Then, the current project's root directory is
> added without this flag. This ensures that the targets defined by the
> project and the modules that they need (but no other) are added to the
> build system. This works very well and is much nicer than having to
> define options for all optional modules to be able to disable them.
>
> There is one catch, however: each module defines an executable that runs
> its unit tests. What should happen is that if a module is built by a
> project, its unit tests are also built. However, there seems to be no
> way to define this relationship in CMake. What we would like to express
> is that "if library A is built, then executable ATest should also be
> built". Since ATest obviously links against A, we cannot use
> add_dependencies(A ATest) since this creates a circular dependency
> between an executable and a library.
>
> Note that the "option" approach briefly mentioned above would allow us
> to express this but this would be completely unwieldy in our case.
>
> Is there currently a way in CMake to express this relation between a
> library and an executable?
>
> If not, would the following suggestion make sense?: A target property
> "INTERFACE_DEPENDENCIES" could be added that would set the
> MANUALLY_ADDED_DEPENDENCIES target property of dependents. Setting this
> property on A with ATest as value would then solve my problem (note that
> I proposed adding this property for a different use case here:
> https://gitlab.kitware.com/cmake/cmake/issues/14633).
>
> Regards,
> Job
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180515/6f9a6b59/attachment.html>

From drago.trusk at gmail.com  Wed May 16 03:33:10 2018
From: drago.trusk at gmail.com (Drago Trusk)
Date: Wed, 16 May 2018 09:33:10 +0200
Subject: [CMake] [CPack] Avoiding packaging (some) dependencies
Message-ID: <CAHN0WEApejsg-J4Eo1o0u5v8GUV6rEBC_jJn3PAEXTdu38_V2A@mail.gmail.com>

Hi everyone,

I have particular problem which I'm unable to solve.

Lets say there are following components:
 - Main: library/executable
 - Ignorable: Main requires it to build, but not for packaging

Main simply defines:
add_dependencies(Main Ignorable)

FindIgnorable.cmake contains something like:
add_custom_target(Ignorable
  COMMAND ... ... && cmake --build --target install .
  # ...
)

Problem is that deb cpack generator picks this from install tree (tar/zip
doesn't contain Ignorable). So deb ends up with:
# ... correct fs hierarchy
/home/saduser/projects/ignorableinstall

I need to avoid dependency used only for building artifacts.

What I found:
- Remove add_dependency
---- Problem: have to build dependencies manually and will break CI and
other people builds
- Disable automatic packaging of everything and specify custom components
to package
---- Problem: Dependency tree which might be bigger and requires to know
too many details. In addition requires for outside  changes so that all
targets have (appropriate)  install conponents.

I tried everything else that is possible. Am i missing something or are
those two only viable options?

Bye,
Drago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180516/0c4a1ccf/attachment-0001.html>

From espakm at gmail.com  Wed May 16 04:19:30 2018
From: espakm at gmail.com (Miklos Espak)
Date: Wed, 16 May 2018 09:19:30 +0100
Subject: [CMake] include directories not found for object library
In-Reply-To: <CAFzjYVp3Pp9htS0vDdAdT+gcKFG0Q+3ExrY+J50MoT5qP-hwFg@mail.gmail.com>
References: <CAOVq=oOnhC86JRnuEkmU4H7wHBzj47b0B4NDDG1_55wqXQP2Yw@mail.gmail.com>
 <CAFzjYVp3Pp9htS0vDdAdT+gcKFG0Q+3ExrY+J50MoT5qP-hwFg@mail.gmail.com>
Message-ID: <CAOVq=oMyq8LgSPqybaPTMfwb5R6+fbt6Y9wTKwagbT5bUSX72w@mail.gmail.com>

That's awesome, thanks a lot!

So, it would look like this in my case then:

target_link_libraries(baseapp PUBLIC dcmjpeg mylib1 mylib2)

And the object library has to be added to the sources of the app1 and app2,
like now. With other words, object libraries would be allowed on the left
hand side of "target_link_libraries".

This looks the most intuitive way, indeed.

Cheers,
Miklos


On Tue, 15 May 2018 at 16:51, Robert Maynard <robert.maynard at kitware.com>
wrote:

> This is scheduled to be fixed in the next release by allowing OBJECT
> libraries to be used in target_link_libraries.
>
>
>
> On Tue, May 8, 2018 at 7:46 PM Miklos Espak <espakm at gmail.com> wrote:
>
>> Hi,
>>
>> I have an abstract class that I want to compile into many applications.
>> Something like this:
>>
>> baseapp.h
>> baseapp.cpp
>> app1.h
>> app1.cpp
>> app2.h
>> app2.cpp
>> ...
>>
>> I thought of making an object library from baseapp because I want to
>> compile it only once and it is used only internally.
>>
>> However, baseapp depends on other libraries, e.g. dcmjpeg, mylib1 and
>> mylib2, and the include directories of these of these libraries are not
>> found. For regular libraries and executables, the include directories are
>> picked up from the target property of the linked libraries, but for object
>> libraries you cannot specify target link libraries.
>>
>> I came up with this:
>>
>> add_library(baseapp OBJECT baseapp.h baseapp.cpp)
>> target_include_directories(baseapp PUBLIC
>>   $<TARGET_PROPERTY:dcmjpeg,INCLUDE_DIRECTORIES>
>>   $<TARGET_PROPERTY:mylib1,INCLUDE_DIRECTORIES>
>>   $<TARGET_PROPERTY:mylib2,INCLUDE_DIRECTORIES>)
>>
>> This works, but it does not look too pretty to me.
>>
>> I am wondering if there is a more elegant way.
>>
>> E.g. would it be a good idea to propagate the include dirs with the
>> add_dependencies command? E.g. instead of the above, one could write:
>>
>> add_dependencies(baseapp dcmjpeg mylib1 mylib2)
>>
>> Cheers,
>> Miklos
>>
>> --
>>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180516/110871f5/attachment.html>

From eric.noulard at gmail.com  Wed May 16 04:37:26 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 16 May 2018 10:37:26 +0200
Subject: [CMake] [CPack] Avoiding packaging (some) dependencies
In-Reply-To: <CAHN0WEApejsg-J4Eo1o0u5v8GUV6rEBC_jJn3PAEXTdu38_V2A@mail.gmail.com>
References: <CAHN0WEApejsg-J4Eo1o0u5v8GUV6rEBC_jJn3PAEXTdu38_V2A@mail.gmail.com>
Message-ID: <CAPASGLpfDwMe5bhkF3WqfJxuRD1U0i5Q_khoRRH_tSfsPRh4rg@mail.gmail.com>

2018-05-16 9:33 GMT+02:00 Drago Trusk <drago.trusk at gmail.com>:

> Hi everyone,
>
> I have particular problem which I'm unable to solve.
>
> Lets say there are following components:
>  - Main: library/executable
>  - Ignorable: Main requires it to build, but not for packaging
>
> Main simply defines:
> add_dependencies(Main Ignorable)
>
> FindIgnorable.cmake contains something like:
> add_custom_target(Ignorable
>   COMMAND ... ... && cmake --build --target install .
>   # ...
> )
>
> Problem is that deb cpack generator picks this from install tree (tar/zip
> doesn't contain Ignorable). So deb ends up with:
> # ... correct fs hierarchy
> /home/saduser/projects/ignorableinstall
>
> I need to avoid dependency used only for building artifacts.
>
> What I found:
> - Remove add_dependency
> ---- Problem: have to build dependencies manually and will break CI and
> other people builds
> - Disable automatic packaging of everything and specify custom components
> to package
> ---- Problem: Dependency tree which might be bigger and requires to know
> too many details. In addition requires for outside  changes so that all
> targets have (appropriate)  install conponents.
>
> I tried everything else that is possible. Am i missing something or are
> those two only viable options?
>

I think the second option should be ok and not that complicated.
Put the "Ignorable" in an "IgnoredComp" install component and remove this
component from the list of installed components.

get_cmake_property(CPACK_COMPONENTS_ALL COMPONENTS)
list(REMOVE_ITEM CPACK_COMPONENTS_ALL """)

see: https://cmake.org/cmake/help/v3.11/module/CPackComponent.html

AFAIR you don't need to defined a component for every install because CPack
already does that for you.
I think that every bits installed without component specification ends-up
in the trap-them-all
"Unspecified" component which is automatically created by CPack.

see:
https://cmake.org/cmake/help/v3.11/variable/CMAKE_INSTALL_DEFAULT_COMPONENT_NAME.html

Another way to do that even more simply (**if you are sure no component are
defined**)
would be to:

1) install ignorable in "IgnoredComp" component
2) let all other be in your default component
set(CMAKE_INSTALL_DEFAULT_COMPONENT_NAME "InstallThatOnly")
3) only install your default component
set(CPACK_COMPONENTS_ALL "InstallThatOnly")


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180516/31a8ae97/attachment.html>

From rozelak at volny.cz  Wed May 16 07:03:08 2018
From: rozelak at volny.cz (rozelak at volny.cz)
Date: Wed, 16 May 2018 13:03:08 +0200
Subject: [CMake] 
 =?utf-8?q?Install_libraries_defined_in_INTERFACE_targets?=
In-Reply-To: 00010000007500000d8c0162aafd
References: 00010000007500000d8c0162aafd
Message-ID: <20180516130308.D04F3391@volny.cz>

Hallo,
I have created a simple project simulating the issue.?
?
There is 'run.sh' script which first builds an executable using 'add_subdirectory()' CMake command. It works without issues, as expected (the libraries required by Module1 and Module2 are passed to the Module4 builder).
Then, it first builds a STATIC library (defined by Module3) which is then used by Module4. This fails, since I do not know how to export a list of libraries required by Module1 and Module2.
?
Could someone, please, look at the project (which is really simple) and give me a hint how Module3 should export (when install iss called) a CMake script, which would containt the libraries to link with?
?
Thank you very much.
Best regards,
?
Dan
?
?
______________________________________________________________
> Od: <rozelak at volny.cz>
> Komu: <cmake at cmake.org>
> Datum: 04.05.2018 13:25
> P?edm?t: Install libraries defined in INTERFACE targets
>

 Hello,
 I build a project which consists of several "modules" with various mutual dependencies. Each module defines its OBJECT target as:
 ?
 ?
 ? ? # Module 1:
 ? ? add_library(Module1 OBJECT ....)
 ? ? target_include_directories(Module1 PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
 ?
 ? ? add_library(Module1_LIBRARIES INTERFACE)
 ? ? target_link_libraries(Module1_LIBRARIES INTERFACE $<BUILD_INTERFACE:....>)
 ?
 ?
 ? ? # Module 2:
 ? ? add_library(Module2 OBJECT ....)
 ? ? target_include_directories(Module2 PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>)
 ?
 ? ? add_library(Module2_LIBRARIES INTERFACE)
 ? ? target_link_libraries(Module2_LIBRARIES INTERFACE $<BUILD_INTERFACE:....> $<BUILD_INTERFACE:Module1_LIBRARIES>)
 ?
 ? ? add_library(Module2_INCLUDES? INTERFACE)
 ? ? target_include_directories(Module2_INCLUDES? INTERFACE $<TARGET_PROPERTY:Module2,INCLUDE_DIRECTORIES>)
 ? ? target_sources(Module2_INCLUDES? INTERFACE ....)
 ?
 ? ? add_library(Module_CONFFILE? INTERFACE)
 ? ? target_sources(Module2_CONFFILE? INTERFACE Module.config)
 ?
 ?
 And when building a final product (or one of the final products), I use the individual targets:
 ?
 ? ? add_library(Product1 STATIC $<TARGET_OBJECTS:Module1> $<TARGET_OBJECTS:Module2> ...)
 ? ? target_link_libraries(Product1 LINK_INTERFACE_LIBRARIES $<BUILD_INTERFACE:Module1_LIBRARIES> $<BUILD_INTERFACE:Module2_LIBRARIES> ...)
 ?
 ?
 ?
 It works perfectly, the library is built using all the sources. Even when defining INSTALL, all the properties of the targets (include files, config files, etc.) can be accessed and are installed correctly
 ?
 ? ? install(TARGETS Product1? DESTINATION "./" EXPORT "libProduct1")
 ? ? install(FILES $<TARGET_PROPERTY:Module2_CONFFILE,INTERFACE_SOURCES>? ? ? ? ? DESTINATION "./config")
 ? ? install(FILES $<TARGET_PROPERTY:Module2_INCLUDES,INTERFACE_SOURCES>? ? ? ? ? DESTINATION "./include")
 ?
 ? ??
 The problem starts when I want to export a CMake file listing all the libraries which were defined by the individual modules (and are accessed by $<BUILD_INTERFACE:Module2_LIBRARIES>) since they know what they need (how they were configured).
 ?
 When building a static library (which is shown here), I need to export a list of additional libraries necessary to link the Product1 correctly. But using $<BUILD_INTERFACE:Module[]_LIBRARIES> in the INSTALL() command does not work, neither works something like:
 ?
 ? ? install(EXPORT "llibProduct1" DESTINATION "." EXPORT_LINK_INTERFACE_LIBRARIES)
 ?
 ?
 So the question is: how to export the libraries defined by the individual modules to an CMake file which would be installed together with the Product1 library and header files?
 ?
 ?
 Thank you very much,
 Dan
 ?
 P.S. I use CMake 3.6.2.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMake.tar.bz2
Type: application/x-bzip
Size: 2286 bytes
Desc: CMake.tar.bz2
URL: <https://cmake.org/pipermail/cmake/attachments/20180516/b6801261/attachment-0001.bin>

From robert.maynard at kitware.com  Wed May 16 08:37:47 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 16 May 2018 08:37:47 -0400
Subject: [CMake] include directories not found for object library
In-Reply-To: <CAOVq=oMyq8LgSPqybaPTMfwb5R6+fbt6Y9wTKwagbT5bUSX72w@mail.gmail.com>
References: <CAOVq=oOnhC86JRnuEkmU4H7wHBzj47b0B4NDDG1_55wqXQP2Yw@mail.gmail.com>
 <CAFzjYVp3Pp9htS0vDdAdT+gcKFG0Q+3ExrY+J50MoT5qP-hwFg@mail.gmail.com>
 <CAOVq=oMyq8LgSPqybaPTMfwb5R6+fbt6Y9wTKwagbT5bUSX72w@mail.gmail.com>
Message-ID: <CAFzjYVqXz4CwgHDUKeE-XtXLYCSK0p6jV+DRVZXovmK8H4bxFQ@mail.gmail.com>

That is exactly how it will look.

On Wed, May 16, 2018 at 4:19 AM Miklos Espak <espakm at gmail.com> wrote:

> That's awesome, thanks a lot!
>
> So, it would look like this in my case then:
>
> target_link_libraries(baseapp PUBLIC dcmjpeg mylib1 mylib2)
>
> And the object library has to be added to the sources of the app1 and
> app2, like now. With other words, object libraries would be allowed on the
> left hand side of "target_link_libraries".
>
> This looks the most intuitive way, indeed.
>
> Cheers,
> Miklos
>
>
> On Tue, 15 May 2018 at 16:51, Robert Maynard <robert.maynard at kitware.com>
> wrote:
>
>> This is scheduled to be fixed in the next release by allowing OBJECT
>> libraries to be used in target_link_libraries.
>>
>>
>>
>> On Tue, May 8, 2018 at 7:46 PM Miklos Espak <espakm at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have an abstract class that I want to compile into many applications.
>>> Something like this:
>>>
>>> baseapp.h
>>> baseapp.cpp
>>> app1.h
>>> app1.cpp
>>> app2.h
>>> app2.cpp
>>> ...
>>>
>>> I thought of making an object library from baseapp because I want to
>>> compile it only once and it is used only internally.
>>>
>>> However, baseapp depends on other libraries, e.g. dcmjpeg, mylib1 and
>>> mylib2, and the include directories of these of these libraries are not
>>> found. For regular libraries and executables, the include directories are
>>> picked up from the target property of the linked libraries, but for object
>>> libraries you cannot specify target link libraries.
>>>
>>> I came up with this:
>>>
>>> add_library(baseapp OBJECT baseapp.h baseapp.cpp)
>>> target_include_directories(baseapp PUBLIC
>>>   $<TARGET_PROPERTY:dcmjpeg,INCLUDE_DIRECTORIES>
>>>   $<TARGET_PROPERTY:mylib1,INCLUDE_DIRECTORIES>
>>>   $<TARGET_PROPERTY:mylib2,INCLUDE_DIRECTORIES>)
>>>
>>> This works, but it does not look too pretty to me.
>>>
>>> I am wondering if there is a more elegant way.
>>>
>>> E.g. would it be a good idea to propagate the include dirs with the
>>> add_dependencies command? E.g. instead of the above, one could write:
>>>
>>> add_dependencies(baseapp dcmjpeg mylib1 mylib2)
>>>
>>> Cheers,
>>> Miklos
>>>
>>> --
>>>
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180516/a744fae1/attachment.html>

From robert.maynard at kitware.com  Wed May 16 18:12:10 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 16 May 2018 18:12:10 -0400
Subject: [CMake] Install libraries defined in INTERFACE targets
In-Reply-To: <20180516130308.D04F3391@volny.cz>
References: <20180516130308.D04F3391@volny.cz>
Message-ID: <CAFzjYVpSpvCx=1MZurMrHm5VR5sz6jUeTVDW9x4YsQEqxHrmJA@mail.gmail.com>

BUILD_INTERFACE explicitly means that only consumers inside the same
buildsystem should use these libraries. To specify the libraries that
should be used when linking to an installed version of a library you need
to use INSTALL_INTERFACE.

The reason for BUILD and INSTALL interface is to make sure you can build
relocatable libraries and not embed absolute paths into a libraries
specification.

On Wed, May 16, 2018 at 7:03 AM <rozelak at volny.cz> wrote:

> Hallo,
> I have created a simple project simulating the issue.
>
> There is 'run.sh' script which first builds an executable using
> 'add_subdirectory()' CMake command. It works without issues, as expected
> (the libraries required by Module1 and Module2 are passed to the Module4
> builder).
> Then, it first builds a STATIC library (defined by Module3) which is then
> used by Module4. This fails, since I do not know how to export a list of
> libraries required by Module1 and Module2.
>
> Could someone, please, look at the project (which is really simple) and
> give me a hint how Module3 should export (when install iss called) a CMake
> script, which would containt the libraries to link with?
>
> Thank you very much.
> Best regards,
>
> Dan
>
>
> ______________________________________________________________
> > Od: <rozelak at volny.cz>
> > Komu: <cmake at cmake.org>
> > Datum: 04.05.2018 13:25
> > P?edm?t: Install libraries defined in INTERFACE targets
> >
>
>  Hello,
>  I build a project which consists of several "modules" with various mutual
> dependencies. Each module defines its OBJECT target as:
>
>
>      # Module 1:
>      add_library(Module1 OBJECT ....)
>      target_include_directories(Module1 PRIVATE
> ${CMAKE_CURRENT_SOURCE_DIR})
>
>      add_library(Module1_LIBRARIES INTERFACE)
>      target_link_libraries(Module1_LIBRARIES INTERFACE
> $<BUILD_INTERFACE:....>)
>
>
>      # Module 2:
>      add_library(Module2 OBJECT ....)
>      target_include_directories(Module2 PUBLIC
> $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>)
>
>      add_library(Module2_LIBRARIES INTERFACE)
>      target_link_libraries(Module2_LIBRARIES INTERFACE
> $<BUILD_INTERFACE:....> $<BUILD_INTERFACE:Module1_LIBRARIES>)
>
>      add_library(Module2_INCLUDES  INTERFACE)
>      target_include_directories(Module2_INCLUDES  INTERFACE
> $<TARGET_PROPERTY:Module2,INCLUDE_DIRECTORIES>)
>      target_sources(Module2_INCLUDES  INTERFACE ....)
>
>      add_library(Module_CONFFILE  INTERFACE)
>      target_sources(Module2_CONFFILE  INTERFACE Module.config)
>
>
>  And when building a final product (or one of the final products), I use
> the individual targets:
>
>      add_library(Product1 STATIC $<TARGET_OBJECTS:Module1>
> $<TARGET_OBJECTS:Module2> ...)
>      target_link_libraries(Product1 LINK_INTERFACE_LIBRARIES
> $<BUILD_INTERFACE:Module1_LIBRARIES> $<BUILD_INTERFACE:Module2_LIBRARIES>
> ...)
>
>
>
>  It works perfectly, the library is built using all the sources. Even when
> defining INSTALL, all the properties of the targets (include files, config
> files, etc.) can be accessed and are installed correctly
>
>      install(TARGETS Product1  DESTINATION "./" EXPORT "libProduct1")
>      install(FILES $<TARGET_PROPERTY:Module2_CONFFILE,INTERFACE_SOURCES>
>         DESTINATION "./config")
>      install(FILES $<TARGET_PROPERTY:Module2_INCLUDES,INTERFACE_SOURCES>
>         DESTINATION "./include")
>
>
>  The problem starts when I want to export a CMake file listing all the
> libraries which were defined by the individual modules (and are accessed by
> $<BUILD_INTERFACE:Module2_LIBRARIES>) since they know what they need (how
> they were configured).
>
>  When building a static library (which is shown here), I need to export a
> list of additional libraries necessary to link the Product1 correctly. But
> using $<BUILD_INTERFACE:Module[]_LIBRARIES> in the INSTALL() command does
> not work, neither works something like:
>
>      install(EXPORT "llibProduct1" DESTINATION "."
> EXPORT_LINK_INTERFACE_LIBRARIES)
>
>
>  So the question is: how to export the libraries defined by the individual
> modules to an CMake file which would be installed together with the
> Product1 library and header files?
>
>
>  Thank you very much,
>  Dan
>
>  P.S. I use CMake 3.6.2.
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180516/cd3eb5c9/attachment.html>

From job at noorman.info  Thu May 17 06:19:30 2018
From: job at noorman.info (Job Noorman)
Date: Thu, 17 May 2018 12:19:30 +0200
Subject: [CMake] Forcing a target to be built if another target is built
In-Reply-To: <CAFzjYVrxBSLEiS_tMksDeFiWvbNsTgZqRbcsLz3DO0knfNh4dw@mail.gmail.com>
References: <5ad84f70-1bcd-f095-6ca9-5cf1958e977a@noorman.info>
 <CAFzjYVrxBSLEiS_tMksDeFiWvbNsTgZqRbcsLz3DO0knfNh4dw@mail.gmail.com>
Message-ID: <cd2f2c98-7d75-7330-88f1-d62fbe1b0125@noorman.info>

I'm not sure I completely understand what you mean but I think your 
suggestion would be to list *all* needed subdirectories in the active 
project. This is not what a want. The active project simply lists its 
*direct* dependencies (via target_link_libraries) and CMake then figures 
out all the needed transitive dependencies.

Please correct me if i missed your point :-)


On 15/05/18 23:29, Robert Maynard wrote:
>
> Have you thought about not doing anything in the root CMakeLists for 
> your testing directories but instead inside the active project you use 
> add_subdirectory ( it supports relative paths to handle directories 
> not physically nested inside it ).
>
> On Wed, May 9, 2018 at 8:56 AM Job Noorman <job at noorman.info 
> <mailto:job at noorman.info>> wrote:
>
>     Hi all,
>
>     We have a large codebase consisting of 200+ modules. Each module is
>     defined in its own subdirectory and compiled as a static library.
>
>     These modules are not final products on their own but are combined to
>     create "projects". We have about 15 projects that all use a subset of
>     the modules to implement their functionality. The projects are
>     independent in the sense that they cannot be built together; when
>     running cmake, we select the project to build.
>
>     To ensure that only the modules that are needed by the selected
>     project
>     are built, we took the following approach: all modules have a common
>     root directory which is included using add_subdirectory with the
>     EXCLUDE_FROM_ALL flag. Then, the current project's root directory is
>     added without this flag. This ensures that the targets defined by the
>     project and the modules that they need (but no other) are added to
>     the
>     build system. This works very well and is much nicer than having to
>     define options for all optional modules to be able to disable them.
>
>     There is one catch, however: each module defines an executable
>     that runs
>     its unit tests. What should happen is that if a module is built by a
>     project, its unit tests are also built. However, there seems to be no
>     way to define this relationship in CMake. What we would like to
>     express
>     is that "if library A is built, then executable ATest should also be
>     built". Since ATest obviously links against A, we cannot use
>     add_dependencies(A ATest) since this creates a circular dependency
>     between an executable and a library.
>
>     Note that the "option" approach briefly mentioned above would
>     allow us
>     to express this but this would be completely unwieldy in our case.
>
>     Is there currently a way in CMake to express this relation between a
>     library and an executable?
>
>     If not, would the following suggestion make sense?: A target property
>     "INTERFACE_DEPENDENCIES" could be added that would set the
>     MANUALLY_ADDED_DEPENDENCIES target property of dependents. Setting
>     this
>     property on A with ATest as value would then solve my problem
>     (note that
>     I proposed adding this property for a different use case here:
>     https://gitlab.kitware.com/cmake/cmake/issues/14633).
>
>     Regards,
>     Job
>
>     -- 
>
>     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:
>     https://cmake.org/mailman/listinfo/cmake
>


From robert.maynard at kitware.com  Thu May 17 09:50:03 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 17 May 2018 09:50:03 -0400
Subject: [CMake] Forcing a target to be built if another target is built
In-Reply-To: <cd2f2c98-7d75-7330-88f1-d62fbe1b0125@noorman.info>
References: <5ad84f70-1bcd-f095-6ca9-5cf1958e977a@noorman.info>
 <CAFzjYVrxBSLEiS_tMksDeFiWvbNsTgZqRbcsLz3DO0knfNh4dw@mail.gmail.com>
 <cd2f2c98-7d75-7330-88f1-d62fbe1b0125@noorman.info>
Message-ID: <CAFzjYVr6qPH5uW4f4uVM3v9FH-QT2ueeaeiorc+m4W6trmX_fA@mail.gmail.com>

That is roughly what I am saying. In my head you had a layout that looked
like

-> root_dir
--> module_A
--> tests_A
--> module_B
--> tests_B

So while it is tedious to have module_A explicitly add tests_A it would be
a possible solution. The problem is one of graph building.  Currently the
CMake 'all' graph properly represents building the active module and all
dependencies it needs. Separately you have a pool of smaller graphs that
represent all tests and targets that are from sub-directories that had
EXCLUDE_FROM_ALL applied. Nothing is quickly coming to me that will allow
you to add more components to the 'all' graph after the fact.

On Thu, May 17, 2018 at 6:19 AM Job Noorman <job at noorman.info> wrote:

> I'm not sure I completely understand what you mean but I think your
> suggestion would be to list *all* needed subdirectories in the active
> project. This is not what a want. The active project simply lists its
> *direct* dependencies (via target_link_libraries) and CMake then figures
> out all the needed transitive dependencies.
>
> Please correct me if i missed your point :-)
>
>
> On 15/05/18 23:29, Robert Maynard wrote:
> >
> > Have you thought about not doing anything in the root CMakeLists for
> > your testing directories but instead inside the active project you use
> > add_subdirectory ( it supports relative paths to handle directories
> > not physically nested inside it ).
> >
> > On Wed, May 9, 2018 at 8:56 AM Job Noorman <job at noorman.info
> > <mailto:job at noorman.info>> wrote:
> >
> >     Hi all,
> >
> >     We have a large codebase consisting of 200+ modules. Each module is
> >     defined in its own subdirectory and compiled as a static library.
> >
> >     These modules are not final products on their own but are combined to
> >     create "projects". We have about 15 projects that all use a subset of
> >     the modules to implement their functionality. The projects are
> >     independent in the sense that they cannot be built together; when
> >     running cmake, we select the project to build.
> >
> >     To ensure that only the modules that are needed by the selected
> >     project
> >     are built, we took the following approach: all modules have a common
> >     root directory which is included using add_subdirectory with the
> >     EXCLUDE_FROM_ALL flag. Then, the current project's root directory is
> >     added without this flag. This ensures that the targets defined by the
> >     project and the modules that they need (but no other) are added to
> >     the
> >     build system. This works very well and is much nicer than having to
> >     define options for all optional modules to be able to disable them.
> >
> >     There is one catch, however: each module defines an executable
> >     that runs
> >     its unit tests. What should happen is that if a module is built by a
> >     project, its unit tests are also built. However, there seems to be no
> >     way to define this relationship in CMake. What we would like to
> >     express
> >     is that "if library A is built, then executable ATest should also be
> >     built". Since ATest obviously links against A, we cannot use
> >     add_dependencies(A ATest) since this creates a circular dependency
> >     between an executable and a library.
> >
> >     Note that the "option" approach briefly mentioned above would
> >     allow us
> >     to express this but this would be completely unwieldy in our case.
> >
> >     Is there currently a way in CMake to express this relation between a
> >     library and an executable?
> >
> >     If not, would the following suggestion make sense?: A target property
> >     "INTERFACE_DEPENDENCIES" could be added that would set the
> >     MANUALLY_ADDED_DEPENDENCIES target property of dependents. Setting
> >     this
> >     property on A with ATest as value would then solve my problem
> >     (note that
> >     I proposed adding this property for a different use case here:
> >     https://gitlab.kitware.com/cmake/cmake/issues/14633).
> >
> >     Regards,
> >     Job
> >
> >     --
> >
> >     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:
> >     https://cmake.org/mailman/listinfo/cmake
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180517/391b5cd0/attachment-0001.html>

From rozelak at volny.cz  Thu May 17 10:50:14 2018
From: rozelak at volny.cz (rozelak at volny.cz)
Date: Thu, 17 May 2018 16:50:14 +0200
Subject: [CMake] 
 =?utf-8?q?Install_libraries_defined_in_INTERFACE_targets?=
In-Reply-To: 000000001ae80001c3000162ab27
References: <20180516130308.D04F3391@volny.cz> 000000001ae80001c3000162ab27
Message-ID: <20180517165014.F1D3404A@volny.cz>

Hallo?Robert,
thank you for your answer.
?
While I generally understand your explanation, I do not know exactly what to do. I have tried to add
?
? ?target_link_libraries(Module2_LIBRARIES INTERFACE $<INSTALL_INTERFACE:...>)
?
into Modules 1 and 2 together with?
?
? ?install(EXPORT ...
?
in Module 3, but still there is no definition of the required libraries in the CMake file(s) generated (by the EXPORT).
?
Could you give me few more additional hints, please?
?
Thank you very much,
Dan
?


______________________________________________________________
> Od: Robert Maynard <robert.maynard at kitware.com>
> Komu: rozelak at volny.cz
> Datum: 17.05.2018 00:12
> P?edm?t: Re: [CMake] Install libraries defined in INTERFACE targets
>
BUILD_INTERFACE explicitly means that only consumers inside the same buildsystem should use these libraries. To specify the libraries that should be used when linking to an installed version of a library you need to use INSTALL_INTERFACE.The reason for BUILD and INSTALL interface is to make sure you can build relocatable libraries and not embed absolute paths into a libraries specification.?
On Wed, May 16, 2018 at 7:03 AM <rozelak at volny.cz <rozelak at volny.cz>> wrote:Hallo,
 I have created a simple project simulating the issue.?
 ?
 There is 'run.sh' script which first builds an executable using 'add_subdirectory()' CMake command. It works without issues, as expected (the libraries required by Module1 and Module2 are passed to the Module4 builder).
 Then, it first builds a STATIC library (defined by Module3) which is then used by Module4. This fails, since I do not know how to export a list of libraries required by Module1 and Module2.
 ?
 Could someone, please, look at the project (which is really simple) and give me a hint how Module3 should export (when install iss called) a CMake script, which would containt the libraries to link with?
 ?
 Thank you very much.
 Best regards,
 ?
 Dan
 ?
 ?
 ______________________________________________________________
 > Od: <rozelak at volny.cz <rozelak at volny.cz>>
 > Komu: <cmake at cmake.org <cmake at cmake.org>>
 > Datum: 04.05.2018 13:25
 > P?edm?t: Install libraries defined in INTERFACE targets
 >
 
 ?Hello,
 ?I build a project which consists of several "modules" with various mutual dependencies. Each module defines its OBJECT target as:
 ??
 ??
 ?? ? # Module 1:
 ?? ? add_library(Module1 OBJECT ....)
 ?? ? target_include_directories(Module1 PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
 ??
 ?? ? add_library(Module1_LIBRARIES INTERFACE)
 ?? ? target_link_libraries(Module1_LIBRARIES INTERFACE $<BUILD_INTERFACE:....>)
 ??
 ??
 ?? ? # Module 2:
 ?? ? add_library(Module2 OBJECT ....)
 ?? ? target_include_directories(Module2 PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>)
 ??
 ?? ? add_library(Module2_LIBRARIES INTERFACE)
 ?? ? target_link_libraries(Module2_LIBRARIES INTERFACE $<BUILD_INTERFACE:....> $<BUILD_INTERFACE:Module1_LIBRARIES>)
 ??
 ?? ? add_library(Module2_INCLUDES? INTERFACE)
 ?? ? target_include_directories(Module2_INCLUDES? INTERFACE $<TARGET_PROPERTY:Module2,INCLUDE_DIRECTORIES>)
 ?? ? target_sources(Module2_INCLUDES? INTERFACE ....)
 ??
 ?? ? add_library(Module_CONFFILE? INTERFACE)
 ?? ? target_sources(Module2_CONFFILE? INTERFACE Module.config)
 ??
 ??
 ?And when building a final product (or one of the final products), I use the individual targets:
 ??
 ?? ? add_library(Product1 STATIC $<TARGET_OBJECTS:Module1> $<TARGET_OBJECTS:Module2> ...)
 ?? ? target_link_libraries(Product1 LINK_INTERFACE_LIBRARIES $<BUILD_INTERFACE:Module1_LIBRARIES> $<BUILD_INTERFACE:Module2_LIBRARIES> ...)
 ??
 ??
 ??
 ?It works perfectly, the library is built using all the sources. Even when defining INSTALL, all the properties of the targets (include files, config files, etc.) can be accessed and are installed correctly
 ??
 ?? ? install(TARGETS Product1? DESTINATION "./" EXPORT "libProduct1")
 ?? ? install(FILES $<TARGET_PROPERTY:Module2_CONFFILE,INTERFACE_SOURCES>? ? ? ? ? DESTINATION "./config")
 ?? ? install(FILES $<TARGET_PROPERTY:Module2_INCLUDES,INTERFACE_SOURCES>? ? ? ? ? DESTINATION "./include")
 ??
 ?? ??
 ?The problem starts when I want to export a CMake file listing all the libraries which were defined by the individual modules (and are accessed by $<BUILD_INTERFACE:Module2_LIBRARIES>) since they know what they need (how they were configured).
 ??
 ?When building a static library (which is shown here), I need to export a list of additional libraries necessary to link the Product1 correctly. But using $<BUILD_INTERFACE:Module[]_LIBRARIES> in the INSTALL() command does not work, neither works something like:
 ??
 ?? ? install(EXPORT "llibProduct1" DESTINATION "." EXPORT_LINK_INTERFACE_LIBRARIES)
 ??
 ??
 ?So the question is: how to export the libraries defined by the individual modules to an CMake file which would be installed together with the Product1 library and header files?
 ??
 ??
 ?Thank you very much,
 ?Dan
 ??
 ?P.S. I use CMake 3.6.2.
 -- 
 
 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 <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 <http://cmake.org/cmake/help/support.html>
 CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html>
 CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html>
 
 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
 
 Follow this link to subscribe/unsubscribe:
 https://cmake.org/mailman/listinfo/cmake <https://cmake.org/mailman/listinfo/cmake>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180517/42252ce9/attachment.html>

From robert.maynard at kitware.com  Thu May 17 13:47:20 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 17 May 2018 13:47:20 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.11.2 available for download
Message-ID: <CAFzjYVq=wPOF-NpijH+FXa5gaq7v0LaQK4yuUH2PyE1hQMQngA@mail.gmail.com>

We are pleased to announce that CMake 3.11.2 is now available for download.

Please use the latest release from our download page:
   https://cmake.org/download/

* Calling "add_library()" to create an alias of an imported target
   that is not globally visible now causes an error again as it did
   prior to 3.11.0.  This diagnostic was accidentally dropped from
   CMake 3.11.0 and 3.11.1 by the change to allow globally visible
   imported targets to be aliased.

* The "FindQt4" module "qt4_wrap_cpp", "qt4_wrap_ui" and
   "qt4_add_resources" macros now set "SKIP_AUTOMOC" and "SKIP_AUTOUIC"
   on their generated files.  These files never need to be processed by
   moc or uic, and we must say so explicitly to account for policy
   "CMP0071".

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.11.2 since 3.11.1:

Brad King (8):
       Ninja: Do not add empty custom command for file(GENERATE) outputs
       C++ feature checks: Filter out warnings caused by local configuration
       libuv: linux/sparc64: use fcntl to set and clear O_NONBLOCK
       FindCUDA: Fix regression in separable compilation without cublas
       FindBoost: Remove extra indentation in 1.65/1.66 dependency block
       add_library: Restore error on alias of non-global imported target
       add_custom_{command,target}: Fix crash on empty expanded command
       CMake 3.11.2

Christian Pfeiffer (1):
       IRSL: Fix Intel library list for ifort-only setups

Christof Kr?ger (1):
       InstallRequiredSystemLibraries: Check for existence of mfcm dlls

Filip Matzner (1):
       FindBoost: Backport versioned python dependencies for v1.35 to v1.66

Marc Chevrier (5):
       Fix CMAKE_DISABLE_SOURCE_CHANGES recognition of top of build tree
       FindJava, FindJNI, UseJava: update for version 10 support
       FindJava, FindJNI: Ensure most recent version is searched first
       FindJava, FindJNI: fix erroneous regex, enhance registry lookup
       Help: Specify COMPILE_OPTIONS and COMPILE_FLAGS source properties
       usage

Matthew Woehlke (2):
       Qt4Macros: Use get_property/set_property
       Qt4Macros: Don't AUTOMOC or AUTOUIC qt4-generated files

Rolf Eike Beer (2):
       FindPkgConfig: do not unset unused variable
       FindBLAS: do not write an imported target name into BLAS_LIBRARIES

Sebastian Holtermann (1):
       Autogen: Register generated dependency files

From drago.trusk at gmail.com  Thu May 17 17:21:28 2018
From: drago.trusk at gmail.com (Drago Trusk)
Date: Thu, 17 May 2018 23:21:28 +0200
Subject: [CMake] [CPack] Avoiding packaging (some) dependencies
In-Reply-To: <CAPASGLpfDwMe5bhkF3WqfJxuRD1U0i5Q_khoRRH_tSfsPRh4rg@mail.gmail.com>
References: <CAHN0WEApejsg-J4Eo1o0u5v8GUV6rEBC_jJn3PAEXTdu38_V2A@mail.gmail.com>
 <CAPASGLpfDwMe5bhkF3WqfJxuRD1U0i5Q_khoRRH_tSfsPRh4rg@mail.gmail.com>
Message-ID: <CAHN0WEBSh1jyj_r83g3GkjcEmMtph7Nwh-B5QndYp74JxmO6dQ@mail.gmail.com>

Thank you for your answer!

I was afraid there was no other option.
Problem is that "Ignorable" is a transient dependency of a target which I
need (both don't specify components) and therefore both are somewhat out of
my control, but I guess modification to them will be necessary.

I wasn't aware of REMOVE_ITEM CPACK_COMPONENTS_ALL and hint is much
appreciated (though sadly I cannot use it). Good to know ;)

On Wed, May 16, 2018 at 10:37 AM Eric Noulard <eric.noulard at gmail.com>
wrote:

>
>
> 2018-05-16 9:33 GMT+02:00 Drago Trusk <drago.trusk at gmail.com>:
>
>> Hi everyone,
>>
>> I have particular problem which I'm unable to solve.
>>
>> Lets say there are following components:
>>  - Main: library/executable
>>  - Ignorable: Main requires it to build, but not for packaging
>>
>> Main simply defines:
>> add_dependencies(Main Ignorable)
>>
>> FindIgnorable.cmake contains something like:
>> add_custom_target(Ignorable
>>   COMMAND ... ... && cmake --build --target install .
>>   # ...
>> )
>>
>> Problem is that deb cpack generator picks this from install tree (tar/zip
>> doesn't contain Ignorable). So deb ends up with:
>> # ... correct fs hierarchy
>> /home/saduser/projects/ignorableinstall
>>
>> I need to avoid dependency used only for building artifacts.
>>
>> What I found:
>> - Remove add_dependency
>> ---- Problem: have to build dependencies manually and will break CI and
>> other people builds
>> - Disable automatic packaging of everything and specify custom components
>> to package
>> ---- Problem: Dependency tree which might be bigger and requires to know
>> too many details. In addition requires for outside  changes so that all
>> targets have (appropriate)  install conponents.
>>
>> I tried everything else that is possible. Am i missing something or are
>> those two only viable options?
>>
>
> I think the second option should be ok and not that complicated.
> Put the "Ignorable" in an "IgnoredComp" install component and remove this
> component from the list of installed components.
>
> get_cmake_property(CPACK_COMPONENTS_ALL COMPONENTS)
> list(REMOVE_ITEM CPACK_COMPONENTS_ALL """)
>
> see: https://cmake.org/cmake/help/v3.11/module/CPackComponent.html
>
> AFAIR you don't need to defined a component for every install because
> CPack already does that for you.
> I think that every bits installed without component specification ends-up
> in the trap-them-all
> "Unspecified" component which is automatically created by CPack.
>
> see:
> https://cmake.org/cmake/help/v3.11/variable/CMAKE_INSTALL_DEFAULT_COMPONENT_NAME.html
>
> Another way to do that even more simply (**if you are sure no component
> are defined**)
> would be to:
>
> 1) install ignorable in "IgnoredComp" component
> 2) let all other be in your default component
> set(CMAKE_INSTALL_DEFAULT_COMPONENT_NAME "InstallThatOnly")
> 3) only install your default component
> set(CPACK_COMPONENTS_ALL "InstallThatOnly")
>
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180517/b1277fe6/attachment.html>

From CraftedCart at outlook.com  Fri May 18 06:55:02 2018
From: CraftedCart at outlook.com (Michael Ho)
Date: Fri, 18 May 2018 10:55:02 +0000
Subject: [CMake] Link against exe on Windows fails - .a file not found
In-Reply-To: <CAN2u-c7gY_3zpjBR2JJTPdXWWtDfE4O0W6-VfOAnnYy_r+6E9g@mail.gmail.com>
References: <MM1P12301MB1433F4F7A6BA4A868BA7E70B919D0@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>,
 <CAN2u-c7gY_3zpjBR2JJTPdXWWtDfE4O0W6-VfOAnnYy_r+6E9g@mail.gmail.com>
Message-ID: <MM1P12301MB1433151F9A6E9B5868739E7F91900@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>

Ah yes, I forgot Windows doesn't export symbols by default.
Unfortunately adding set_target_properties(${PROJECT_NAME} PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS 1) didn't seem to help however - I get the same file not found error.

Something interesting I noticed however is that if I copy and rename ws2editor/CMakeFiles/ws2editor.dir/objects.a to ws2editor/libws2editor.dll.a, the plugin links just fine and even works when I run the application. I suppose I could add this as some post build step, but it certainly feels like a bit of a hacky solution. This only seems to work for the Unix Makefiles generate however (Which should be fine, although I had been using ninja at the moment so certainly not ideal).

Thanks
- Mike

(Note: sorry for the mostly duplicate message - I wasn't aware that you should use "Reply All" in mailing lists)

________________________________
From: Jano Svitok <jan.svitok at gmail.com>
Sent: 14 May 2018 00:34
To: Michael Ho
Cc: cmake at cmake.org
Subject: Re: [CMake] Link against exe on Windows fails - .a file not found

On Sun, May 13, 2018 at 1:41 PM, Michael Ho <CraftedCart at outlook.com<mailto:CraftedCart at outlook.com>> wrote:
>
> Hey there.
>
> I'm trying to make a plugin system for my application, and thus each plugin will need to link with my main application. This is fine on Linux and macOS, as I can just set the ENABLE_EXPORTS property of my executable target (set_target_properties(${PROJECT_NAME} PROPERTIES ENABLE_EXPORTS 1), and plugins will link just fine. On Windows however, clang++ yells at me that it can't find libws2editor.dll.a.
>
> clang++.exe: error: no such file or directory: 'ws2editor/libws2editor.dll.a'
>
> Upon looking over the CMake docs, it says "For DLL platforms an import library will be created for the exported symbols and then used for linking." - This import library file (presumably the .dll.a) never seems to be created though.
>
>
> After a bit more digging around I came across https://github.com/Kitware/CMake/blob/master/Tests/Plugin/CMakeLists.txt - When I clone the CMake repo and try and compile that test myself, it also fails with the same error when using clang + ninja! When building with MSVC/msbuild however it compiles just fine (My project fails to configure when generating files for MSVC however, and ideally I'd like to use the same build config across Win/Mac/Linux).
>
> So how can I get the CMake build on Windows to create this file, or otherwise link with an executable?

You need to 1. mark some/all symbols to export 2. actually export them
ENABLE_EXPORTS does #2. For #1, you need to either mark each symbol to export as __declspec(dllexport) or mark all symbols with WINDOWS_EXPORT_ALL_SYMBOLS (see https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/, check also comments for possible drawbacks).

https://github.com/Kitware/CMake/blob/master/Tests/Plugin/include/example.h shows how to use __declspec(dllexport): for each dll you define a macro (EXAMPLE_EXPORT here) that becomes either export (when #included from dll) or import (when #included from code linked to dll). Every class/function/variable you want to use from the plugin must be marked this way (example_exe_function). For class members, it's enough to mark the class.
Finally there's a #define (example_exe_EXPORTS here) that controls how is the macro defined. See https://cmake.org/cmake/help/git-master/prop_tgt/DEFINE_SYMBOL.html (I didn't know this until now, we used to manually define the symbol!)

Jano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180518/ce83c2f2/attachment-0001.html>

From CraftedCart at outlook.com  Fri May 18 14:18:42 2018
From: CraftedCart at outlook.com (Michael Ho)
Date: Fri, 18 May 2018 18:18:42 +0000
Subject: [CMake] Link against exe on Windows fails - .a file not found
In-Reply-To: <MM1P12301MB1433151F9A6E9B5868739E7F91900@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>
References: <MM1P12301MB1433F4F7A6BA4A868BA7E70B919D0@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>,
 <CAN2u-c7gY_3zpjBR2JJTPdXWWtDfE4O0W6-VfOAnnYy_r+6E9g@mail.gmail.com>,
 <MM1P12301MB1433151F9A6E9B5868739E7F91900@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <MM1P12301MB1433E2E9DE5DFECFC77183D691900@MM1P12301MB1433.GBRP123.PROD.OUTLOOK.COM>

Looks like I can use ar to generate the .a file for me, regardless of generator - plugins seem to link and load just fine when doing this. Awesome! :)

if(WIN32)
    #Invoke ar to generate a .dll.a from the .obj files, required to link plugins
    add_custom_command(TARGET ${PROJECT_NAME} PRE_LINK
        COMMAND sh -c "${CMAKE_AR} cr lib${PROJECT_NAME}.dll.a $$(find . -name '*.obj' -printf '%p ')"
        COMMENT "Generating lib${PROJECT_NAME}.dll.a for external linking"
        )

    #Also add the install command for libws2editor.dll.a
    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/lib${PROJECT_NAME}.dll.a DESTINATION bin)
endif(WIN32)

-Mike

________________________________
From: Michael Ho <CraftedCart at outlook.com>
Sent: 18 May 2018 11:55
To: Jano Svitok; Michael Ho
Cc: cmake at cmake.org
Subject: Re: [CMake] Link against exe on Windows fails - .a file not found

Ah yes, I forgot Windows doesn't export symbols by default.
Unfortunately adding set_target_properties(${PROJECT_NAME} PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS 1) didn't seem to help however - I get the same file not found error.

Something interesting I noticed however is that if I copy and rename ws2editor/CMakeFiles/ws2editor.dir/objects.a to ws2editor/libws2editor.dll.a, the plugin links just fine and even works when I run the application. I suppose I could add this as some post build step, but it certainly feels like a bit of a hacky solution. This only seems to work for the Unix Makefiles generate however (Which should be fine, although I had been using ninja at the moment so certainly not ideal).

Thanks
- Mike

(Note: sorry for the mostly duplicate message - I wasn't aware that you should use "Reply All" in mailing lists)

________________________________
From: Jano Svitok <jan.svitok at gmail.com>
Sent: 14 May 2018 00:34
To: Michael Ho
Cc: cmake at cmake.org
Subject: Re: [CMake] Link against exe on Windows fails - .a file not found

On Sun, May 13, 2018 at 1:41 PM, Michael Ho <CraftedCart at outlook.com<mailto:CraftedCart at outlook.com>> wrote:
>
> Hey there.
>
> I'm trying to make a plugin system for my application, and thus each plugin will need to link with my main application. This is fine on Linux and macOS, as I can just set the ENABLE_EXPORTS property of my executable target (set_target_properties(${PROJECT_NAME} PROPERTIES ENABLE_EXPORTS 1), and plugins will link just fine. On Windows however, clang++ yells at me that it can't find libws2editor.dll.a.
>
> clang++.exe: error: no such file or directory: 'ws2editor/libws2editor.dll.a'
>
> Upon looking over the CMake docs, it says "For DLL platforms an import library will be created for the exported symbols and then used for linking." - This import library file (presumably the .dll.a) never seems to be created though.
>
>
> After a bit more digging around I came across https://github.com/Kitware/CMake/blob/master/Tests/Plugin/CMakeLists.txt - When I clone the CMake repo and try and compile that test myself, it also fails with the same error when using clang + ninja! When building with MSVC/msbuild however it compiles just fine (My project fails to configure when generating files for MSVC however, and ideally I'd like to use the same build config across Win/Mac/Linux).
>
> So how can I get the CMake build on Windows to create this file, or otherwise link with an executable?

You need to 1. mark some/all symbols to export 2. actually export them
ENABLE_EXPORTS does #2. For #1, you need to either mark each symbol to export as __declspec(dllexport) or mark all symbols with WINDOWS_EXPORT_ALL_SYMBOLS (see https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/, check also comments for possible drawbacks).

https://github.com/Kitware/CMake/blob/master/Tests/Plugin/include/example.h shows how to use __declspec(dllexport): for each dll you define a macro (EXAMPLE_EXPORT here) that becomes either export (when #included from dll) or import (when #included from code linked to dll). Every class/function/variable you want to use from the plugin must be marked this way (example_exe_function). For class members, it's enough to mark the class.
Finally there's a #define (example_exe_EXPORTS here) that controls how is the macro defined. See https://cmake.org/cmake/help/git-master/prop_tgt/DEFINE_SYMBOL.html (I didn't know this until now, we used to manually define the symbol!)

Jano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180518/53df9315/attachment.html>

From fifteenknots505 at gmail.com  Fri May 18 15:43:45 2018
From: fifteenknots505 at gmail.com (Martin Weber)
Date: Fri, 18 May 2018 21:43:45 +0200
Subject: [CMake] CMAKE_EXPORT_COMPILE_COMMANDS, compile_commands.json content
Message-ID: <6554861.hMyLP3eNya@linux>

Hi all,

in the generated compile_commands.json, what are the quoting rules in the 
command fields?
Apart from the fact that a quotation mark in json inside a value has to be 
escaped as *\"*, do the arguments in the command-field follow the shell-
escape rules or do they reflect the arguments passed to exec(1).

Seeing a line in my compile_commands.json starting with

"command": "/usr/bin/c++ -Dprojectname_ROOT_DIR=\\\"/home/username/workspace/
projectname\\\" 

is confusing. What exactly is the value of macro projectname_ROOT_DIR here? A 
string literal?

OTOH, the same line has

-DvtkFiltersFlowPaths_AUTOINIT=\"1(vtkFiltersParallelFlowPaths)\"

which I do recognize as a macro value of string literal type.

Background: My tool tries to get the macro definition from the  
compile_commands.json file [1]

TIA,
	Martin

[1] https://github.com/15knots/cmake4eclipse/issues/74

-- 
Cd wrttn wtht vwls s mch trsr.



From elvis.stansvik at orexplore.com  Sat May 19 09:00:04 2018
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sat, 19 May 2018 15:00:04 +0200
Subject: [CMake] Approach to both shared and static lib (again, sorry)
Message-ID: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>

I know this has been asked before, but I've never seen a really
authoritative answer.

Say I have a simple single-library project.

The advise I've seen is to not pass SHARED or STATIC to the
add_library(..), but instead let the user pass
-DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
or static.

That's fine, but leads to packagers having to do ugly things like e.g:

    https://salsa.debian.org/hle/dlib/blob/master/debian/rules

That is, do two separate configure/build/install, in order to get both
a shared and static version. Note that the above was just an example.
But many packagers do it like this.

How can I make life easier for the packager?

I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
add_library(...), one with SHARED and one with STATIC, but the same
input source files. I could give the two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?).

To not have to repeat the list of sources, I could keep them in a
variable. But that's not recommended in modern CMake AFAIK.

I've also seen people add an object library, and then build the shared
+ static lib from that.

What are your thoughts on all this? How do you go about it? Do you use
the recommended way, with a single add_library(..) and just let
packagers put up with having to do two builds?

Thanks in advance!
Elvis

From mingw.android at gmail.com  Sat May 19 09:09:43 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Sat, 19 May 2018 14:09:43 +0100
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
Message-ID: <CAOYw7dt2a_ZipifJRW5MGa2P4M1G-4OGVBjkXCwzeZ1Af-o-eQ@mail.gmail.com>

And the situation is *far* worse on Windows where the extension for a dll
import library is the same as for a static library because cmake refuses to
try to move the needle on this awful 'defacto' decision with respect to
msvc when it is exactly the sort of thing cmake should strive to take the
lead on creating this new standard here, in cooperation and discussion with
Microsoft (though for pure cmake based things it can be done without that).
.dll.lib vs .lib being the obvious extensions here.

FWIW mingw-w64 fixed this, and it was far from difficult. Here we use
.dll.a and .a.

I appeal to the CMake moderators to consider the damage this situation
causes to the genericness and hygiene of CMakeList.txt files.

On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> I know this has been asked before, but I've never seen a really
> authoritative answer.
>
> Say I have a simple single-library project.
>
> The advise I've seen is to not pass SHARED or STATIC to the
> add_library(..), but instead let the user pass
> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> or static.
>
> That's fine, but leads to packagers having to do ugly things like e.g:
>
>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>
> That is, do two separate configure/build/install, in order to get both
> a shared and static version. Note that the above was just an example.
> But many packagers do it like this.
>
> How can I make life easier for the packager?
>
> I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
> add_library(...), one with SHARED and one with STATIC, but the same
> input source files. I could give the two libraries different output
> filenames, as to not conflict on e.g. Windows (where I think the .lib
> import library containing symbols for the .dll would otherwise
> conflict with the static library .lib, or..?).
>
> To not have to repeat the list of sources, I could keep them in a
> variable. But that's not recommended in modern CMake AFAIK.
>
> I've also seen people add an object library, and then build the shared
> + static lib from that.
>
> What are your thoughts on all this? How do you go about it? Do you use
> the recommended way, with a single add_library(..) and just let
> packagers put up with having to do two builds?
>
> Thanks in advance!
> Elvis
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180519/ca3df0ba/attachment.html>

From elvis.stansvik at orexplore.com  Sat May 19 09:25:47 2018
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sat, 19 May 2018 15:25:47 +0200
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAOYw7dt2a_ZipifJRW5MGa2P4M1G-4OGVBjkXCwzeZ1Af-o-eQ@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CAOYw7dt2a_ZipifJRW5MGa2P4M1G-4OGVBjkXCwzeZ1Af-o-eQ@mail.gmail.com>
Message-ID: <CAE-7VJ=+s3fEzuh_WueK1bF8WxjMehBGNpH7gEMPwqtibrfTCQ@mail.gmail.com>

2018-05-19 15:09 GMT+02:00 Ray Donnelly <mingw.android at gmail.com>:
> And the situation is *far* worse on Windows where the extension for a dll
> import library is the same as for a static library because cmake refuses to
> try to move the needle on this awful 'defacto' decision with respect to msvc
> when it is exactly the sort of thing cmake should strive to take the lead on
> creating this new standard here, in cooperation and discussion with
> Microsoft (though for pure cmake based things it can be done without that).
> .dll.lib vs .lib being the obvious extensions here.
>
> FWIW mingw-w64 fixed this, and it was far from difficult. Here we use .dll.a
> and .a.
>
> I appeal to the CMake moderators to consider the damage this situation
> causes to the genericness and hygiene of CMakeList.txt files.

Right, that was the issue I alluded to when I said "I could give the
two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?)".

But I was mostly curious what people are doing when they wish to build
both static and shared, given what the situation is right now (or if
they simply refrain from doing that).

Elvis

>
> On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <elvis.stansvik at orexplore.com>
> wrote:
>>
>> I know this has been asked before, but I've never seen a really
>> authoritative answer.
>>
>> Say I have a simple single-library project.
>>
>> The advise I've seen is to not pass SHARED or STATIC to the
>> add_library(..), but instead let the user pass
>> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
>> or static.
>>
>> That's fine, but leads to packagers having to do ugly things like e.g:
>>
>>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>>
>> That is, do two separate configure/build/install, in order to get both
>> a shared and static version. Note that the above was just an example.
>> But many packagers do it like this.
>>
>> How can I make life easier for the packager?
>>
>> I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
>> add_library(...), one with SHARED and one with STATIC, but the same
>> input source files. I could give the two libraries different output
>> filenames, as to not conflict on e.g. Windows (where I think the .lib
>> import library containing symbols for the .dll would otherwise
>> conflict with the static library .lib, or..?).
>>
>> To not have to repeat the list of sources, I could keep them in a
>> variable. But that's not recommended in modern CMake AFAIK.
>>
>> I've also seen people add an object library, and then build the shared
>> + static lib from that.
>>
>> What are your thoughts on all this? How do you go about it? Do you use
>> the recommended way, with a single add_library(..) and just let
>> packagers put up with having to do two builds?
>>
>> Thanks in advance!
>> Elvis
>> --
>>
>> 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

From jbarrett at pivotal.io  Sat May 19 09:49:00 2018
From: jbarrett at pivotal.io (Jacob Barrett)
Date: Sat, 19 May 2018 06:49:00 -0700
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
Message-ID: <CAA1wVxrd1YVdh3RA+gWPso84EcjDxzJQOX4PDVEn19iUs=S95A@mail.gmail.com>

The Apache Geode Native [1] project needs to build both the shared, for
releasing, and the static, unit testing and embedding in mix-mode .NET
assembly. We tackled this by creating an INTERFACE library [2] that
contains the common elements of both shared and static then having SHARED
[3] and STATIC [4] libraries include the INTERFACE as a dependency. We also
put the static and shared library CMake files in separate directories so
that Cotire [5] would work.

 It isn't perfect but it works pretty good. The biggest downside is that
the INTERFACE target can't contain the sources. So at the parent CMake file
we jam all the sources in a variable for the children libraries to consume.
Something like this, details in the links below.

mylib/CMakeLists.txt:
add_library(INTERFACE _mylib)
target_link_libraries(_mylib INTERFACE Boost::Boost ...)
target_...(_mylib INTERFACE ...)
set(MYLIB_SOURCES mylib.hpp mylib.cpp ...)

mylib/shared/CMakeLists.txt:
add_library(mylib SHARED ${MYLIB_SOURCES})
target_link_libraries(mylib PRIVATE _mylib)

mylib/static/CMakeLists.txt:
add_library(mylib-static STATIC ${MYLIB_SOURCES})
target_link_libraries(mylib-static PUBLIC _mylib)
target_compile_definitions(mylib-static PUBLIC MYLIB_STATIC_DEFINE)

If you check out the links below for details please provide some feedback
on improvements we can make. There is lots of stuff going on in these files
to support Cotire and some platform differences we couldn't find a better
place to deal with. There is also some funkiness with include directories
that I haven't investigated fully.

Would love to hear that there is a better or modern way to attack this
problem.

[1] https://github.com/apache/geode-native
[2]
https://github.com/apache/geode-native/blob/develop/cppcache/CMakeLists.txt
[3]
https://github.com/apache/geode-native/blob/develop/cppcache/shared/CMakeLists.txt
[4]
https://github.com/apache/geode-native/blob/develop/cppcache/static/CMakeLists.txt
[5] https://github.com/sakra/cotire

-Jake

On Sat, May 19, 2018 at 6:00 AM Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> I know this has been asked before, but I've never seen a really
> authoritative answer.
>
> Say I have a simple single-library project.
>
> The advise I've seen is to not pass SHARED or STATIC to the
> add_library(..), but instead let the user pass
> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> or static.
>
> That's fine, but leads to packagers having to do ugly things like e.g:
>
>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>
> That is, do two separate configure/build/install, in order to get both
> a shared and static version. Note that the above was just an example.
> But many packagers do it like this.
>
> How can I make life easier for the packager?
>
> I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
> add_library(...), one with SHARED and one with STATIC, but the same
> input source files. I could give the two libraries different output
> filenames, as to not conflict on e.g. Windows (where I think the .lib
> import library containing symbols for the .dll would otherwise
> conflict with the static library .lib, or..?).
>
> To not have to repeat the list of sources, I could keep them in a
> variable. But that's not recommended in modern CMake AFAIK.
>
> I've also seen people add an object library, and then build the shared
> + static lib from that.
>
> What are your thoughts on all this? How do you go about it? Do you use
> the recommended way, with a single add_library(..) and just let
> packagers put up with having to do two builds?
>
> Thanks in advance!
> Elvis
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180519/5e5525ca/attachment-0001.html>

From smeenai at fb.com  Sat May 19 15:43:36 2018
From: smeenai at fb.com (Shoaib Meenai)
Date: Sat, 19 May 2018 19:43:36 +0000
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAOYw7dt2a_ZipifJRW5MGa2P4M1G-4OGVBjkXCwzeZ1Af-o-eQ@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CAOYw7dt2a_ZipifJRW5MGa2P4M1G-4OGVBjkXCwzeZ1Af-o-eQ@mail.gmail.com>
Message-ID: <7BD7A47B-3DB3-4D5B-8A34-7BA6ED49C39C@fb.com>

The convention in MSVC-land seems to be to prefix (as well as suffix) static libraries with lib. E.g. the static CRT is libcmt.lib, the static VC runtime support library is libvcruntime.lib (whereas the import library for the dynamic equivalent is vcruntime.lib), and so on. It isn't necessarily the greatest scheme, but it does provide some distinction, at least.

From: CMake <cmake-bounces at cmake.org> on behalf of Ray Donnelly <mingw.android at gmail.com>
Date: Saturday, May 19, 2018 at 6:10 AM
To: Elvis Stansvik <elvis.stansvik at orexplore.com>
Cc: CMake MailingList <cmake at cmake.org>
Subject: Re: [CMake] Approach to both shared and static lib (again, sorry)

And the situation is *far* worse on Windows where the extension for a dll import library is the same as for a static library because cmake refuses to try to move the needle on this awful 'defacto' decision with respect to msvc when it is exactly the sort of thing cmake should strive to take the lead on creating this new standard here, in cooperation and discussion with Microsoft (though for pure cmake based things it can be done without that). .dll.lib vs .lib being the obvious extensions here.

FWIW mingw-w64 fixed this, and it was far from difficult. Here we use .dll.a and .a.

I appeal to the CMake moderators to consider the damage this situation causes to the genericness and hygiene of CMakeList.txt files.

On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <elvis.stansvik at orexplore.com<mailto:elvis.stansvik at orexplore.com>> wrote:
I know this has been asked before, but I've never seen a really
authoritative answer.

Say I have a simple single-library project.

The advise I've seen is to not pass SHARED or STATIC to the
add_library(..), but instead let the user pass
-DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
or static.

That's fine, but leads to packagers having to do ugly things like e.g:

    https://salsa.debian.org/hle/dlib/blob/master/debian/rules<https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_hle_dlib_blob_master_debian_rules&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=R7JQmKVI2oxy-AIQVcBC-DX-dqlkBFk5kTCI222ecO8&e=>

That is, do two separate configure/build/install, in order to get both
a shared and static version. Note that the above was just an example.
But many packagers do it like this.

How can I make life easier for the packager?

I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
add_library(...), one with SHARED and one with STATIC, but the same
input source files. I could give the two libraries different output
filenames, as to not conflict on e.g. Windows (where I think the .lib
import library containing symbols for the .dll would otherwise
conflict with the static library .lib, or..?).

To not have to repeat the list of sources, I could keep them in a
variable. But that's not recommended in modern CMake AFAIK.

I've also seen people add an object library, and then build the shared
+ static lib from that.

What are your thoughts on all this? How do you go about it? Do you use
the recommended way, with a single add_library(..) and just let
packagers put up with having to do two builds?

Thanks in advance!
Elvis
--

Powered by www.kitware.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=V3mYr9Flf9Qf-Pq-_OovKbzrwVWhpIOrjcCHuYvbszk&e=>

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=sX26SQZVFYfGdhl4S0nVhXQDQ6eq_MhGXOy06ZAW9KQ&e=>

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=BWvA9Izw2G-XbRvZi9ptVgljjbJtkoRi_P7RuctYyTk&e=>
CMake Consulting: http://cmake.org/cmake/help/consulting.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=ouA_QmMRSZ16piM4G5xCtdJwt7Sz4fx_anknDStubYU&e=>
CMake Training Courses: http://cmake.org/cmake/help/training.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=qR0yZSqjFyaVr1xJpwSmtk28b-sMXtWDoM_URvLQs7A&e=>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=m2pcWM0TtqESkDz4KmjlV9a1VwfRPD2XaiR3Motzbxg&e=>

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake<https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=_fvbzMfoMh-elt7ju2Fetz2OTx7Z4TmCHGf7D6C4htE&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180519/a1089472/attachment.html>

From mateusz at loskot.net  Sat May 19 15:49:31 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Sat, 19 May 2018 21:49:31 +0200
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
Message-ID: <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>

On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com> wrote:
> I know this has been asked before, but I've never seen a really
> authoritative answer.
>
> Say I have a simple single-library project.
>
> The advise I've seen is to not pass SHARED or STATIC to the
> add_library(..), but instead let the user pass
> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> or static.
>
> That's fine, but leads to packagers having to do ugly things like e.g:
>
>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>
> That is, do two separate configure/build/install, in order to get both
> a shared and static version.

IMHO, there is nothing ugly in this approach.
Not every system allows (or recomments) to generate both,
static and shared, from the same object files.
Why not view static vs shared as the similar to 32 vs 64 bit?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From mingw.android at gmail.com  Sat May 19 16:16:55 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Sat, 19 May 2018 21:16:55 +0100
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
Message-ID: <CAOYw7dsXoSQ+YCjfdNh1QVJ_+a1+m1ZqpnPxd=2GvODoGmfLvg@mail.gmail.com>

On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <mateusz at loskot.net> wrote:

> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com>
> wrote:
> > I know this has been asked before, but I've never seen a really
> > authoritative answer.
> >
> > Say I have a simple single-library project.
> >
> > The advise I've seen is to not pass SHARED or STATIC to the
> > add_library(..), but instead let the user pass
> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> > or static.
> >
> > That's fine, but leads to packagers having to do ugly things like e.g:
> >
> >     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
> >
> > That is, do two separate configure/build/install, in order to get both
> > a shared and static version.
>
> IMHO, there is nothing ugly in this approach.
> Not every system allows (or recomments) to generate both,
> static and shared, from the same object files.
> Why not view static vs shared as the similar to 32 vs 64 bit?
>

Because they are different architectures that in many cases require
different compilers and in some cases different host machines to run on.
Static vs shared has none of these issues to contend with.

>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180519/d373753f/attachment.html>

From mingw.android at gmail.com  Sat May 19 16:23:41 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Sat, 19 May 2018 21:23:41 +0100
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <7BD7A47B-3DB3-4D5B-8A34-7BA6ED49C39C@fb.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CAOYw7dt2a_ZipifJRW5MGa2P4M1G-4OGVBjkXCwzeZ1Af-o-eQ@mail.gmail.com>
 <7BD7A47B-3DB3-4D5B-8A34-7BA6ED49C39C@fb.com>
Message-ID: <CAOYw7dskwOaRRVWms5DpG=x+bTY4-aQWEr3Xo+12bR-H-pKtXw@mail.gmail.com>

It most definitely is not. I work on a cross platform software distro that
includes many hundreds on libraries. There are 3 competing standards (4 if
you include mingw-w64):

lib prefix: ugly when the lib is already prefixed with lib.
-static.lib suffix.
.dll.lib vs .lib.

The point is cmake has defaults for this and they work on other platforms,
instead on Windows it ignores this and leaves the entire software
development would to deal with it instead.


On Sat, May 19, 2018, 8:43 PM Shoaib Meenai <smeenai at fb.com> wrote:

> The convention in MSVC-land seems to be to prefix (as well as suffix)
> static libraries with lib. E.g. the static CRT is libcmt.lib, the static VC
> runtime support library is libvcruntime.lib (whereas the import library for
> the dynamic equivalent is vcruntime.lib), and so on. It isn't necessarily
> the greatest scheme, but it does provide some distinction, at least.
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of Ray Donnelly <
> mingw.android at gmail.com>
> *Date: *Saturday, May 19, 2018 at 6:10 AM
> *To: *Elvis Stansvik <elvis.stansvik at orexplore.com>
> *Cc: *CMake MailingList <cmake at cmake.org>
> *Subject: *Re: [CMake] Approach to both shared and static lib (again,
> sorry)
>
>
>
> And the situation is *far* worse on Windows where the extension for a dll
> import library is the same as for a static library because cmake refuses to
> try to move the needle on this awful 'defacto' decision with respect to
> msvc when it is exactly the sort of thing cmake should strive to take the
> lead on creating this new standard here, in cooperation and discussion with
> Microsoft (though for pure cmake based things it can be done without that).
> .dll.lib vs .lib being the obvious extensions here.
>
>
>
> FWIW mingw-w64 fixed this, and it was far from difficult. Here we use
> .dll.a and .a.
>
>
>
> I appeal to the CMake moderators to consider the damage this situation
> causes to the genericness and hygiene of CMakeList.txt files.
>
>
>
> On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <elvis.stansvik at orexplore.com>
> wrote:
>
> I know this has been asked before, but I've never seen a really
> authoritative answer.
>
> Say I have a simple single-library project.
>
> The advise I've seen is to not pass SHARED or STATIC to the
> add_library(..), but instead let the user pass
> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> or static.
>
> That's fine, but leads to packagers having to do ugly things like e.g:
>
>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_hle_dlib_blob_master_debian_rules&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=R7JQmKVI2oxy-AIQVcBC-DX-dqlkBFk5kTCI222ecO8&e=>
>
> That is, do two separate configure/build/install, in order to get both
> a shared and static version. Note that the above was just an example.
> But many packagers do it like this.
>
> How can I make life easier for the packager?
>
> I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two
> add_library(...), one with SHARED and one with STATIC, but the same
> input source files. I could give the two libraries different output
> filenames, as to not conflict on e.g. Windows (where I think the .lib
> import library containing symbols for the .dll would otherwise
> conflict with the static library .lib, or..?).
>
> To not have to repeat the list of sources, I could keep them in a
> variable. But that's not recommended in modern CMake AFAIK.
>
> I've also seen people add an object library, and then build the shared
> + static lib from that.
>
> What are your thoughts on all this? How do you go about it? Do you use
> the recommended way, with a single add_library(..) and just let
> packagers put up with having to do two builds?
>
> Thanks in advance!
> Elvis
> --
>
> Powered by www.kitware.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=V3mYr9Flf9Qf-Pq-_OovKbzrwVWhpIOrjcCHuYvbszk&e=>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=sX26SQZVFYfGdhl4S0nVhXQDQ6eq_MhGXOy06ZAW9KQ&e=>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=BWvA9Izw2G-XbRvZi9ptVgljjbJtkoRi_P7RuctYyTk&e=>
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=ouA_QmMRSZ16piM4G5xCtdJwt7Sz4fx_anknDStubYU&e=>
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=qR0yZSqjFyaVr1xJpwSmtk28b-sMXtWDoM_URvLQs7A&e=>
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=m2pcWM0TtqESkDz4KmjlV9a1VwfRPD2XaiR3Motzbxg&e=>
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=_fvbzMfoMh-elt7ju2Fetz2OTx7Z4TmCHGf7D6C4htE&e=>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180519/66b80fd3/attachment.html>

From mateusz at loskot.net  Sat May 19 16:38:15 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Sat, 19 May 2018 22:38:15 +0200
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAOYw7dsXoSQ+YCjfdNh1QVJ_+a1+m1ZqpnPxd=2GvODoGmfLvg@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
 <CAOYw7dsXoSQ+YCjfdNh1QVJ_+a1+m1ZqpnPxd=2GvODoGmfLvg@mail.gmail.com>
Message-ID: <CABUeae-GVETWn4b76oiNRq-Lw9+YBNDJQVzOnJMZc+NVQpJ0MQ@mail.gmail.com>

On 19 May 2018 at 22:16, Ray Donnelly <mingw.android at gmail.com> wrote:
> On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <mateusz at loskot.net> wrote:
>> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com> wrote:
>> > I know this has been asked before, but I've never seen a really
>> > authoritative answer.
>> >
>> > Say I have a simple single-library project.
>> >
>> > The advise I've seen is to not pass SHARED or STATIC to the
>> > add_library(..), but instead let the user pass
>> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
>> > or static.
>> >
>> > That's fine, but leads to packagers having to do ugly things like e.g:
>> >
>> >     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>> >
>> > That is, do two separate configure/build/install, in order to get both
>> > a shared and static version.
>>
>> IMHO, there is nothing ugly in this approach.
>> Not every system allows (or recomments) to generate both,
>> static and shared, from the same object files.
>> Why not view static vs shared as the similar to 32 vs 64 bit?
>
>
> Because they are different architectures that in many cases require
> different compilers and in some cases different host machines to run on.
> Static vs shared has none of these issues to contend with.

Both, static and shared may use quite different compilation/linking,
that is enough to treat them differently.
Apparently, my point hasn't made it through. Nevermind.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From mingw.android at gmail.com  Sat May 19 16:54:10 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Sat, 19 May 2018 21:54:10 +0100
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CABUeae-GVETWn4b76oiNRq-Lw9+YBNDJQVzOnJMZc+NVQpJ0MQ@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
 <CAOYw7dsXoSQ+YCjfdNh1QVJ_+a1+m1ZqpnPxd=2GvODoGmfLvg@mail.gmail.com>
 <CABUeae-GVETWn4b76oiNRq-Lw9+YBNDJQVzOnJMZc+NVQpJ0MQ@mail.gmail.com>
Message-ID: <CAOYw7duOq0jpgT5pp3Bmrj7iZJGyc3j67+r3wfbZmQe2UBic4g@mail.gmail.com>

On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <mateusz at loskot.net> wrote:

> On 19 May 2018 at 22:16, Ray Donnelly <mingw.android at gmail.com> wrote:
> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <mateusz at loskot.net> wrote:
> >> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com>
> wrote:
> >> > I know this has been asked before, but I've never seen a really
> >> > authoritative answer.
> >> >
> >> > Say I have a simple single-library project.
> >> >
> >> > The advise I've seen is to not pass SHARED or STATIC to the
> >> > add_library(..), but instead let the user pass
> >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
> >> > or static.
> >> >
> >> > That's fine, but leads to packagers having to do ugly things like e.g:
> >> >
> >> >     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
> >> >
> >> > That is, do two separate configure/build/install, in order to get both
> >> > a shared and static version.
> >>
> >> IMHO, there is nothing ugly in this approach.
> >> Not every system allows (or recomments) to generate both,
> >> static and shared, from the same object files.
> >> Why not view static vs shared as the similar to 32 vs 64 bit?
> >
> >
> > Because they are different architectures that in many cases require
> > different compilers and in some cases different host machines to run on.
> > Static vs shared has none of these issues to contend with.
>
> Both, static and shared may use quite different compilation/linking,
> that is enough to treat them differently.
> Apparently, my point hasn't made it through. Nevermind.
>

Yes of course they do but the tooling in and around cmake (including things
like pkg-config and libtool) support this already. All I am pushing for is
for parity between the main 3 OSes here so that users of cmake do not have
to implement ugly hacks purely due to this.

>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180519/6f054af0/attachment.html>

From mateusz at loskot.net  Sat May 19 18:03:36 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Sun, 20 May 2018 00:03:36 +0200
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAOYw7duOq0jpgT5pp3Bmrj7iZJGyc3j67+r3wfbZmQe2UBic4g@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
 <CAOYw7dsXoSQ+YCjfdNh1QVJ_+a1+m1ZqpnPxd=2GvODoGmfLvg@mail.gmail.com>
 <CABUeae-GVETWn4b76oiNRq-Lw9+YBNDJQVzOnJMZc+NVQpJ0MQ@mail.gmail.com>
 <CAOYw7duOq0jpgT5pp3Bmrj7iZJGyc3j67+r3wfbZmQe2UBic4g@mail.gmail.com>
Message-ID: <CABUeae-LDfxCVvCd8z73BBvB3tfcQX6sqMMQMyqmV1J9aVmFGA@mail.gmail.com>

I understand your

Mateusz Loskot, mateusz at loskot.net
(Sent from mobile)

On Sat, 19 May 2018, 22:54 Ray Donnelly, <mingw.android at gmail.com> wrote:

> On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <mateusz at loskot.net> wrote:
>
>> On 19 May 2018 at 22:16, Ray Donnelly <mingw.android at gmail.com> wrote:
>> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <mateusz at loskot.net>
>> wrote:
>> >> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com>
>> wrote:
>> >> > I know this has been asked before, but I've never seen a really
>> >> > authoritative answer.
>> >> >
>> >> > Say I have a simple single-library project.
>> >> >
>> >> > The advise I've seen is to not pass SHARED or STATIC to the
>> >> > add_library(..), but instead let the user pass
>> >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
>> >> > or static.
>> >> >
>> >> > That's fine, but leads to packagers having to do ugly things like
>> e.g:
>> >> >
>> >> >     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>> >> >
>> >> > That is, do two separate configure/build/install, in order to get
>> both
>> >> > a shared and static version.
>> >>
>> >> IMHO, there is nothing ugly in this approach.
>> >> Not every system allows (or recomments) to generate both,
>> >> static and shared, from the same object files.
>> >> Why not view static vs shared as the similar to 32 vs 64 bit?
>> >
>> >
>> > Because they are different architectures that in many cases require
>> > different compilers and in some cases different host machines to run on.
>> > Static vs shared has none of these issues to contend with.
>>
>> Both, static and shared may use quite different compilation/linking,
>> that is enough to treat them differently.
>> Apparently, my point hasn't made it through. Nevermind.
>>
>
> Yes of course they do but the tooling in and around cmake (including
> things like pkg-config and libtool) support this already. All I am pushing
> for is for parity between the main 3 OSes here so that users of cmake do
> not have to implement ugly hacks purely due to this.
>


I understand. I just have learned to live with lacking of such parity in
CMake.
Look, CMake does not event abstract such a basic thing as filesystem
case-sensitivity, for example

find_package(protobuf)
vs
find_package(Protobuf)

The former won't work on OS witch case-sensitive filesystem.



Best regards,
Mateusz Loskot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180520/cda0b164/attachment.html>

From mateusz at loskot.net  Sat May 19 18:05:55 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Sun, 20 May 2018 00:05:55 +0200
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CABUeae-LDfxCVvCd8z73BBvB3tfcQX6sqMMQMyqmV1J9aVmFGA@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
 <CAOYw7dsXoSQ+YCjfdNh1QVJ_+a1+m1ZqpnPxd=2GvODoGmfLvg@mail.gmail.com>
 <CABUeae-GVETWn4b76oiNRq-Lw9+YBNDJQVzOnJMZc+NVQpJ0MQ@mail.gmail.com>
 <CAOYw7duOq0jpgT5pp3Bmrj7iZJGyc3j67+r3wfbZmQe2UBic4g@mail.gmail.com>
 <CABUeae-LDfxCVvCd8z73BBvB3tfcQX6sqMMQMyqmV1J9aVmFGA@mail.gmail.com>
Message-ID: <CABUeae-J+Yj-JjA=eSwxS_qMkGhpm4fZHuRPxf4Kzg6Y78+gbQ@mail.gmail.com>

Sorry for garbage in previous response.

I top posted partial response and bottom-posted more completed one.

Not easy to edit longish emails on mobile :)

Mateusz Loskot, mateusz at loskot.net
(Sent from mobile)

On Sun, 20 May 2018, 00:03 Mateusz Loskot, <mateusz at loskot.net> wrote:

> I understand your
>
> Mateusz Loskot, mateusz at loskot.net
> (Sent from mobile)
>
> On Sat, 19 May 2018, 22:54 Ray Donnelly, <mingw.android at gmail.com> wrote:
>
>> On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <mateusz at loskot.net> wrote:
>>
>>> On 19 May 2018 at 22:16, Ray Donnelly <mingw.android at gmail.com> wrote:
>>> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <mateusz at loskot.net>
>>> wrote:
>>> >> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com>
>>> wrote:
>>> >> > I know this has been asked before, but I've never seen a really
>>> >> > authoritative answer.
>>> >> >
>>> >> > Say I have a simple single-library project.
>>> >> >
>>> >> > The advise I've seen is to not pass SHARED or STATIC to the
>>> >> > add_library(..), but instead let the user pass
>>> >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either
>>> shared
>>> >> > or static.
>>> >> >
>>> >> > That's fine, but leads to packagers having to do ugly things like
>>> e.g:
>>> >> >
>>> >> >     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>>> >> >
>>> >> > That is, do two separate configure/build/install, in order to get
>>> both
>>> >> > a shared and static version.
>>> >>
>>> >> IMHO, there is nothing ugly in this approach.
>>> >> Not every system allows (or recomments) to generate both,
>>> >> static and shared, from the same object files.
>>> >> Why not view static vs shared as the similar to 32 vs 64 bit?
>>> >
>>> >
>>> > Because they are different architectures that in many cases require
>>> > different compilers and in some cases different host machines to run
>>> on.
>>> > Static vs shared has none of these issues to contend with.
>>>
>>> Both, static and shared may use quite different compilation/linking,
>>> that is enough to treat them differently.
>>> Apparently, my point hasn't made it through. Nevermind.
>>>
>>
>> Yes of course they do but the tooling in and around cmake (including
>> things like pkg-config and libtool) support this already. All I am pushing
>> for is for parity between the main 3 OSes here so that users of cmake do
>> not have to implement ugly hacks purely due to this.
>>
>
>
> I understand. I just have learned to live with lacking of such parity in
> CMake.
> Look, CMake does not event abstract such a basic thing as filesystem
> case-sensitivity, for example
>
> find_package(protobuf)
> vs
> find_package(Protobuf)
>
> The former won't work on OS witch case-sensitive filesystem.
>
>
>
> Best regards,
> Mateusz Loskot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180520/0f3a0fdf/attachment-0001.html>

From elvis.stansvik at orexplore.com  Sat May 19 18:55:14 2018
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 20 May 2018 00:55:14 +0200
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
Message-ID: <CAE-7VJkTKiavCAu3R-nZdQ1s4jUjhzUve_f56dTmF6ROkt=LbA@mail.gmail.com>

2018-05-19 21:49 GMT+02:00 Mateusz Loskot <mateusz at loskot.net>:
> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com> wrote:
>> I know this has been asked before, but I've never seen a really
>> authoritative answer.
>>
>> Say I have a simple single-library project.
>>
>> The advise I've seen is to not pass SHARED or STATIC to the
>> add_library(..), but instead let the user pass
>> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
>> or static.
>>
>> That's fine, but leads to packagers having to do ugly things like e.g:
>>
>>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>>
>> That is, do two separate configure/build/install, in order to get both
>> a shared and static version.
>
> IMHO, there is nothing ugly in this approach.
> Not every system allows (or recomments) to generate both,
> static and shared, from the same object files.

Alright. Yes I'm probably personally leaning towards just using the
recommended way, with a single add_library(..) and demand
reconfigure/rebuild/reinstall to get both variants. I was mostly
curious if you CMake pros on this list had some neat solution I hadn't
seen before.

Note that I wasn't necessarily suggesting building shared + static
from the same set of object files (which is indeed not recommended,
e.g. think of -fPIC), but just looking for best practices when having
CMake do the build of both libraries as part of the same build.

Elvis

> Why not view static vs shared as the similar to 32 vs 64 bit?
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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

From mingw.android at gmail.com  Sat May 19 22:19:38 2018
From: mingw.android at gmail.com (Ray Donnelly)
Date: Sun, 20 May 2018 03:19:38 +0100
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAE-7VJkTKiavCAu3R-nZdQ1s4jUjhzUve_f56dTmF6ROkt=LbA@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
 <CAE-7VJkTKiavCAu3R-nZdQ1s4jUjhzUve_f56dTmF6ROkt=LbA@mail.gmail.com>
Message-ID: <CAOYw7dv9KunP97+wF_aaKDdriSNAiqYMXO9AgSDB5HjSF+k8aQ@mail.gmail.com>

On Sat, May 19, 2018 at 11:55 PM, Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
> 2018-05-19 21:49 GMT+02:00 Mateusz Loskot <mateusz at loskot.net>:
>> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com> wrote:
>>> I know this has been asked before, but I've never seen a really
>>> authoritative answer.
>>>
>>> Say I have a simple single-library project.
>>>
>>> The advise I've seen is to not pass SHARED or STATIC to the
>>> add_library(..), but instead let the user pass
>>> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
>>> or static.
>>>
>>> That's fine, but leads to packagers having to do ugly things like e.g:
>>>
>>>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>>>
>>> That is, do two separate configure/build/install, in order to get both
>>> a shared and static version.
>>
>> IMHO, there is nothing ugly in this approach.
>> Not every system allows (or recomments) to generate both,
>> static and shared, from the same object files.
>
> Alright. Yes I'm probably personally leaning towards just using the
> recommended way, with a single add_library(..) and demand
> reconfigure/rebuild/reinstall to get both variants. I was mostly
> curious if you CMake pros on this list had some neat solution I hadn't
> seen before.
>
> Note that I wasn't necessarily suggesting building shared + static
> from the same set of object files (which is indeed not recommended,
> e.g. think of -fPIC),

Static libraries should be compiled with -fPIC on all systems that
support -fPIC. The reason for this is that you should not make
assumptions about the final target of the static library. There is no
reason it should be excluded from being linked into a shared library
or a ASLR capable executable. On Anaconda Distribution, everything is
compiled with -fPIC on Linux for this reason, and on macOS, -fPIC is
the only option and Windows has always been PIC or at least for as
long as I can remember.

but just looking for best practices when having
> CMake do the build of both libraries as part of the same build.
>
> Elvis
>
>> Why not view static vs shared as the similar to 32 vs 64 bit?
>>
>> Best regards,
>> --
>> Mateusz Loskot, http://mateusz.loskot.net
>> --
>>
>> 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

From elvis.stansvik at orexplore.com  Sun May 20 05:20:59 2018
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 20 May 2018 11:20:59 +0200
Subject: [CMake] Approach to both shared and static lib (again, sorry)
In-Reply-To: <CAOYw7dv9KunP97+wF_aaKDdriSNAiqYMXO9AgSDB5HjSF+k8aQ@mail.gmail.com>
References: <CAE-7VJnf5UDSPKdhN0WXWmJvz5GctB0LqKRw2sOX-gsyo7ZGNg@mail.gmail.com>
 <CABUeae-KAdjsqX0fQKLyf7ZN6TEG5-A1G1_B9Q4g_kKcT8AVAA@mail.gmail.com>
 <CAE-7VJkTKiavCAu3R-nZdQ1s4jUjhzUve_f56dTmF6ROkt=LbA@mail.gmail.com>
 <CAOYw7dv9KunP97+wF_aaKDdriSNAiqYMXO9AgSDB5HjSF+k8aQ@mail.gmail.com>
Message-ID: <CAE-7VJmb_6K6bv8dXdr+2afL1B9XykZnHb2JADRRk_yph8n8mw@mail.gmail.com>

2018-05-20 4:19 GMT+02:00 Ray Donnelly <mingw.android at gmail.com>:
> On Sat, May 19, 2018 at 11:55 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>> 2018-05-19 21:49 GMT+02:00 Mateusz Loskot <mateusz at loskot.net>:
>>> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stansvik at orexplore.com> wrote:
>>>> I know this has been asked before, but I've never seen a really
>>>> authoritative answer.
>>>>
>>>> Say I have a simple single-library project.
>>>>
>>>> The advise I've seen is to not pass SHARED or STATIC to the
>>>> add_library(..), but instead let the user pass
>>>> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared
>>>> or static.
>>>>
>>>> That's fine, but leads to packagers having to do ugly things like e.g:
>>>>
>>>>     https://salsa.debian.org/hle/dlib/blob/master/debian/rules
>>>>
>>>> That is, do two separate configure/build/install, in order to get both
>>>> a shared and static version.
>>>
>>> IMHO, there is nothing ugly in this approach.
>>> Not every system allows (or recomments) to generate both,
>>> static and shared, from the same object files.
>>
>> Alright. Yes I'm probably personally leaning towards just using the
>> recommended way, with a single add_library(..) and demand
>> reconfigure/rebuild/reinstall to get both variants. I was mostly
>> curious if you CMake pros on this list had some neat solution I hadn't
>> seen before.
>>
>> Note that I wasn't necessarily suggesting building shared + static
>> from the same set of object files (which is indeed not recommended,
>> e.g. think of -fPIC),
>
> Static libraries should be compiled with -fPIC on all systems that
> support -fPIC. The reason for this is that you should not make
> assumptions about the final target of the static library. There is no
> reason it should be excluded from being linked into a shared library
> or a ASLR capable executable. On Anaconda Distribution, everything is
> compiled with -fPIC on Linux for this reason, and on macOS, -fPIC is
> the only option and Windows has always been PIC or at least for as
> long as I can remember.

Alright, this was some good bit of info, since I had mostly seen "PIC
unnecessarily hurts performance for static libs" kind of advice out
there.

Thinking about it, in my case, even if PIC did hurt performance a bit,
I don't think it's much enough that I should care, for my use case at
least.

So, with that in mind, is anyone doing this:

- Build an object library (with POSITION_INDEPENDENT_CODE)
- Build a static library from the object library
- Build a shared library from the object library

? Any downsides/gotchas with this approach?

The upsides I see are:

1. Sources are compiled once, and the result linked twice.
2. No need for a variable to hold the list of sources.

Time savings of 1 may be negligible though, if linking is the lion
share of the time (my project is tiny though, so I'm not concerned
about build time savings).

Elvis

>
> but just looking for best practices when having
>> CMake do the build of both libraries as part of the same build.
>>
>> Elvis
>>
>>> Why not view static vs shared as the similar to 32 vs 64 bit?
>>>
>>> Best regards,
>>> --
>>> Mateusz Loskot, http://mateusz.loskot.net
>>> --
>>>
>>> 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

From larsch at belunktum.dk  Sun May 20 07:07:09 2018
From: larsch at belunktum.dk (Lars Christensen)
Date: Sun, 20 May 2018 13:07:09 +0200
Subject: [CMake] Detecting compilation option and flags
Message-ID: <CAH2Uiq=oTehFC6QpevK4QKh96tA+M5AXi2wFBnEgW5P2V0eToA@mail.gmail.com>

I rely on these to detect options and flags:

$<TARGET_PROPERTY:${_target},COMPILE_FLAGS>
$<TARGET_PROPERTY:${_target},COMPILE_OPTIONS>

But not all options are picked up. These are missing:

1. Debug flag (when CMAKE_BUILD_TYPE=Debug)
2. -std=xx (CMAKE_CXX_STANDARD)

How can I reliably detect ALL compilation flags for a target?

Picking up these two flags is required for my pre-compiled header cmake
hack[1]. It used to work OK. I guess Debug can be detected and picked up
from _FLAGS_DEBUG, but I don't see a way to pick up -std=.

Lars

1) https://github.com/larsch/cmake-precompiled-header/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180520/68d69b6b/attachment.html>

From shawn0245 at gmail.com  Sun May 20 20:11:13 2018
From: shawn0245 at gmail.com (Shawn G)
Date: Mon, 21 May 2018 08:11:13 +0800
Subject: [CMake] CMake on Raspberry Pi
Message-ID: <CANjKi-e-1o4hiwY=7WtkEpCaMY7A70W8qnoTZZRiQkjGd+bW2Q@mail.gmail.com>

 Hi there, im having some troubles installing CMake on raspberry pi 3
running raspbian stretch.
I keep getting this error message when i run the command "sudo apt-get
install build-essential cmake pkg-config"
The error message:
" Reading package lists... Done
Building dependency tree
Reading state information... Done
Package CMake is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'cmake' has no installation candidate "

I've tried other installation methods like "pip install cmake" & "sudo
apt-get install -y cmake" but all to no avail. Could you guys help me out?
Is there a library i can extract from?

Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180521/2affc75a/attachment.html>

From haocheng.liu at kitware.com  Sun May 20 20:34:58 2018
From: haocheng.liu at kitware.com (Haocheng Liu)
Date: Sun, 20 May 2018 20:34:58 -0400
Subject: [CMake] CMake on Raspberry Pi
In-Reply-To: <CANjKi-e-1o4hiwY=7WtkEpCaMY7A70W8qnoTZZRiQkjGd+bW2Q@mail.gmail.com>
References: <CANjKi-e-1o4hiwY=7WtkEpCaMY7A70W8qnoTZZRiQkjGd+bW2Q@mail.gmail.com>
Message-ID: <CACbTE7NARoTGV_wDf1wc3bLfUNJwm_jt=Xrm_N-a_wy7EcOBcw@mail.gmail.com>

Hi Shawn,

On Sun, May 20, 2018 at 8:11 PM, Shawn G <shawn0245 at gmail.com> wrote:

> Hi there, im having some troubles installing CMake on raspberry pi 3
> running raspbian stretch.
> I keep getting this error message when i run the command "sudo apt-get
> install build-essential cmake pkg-config"
> The error message:
> " Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package CMake is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'cmake' has no installation candidate "
>
> I've tried other installation methods like "pip install cmake" & "sudo
> apt-get install -y cmake" but all to no avail. Could you guys help me out?
> Is there a library i can extract from?
>
> A better question might be want kind of OS are you running on your
raspberry Pi? I used to use the same command to install cmake on RASPBIAN 9
and it installs CMake 3.7.2 fine.

> Thank you in advance.
>
> --
>
> 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
>
>


-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180520/b2aa9d76/attachment-0001.html>

From andi at lisas.de  Mon May 21 01:26:53 2018
From: andi at lisas.de (Andreas Mohr)
Date: Mon, 21 May 2018 07:26:53 +0200
Subject: [CMake] CMake on Raspberry Pi
In-Reply-To: <CANjKi-e-1o4hiwY=7WtkEpCaMY7A70W8qnoTZZRiQkjGd+bW2Q@mail.gmail.com>
Message-ID: <20180521052653.GB28105@rhlx01.hs-esslingen.de>

Hi,

On Sun, May 20, 2018 at 08:35:31PM -0400, cmake-request at cmake.org wrote:
> Date: Mon, 21 May 2018 08:11:13 +0800
> From: Shawn G <shawn0245 at gmail.com>

>  Hi there, im having some troubles installing CMake on raspberry pi 3
> running raspbian stretch.
> I keep getting this error message when i run the command "sudo apt-get
> install build-essential cmake pkg-config"
> The error message:
> " Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package CMake is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> 
> E: Package 'cmake' has no installation candidate "

# apt-cache policy cmake
cmake:
  Installed: 3.7.2-1
  Candidate: 3.7.2-1
  Version table:
 *** 3.7.2-1 500
        500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages
        100 /var/lib/dpkg/status

(possibly your /etc/apt/sources* setup does not have
working/updated info for stretch/main repo?)

HTH,

Andreas Mohr

-- 
Das "S" in "IoT" steht f?r "Security"
[Signatur von betateilchen:
https://forum.fhem.de/index.php/topic,23008.msg163661.html#msg163661 ]

From mateusz at loskot.net  Mon May 21 13:39:16 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Mon, 21 May 2018 19:39:16 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to upstream
Message-ID: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>

Hi,

I've been recently trying to update/add Find-modules to CMake:
updated FindJPEG, proposed FindODBC and most recently FindLZ4.

Discussion during review of the FindLZ4 [1] ended with some surprising
conclusions which I, as someone who relies on CMake and occacionally
contributes to CMake, don't necessarily agree with.
I'd like to share some of my thoughts.

[1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_412640

A bit of a extract from the brief discussion [1]:

The FindLZ4 discussion basically ended with suggestion from Brad that,
instead of adding Find-module to CMake, I should approach LZ4 project
and add Config-file to the library itself.
Then I argued taht Config-files are more complex and I don't feel like
asking projects, which I don't maintain myself, to accept the extra complexity.
Finally, Brad replied that CMake doesn't need LZ4 itself and yet for some
reason is expected to know all about it: versions, headers, libraries, etc.
and that it's not scalable to teach CMake about every project in the world.

This opinion does not surprise me and I understand the rationale.
I argue that CMake does need to know about every project in the world,
or every project that CMake users wish to use, directly or indirectly.
Without the knowledge CMake would simply be useless.

I understand CMake maintainers try to shift the responsibility of recognising
"every project in the world" away from the CMake itself as not scalable.
Good approach to avoid need to scale up the maintenance efforts,
but that is a bad news for CMake users.

As a CMake user, I expect to be able to install CMake and get my dependencies
recognised by CMake as CMake's responsibility
I do not want to care if library A which I depend on is actually
CMake-ignorant or not.
I do not want to learn why library A does not support CMake, as often that is
philosopical reason and asking about it ends up with a rough responses.
(Imagine, there are libraries on GitHub which maintainers do not accept
addition of ***non-intrusive*** single .travis.yml file, because they
don't trust it.)
If a library is strictly GNU Autoconf, I'm on lost position trying to convince
maitnainers to accept CMake stuff and even if they do, they won't be willing to
maintain it - broken Config-files may be deployed with new packages.
That puts users of CMake and such library on lost position:
CMake says no to Find-module, the library does not care either.

As CMake user I don't want to be left to the discretion of package maintainers.
Packages may ignore CMake Config-file existence.
Packages of libraries which provide CMake and alternative build configurations
may not deploy Config-files or Find-modules.

IMHO, CMake should encourage contributions of new Find-modules.

It does not contradict with the recommendation that Config-files
should be preferred.
Once a library that used to be searchable only via Find-module only receives
Config-file, both approaches still can be available, no reason to
remove the Find-module.
The CMake's policy of preferring Config-file can still apply, there is no clash,
it is just users now have choice.
If a Find-module becomes outdated, it doesn't break anything else in CMake
ecosystem but can be spotted and potential contributor may arrive with a fix.

I want to contribute Find-module into a **central place** where I can easily
access it as well as monitor its state and submit fixes if necessary.
>From a contributor POV, that is much more effective than jumping between
variety of issue trackers, creating new accounts for one time use or even
sending patches via e-mails to maitnainers - not everything lives in GitHub yet.

Since CMake is still de-facto a standard for building C++ software,
from end-user POV the current situation feels almost like vendor lock-in.

I call CMake to accept *any* Find-module, filtering only based on
quality of CMake
idiomatic scripting.

If CMake does not want Find-* modules within the source tree, then
- set up https://gitlab.kitware.com/cmake/find-modules
- move all existing Find-modules in there
- relax maintenance rules to accept *any* Find-module, provided
--- CMake scripting is decent quality (e.g no community downvotes or rejecting
     reviews for period of quarantine)
--- CI passing tests
- finally, include the complete find-modules archive in the installer
so it is deployed
   aside of CMake itself

If CMake does not care about Find-modules, it should not care or
should care about
them equally - thus presence of such find-modules archive deployed should
not affect the health of CMake installation and its pursue fo
rFind-modules ignorance.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From ewmailing at gmail.com  Mon May 21 23:24:38 2018
From: ewmailing at gmail.com (Eric Wing)
Date: Mon, 21 May 2018 20:24:38 -0700
Subject: [CMake] CMake on Raspberry Pi
In-Reply-To: <CANjKi-e-1o4hiwY=7WtkEpCaMY7A70W8qnoTZZRiQkjGd+bW2Q@mail.gmail.com>
References: <CANjKi-e-1o4hiwY=7WtkEpCaMY7A70W8qnoTZZRiQkjGd+bW2Q@mail.gmail.com>
Message-ID: <CA+Q62MDq-Hj_VRNn2wYzn1AmS5227jdRTyf+yzbyTpCV=Y2sLg@mail.gmail.com>

On 5/20/18, Shawn G <shawn0245 at gmail.com> wrote:
>  Hi there, im having some troubles installing CMake on raspberry pi 3
> running raspbian stretch.
> I keep getting this error message when i run the command "sudo apt-get
> install build-essential cmake pkg-config"
> The error message:
> " Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package CMake is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'cmake' has no installation candidate "
>
> I've tried other installation methods like "pip install cmake" & "sudo
> apt-get install -y cmake" but all to no avail. Could you guys help me out?
> Is there a library i can extract from?
>
> Thank you in advance.
>

Try running:
sudo apt-get update

Then try again, i.e.
sudo apt-get install cmake

From josp.jorge at gmail.com  Tue May 22 03:26:52 2018
From: josp.jorge at gmail.com (Jorge Perez)
Date: Tue, 22 May 2018 09:26:52 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
Message-ID: <CAM2LniFhS_Df=FCz9NsxXd9Pdg6M9VYrZjpi=FWMXx7bkCrKkA@mail.gmail.com>

+1 to the gitlab central repository

On Mon, 21 May 2018 at 19:39, Mateusz Loskot <mateusz at loskot.net> wrote:

> Hi,
>
> I've been recently trying to update/add Find-modules to CMake:
> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
>
> Discussion during review of the FindLZ4 [1] ended with some surprising
> conclusions which I, as someone who relies on CMake and occacionally
> contributes to CMake, don't necessarily agree with.
> I'd like to share some of my thoughts.
>
> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_412640
>
> A bit of a extract from the brief discussion [1]:
>
> The FindLZ4 discussion basically ended with suggestion from Brad that,
> instead of adding Find-module to CMake, I should approach LZ4 project
> and add Config-file to the library itself.
> Then I argued taht Config-files are more complex and I don't feel like
> asking projects, which I don't maintain myself, to accept the extra
> complexity.
> Finally, Brad replied that CMake doesn't need LZ4 itself and yet for some
> reason is expected to know all about it: versions, headers, libraries, etc.
> and that it's not scalable to teach CMake about every project in the world.
>
> This opinion does not surprise me and I understand the rationale.
> I argue that CMake does need to know about every project in the world,
> or every project that CMake users wish to use, directly or indirectly.
> Without the knowledge CMake would simply be useless.
>
> I understand CMake maintainers try to shift the responsibility of
> recognising
> "every project in the world" away from the CMake itself as not scalable.
> Good approach to avoid need to scale up the maintenance efforts,
> but that is a bad news for CMake users.
>
> As a CMake user, I expect to be able to install CMake and get my
> dependencies
> recognised by CMake as CMake's responsibility
> I do not want to care if library A which I depend on is actually
> CMake-ignorant or not.
> I do not want to learn why library A does not support CMake, as often that
> is
> philosopical reason and asking about it ends up with a rough responses.
> (Imagine, there are libraries on GitHub which maintainers do not accept
> addition of ***non-intrusive*** single .travis.yml file, because they
> don't trust it.)
> If a library is strictly GNU Autoconf, I'm on lost position trying to
> convince
> maitnainers to accept CMake stuff and even if they do, they won't be
> willing to
> maintain it - broken Config-files may be deployed with new packages.
> That puts users of CMake and such library on lost position:
> CMake says no to Find-module, the library does not care either.
>
> As CMake user I don't want to be left to the discretion of package
> maintainers.
> Packages may ignore CMake Config-file existence.
> Packages of libraries which provide CMake and alternative build
> configurations
> may not deploy Config-files or Find-modules.
>
> IMHO, CMake should encourage contributions of new Find-modules.
>
> It does not contradict with the recommendation that Config-files
> should be preferred.
> Once a library that used to be searchable only via Find-module only
> receives
> Config-file, both approaches still can be available, no reason to
> remove the Find-module.
> The CMake's policy of preferring Config-file can still apply, there is no
> clash,
> it is just users now have choice.
> If a Find-module becomes outdated, it doesn't break anything else in CMake
> ecosystem but can be spotted and potential contributor may arrive with a
> fix.
>
> I want to contribute Find-module into a **central place** where I can
> easily
> access it as well as monitor its state and submit fixes if necessary.
> From a contributor POV, that is much more effective than jumping between
> variety of issue trackers, creating new accounts for one time use or even
> sending patches via e-mails to maitnainers - not everything lives in
> GitHub yet.
>
> Since CMake is still de-facto a standard for building C++ software,
> from end-user POV the current situation feels almost like vendor lock-in.
>
> I call CMake to accept *any* Find-module, filtering only based on
> quality of CMake
> idiomatic scripting.
>
> If CMake does not want Find-* modules within the source tree, then
> - set up https://gitlab.kitware.com/cmake/find-modules
> - move all existing Find-modules in there
> - relax maintenance rules to accept *any* Find-module, provided
> --- CMake scripting is decent quality (e.g no community downvotes or
> rejecting
>      reviews for period of quarantine)
> --- CI passing tests
> - finally, include the complete find-modules archive in the installer
> so it is deployed
>    aside of CMake itself
>
> If CMake does not care about Find-modules, it should not care or
> should care about
> them equally - thus presence of such find-modules archive deployed should
> not affect the health of CMake installation and its pursue fo
> rFind-modules ignorance.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180522/d80357c1/attachment.html>

From johannes.zarl-zierl at jku.at  Tue May 22 06:27:22 2018
From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl)
Date: Tue, 22 May 2018 12:27:22 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
Message-ID: <1893894.FklTHkCckZ@ersa>

Hi Mateusz,

On Montag, 21. Mai 2018 19:39:16 CEST Mateusz Loskot wrote:
> The FindLZ4 discussion basically ended with suggestion from Brad that,
> instead of adding Find-module to CMake, I should approach LZ4 project
> and add Config-file to the library itself.
> Then I argued taht Config-files are more complex and I don't feel like
> asking projects, which I don't maintain myself, to accept the extra
> complexity

There's more that we (as CMake community) could do to make it easier for non-
cmake projects to add a config file, and I think this is a worthwhile goal.

Currently, if the maintainer of an autotools-based project is willing to add a 
cmake config file, he or she basically needs to be an expert on cmake. There's 
no official template or guide on how to create a cmake config file without relying 
on a cmake module to do the work.

If there was a good guide, or maybe even some tooling, cmake config files would 
not be much more work for the maintainer as pkg-config files.

> I call CMake to accept *any* Find-module, filtering only based on
> quality of CMake
> idiomatic scripting.

"Filtering based on quality" being the important part.

> If CMake does not want Find-* modules within the source tree, then
> - set up https://gitlab.kitware.com/cmake/find-modules
> - move all existing Find-modules in there
> - relax maintenance rules to accept *any* Find-module, provided
> --- CMake scripting is decent quality (e.g no community downvotes or
> rejecting reviews for period of quarantine)
> --- CI passing tests
> - finally, include the complete find-modules archive in the installer
> so it is deployed
>    aside of CMake itself

That seems like a reasonable way to deal with the situation. Maybe this would 
also encourage better quality of the (current) core find-modules. If you take a 
look at those, they are in wildly different shape regarding their quality.

> If CMake does not care about Find-modules, it should not care or
> should care about
> them equally

ACK.

Cheers,
  Johannes


From rleigh at codelibre.net  Tue May 22 07:36:13 2018
From: rleigh at codelibre.net (rleigh at codelibre.net)
Date: Tue, 22 May 2018 12:36:13 +0100
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
Message-ID: <1bf883c890fddaa0069871dc913ce5b4@codelibre.net>

On 2018-05-21 18:39, Mateusz Loskot wrote:
> I've been recently trying to update/add Find-modules to CMake:
> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
[?]
> The FindLZ4 discussion basically ended with suggestion from Brad that,
> instead of adding Find-module to CMake, I should approach LZ4 project
> and add Config-file to the library itself.
> Then I argued taht Config-files are more complex and I don't feel like
> asking projects, which I don't maintain myself, to accept the extra 
> complexity.
> Finally, Brad replied that CMake doesn't need LZ4 itself and yet for 
> some
> reason is expected to know all about it: versions, headers, libraries, 
> etc.
> and that it's not scalable to teach CMake about every project in the 
> world.

It really doesn't scale.  I've contributed and provided ongoing fixes 
for a few Find modules out of practical necessity, for projects which 
are effectively incapable of adding a Config-file, either because the 
project was stagnant with no new releases (Xerces, Xalan), or where the 
project was so complex that it was effectively impossible to add 
(Boost).  However, that work should have been done by the upstream.  The 
ongoing maintenance cost has been moved from the upstream development, 
where it belongs, to a volunteer (me).  It's work which I do because it 
provides value to me and my employer so I can use CMake with the 
projects I work on, but is otherwise unjustifiable.  You simply can't 
expect every Find module to keep pace with upstream development without 
a small army of volunteers to keep them all up to date.  If they are 
provided with the upstream releases, they are de facto always up to date 
because they are directly matched to the library.

Note that for several of these projects (e.g. Xerces, libtiff), I have 
actually provided upstream CMake build systems which install 
Config-files, so in the future the Find modules can be deprecated and 
users can move to the Config-file as these releases make their way into 
distributions.  That's semi-altruistic.  I've spent a lot of effort up 
front to make CMake infrastructure in these projects maintainable for 
the long term, and something which can be delegated to others for 
ongoing maintenance.

> This opinion does not surprise me and I understand the rationale.
> I argue that CMake does need to know about every project in the world,
> or every project that CMake users wish to use, directly or indirectly.
> Without the knowledge CMake would simply be useless.

Not useless, that's going a bit far.  It's requiring a little bit of 
extra work to be functional.  For libraries without Find modules, you 
can usually write your own in a couple of dozen lines.  At that point 
your options are:

- to upstream it as a Config-file template to the upstream developers
- to maintain it independently in your project
- to upstream it to cmake.git

Depending upon the library in question, I've done all three at various 
times.

> As a CMake user, I expect to be able to install CMake and get my 
> dependencies
> recognised by CMake as CMake's responsibility

> If a library is strictly GNU Autoconf, I'm on lost position trying to 
> convince
> maitnainers to accept CMake stuff and even if they do, they won't be 
> willing to
> maintain it - broken Config-files may be deployed with new packages.
> That puts users of CMake and such library on lost position:
> CMake says no to Find-module, the library does not care either.

If it's using Autoconf, then it can still provide and install CMake 
configuration files.  It can use @var@ substitutions in the 
Config-file.in template and then install it.  Just like for pkg-config 
templates.

Individual projects may have their own policies, and some might not want 
to have CMake support.  In general though, if you were to provide a 
tested patch that creates the Config-file in AC_OUTPUT and then install 
as e.g. cmake_pkgconfig_DATA in Makefile.am, add a distcheck hook and/or 
CI logic to test it, and most projects are in my experience willing to 
accept the patch.  The only way to find out is to create and submit the 
patch, and have a conversation with them about the cost/benefit of 
including it.  Some might be worried about the maintenance burden, so 
explain the value of it and maybe commit to maintaining it as required.  
Since you'd likely be maintaining it /anyway/, it's not a big task.

> As CMake user I don't want to be left to the discretion of package 
> maintainers.
> Packages may ignore CMake Config-file existence.
> Packages of libraries which provide CMake and alternative build 
> configurations
> may not deploy Config-files or Find-modules.
> 
> IMHO, CMake should encourage contributions of new Find-modules.

As with all things, in my opinion this really comes down to these 
questions: "who is going to do the work", and "who is paying for their 
time".  Contribution also has implied ongoing maintenance obligations.  
If Find modules are contributed and then not maintained, they will 
become broken over time, and who will be expected to keep them updated?  
The CMake core maintainers?  The submitter?  Users who need it?  If it's 
upstreamed, it's much less of a liability.  For the stuff I've 
contributed, it's mostly been done on my paid work time because it has 
value for the work projects, enabling easy building and testing on a 
large range of platforms for both our developers and end users.  But 
when I move onto new projects or a new job, I'll find it difficult to 
justify doing this in my spare time, as much as I might like to.  If you 
take a look at the bug list for e.g. FindBoost, there are a lot of open 
issues, but it's so huge and complex that I don't have the resources 
(different systems) to address all of the defects--that requires 
contributions from the people who can actually test these systems I 
can't.  The huge complexity here squarely belongs upstream.  FindBoost 
is one of the more complex modules, and I can fully sympathise with the 
desire to avoid more of these maintenance nightmares.  It's already a 
large burden upon both people like me, and I suspect also the CMake core 
maintainers in creating, testing and reviewing changes for every Boost 
release and for every platform it's expected to run on.  Multiply that 
by the total number of Find modules (approximately 150 at present).

One thing I do think could be improved is the behaviour of find_package 
and MODULE|NO_MODULE|CONFIG.  In order to allow more transparent 
migration from Find modules to Config-files it would be nice if in the 
absence of any of these flags, it would firstly try the Config-file and 
if it was missing, then fall back to a Find module.  This might have 
some compatibility concerns.  However, if the long term goal is to move 
away from Find modules, then a means of transitioning like this would be 
desirable.  Otherwise, doing this manually in the Find module itself 
might be required.


Regards,
Roger

From brad.king at kitware.com  Tue May 22 11:13:18 2018
From: brad.king at kitware.com (Brad King)
Date: Tue, 22 May 2018 11:13:18 -0400
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <1893894.FklTHkCckZ@ersa>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa>
Message-ID: <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>

On 05/22/2018 06:27 AM, Johannes Zarl-Zierl wrote:
> There's more that we (as CMake community) could do to make it easier for non-
> cmake projects to add a config file...
[snip]
> not be much more work for the maintainer as pkg-config files.

There is a proposal here:

  https://mwoehlke.github.io/cps/

for a new package specification format to supersede both CMake
package configuration files and pkg-config .pc files with something
sufficient for both use cases.  The "History" section documents
the limitations of both existing approaches and why neither is
sufficient on its own.

Both pkg-config and CMake's find_package command could use the
proposed `.cps` files.  Projects would only have to provide one
kind of spec file that is buildsystem agnostic.

-Brad

From sergey.nikulov at gmail.com  Tue May 22 11:21:19 2018
From: sergey.nikulov at gmail.com (Sergei Nikulov)
Date: Tue, 22 May 2018 18:21:19 +0300
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
Message-ID: <CAE7Ac0Bt5_Z05y128PSy24qVZhzmjbxbKRcU5hVfTyH_sYWnsQ@mail.gmail.com>

??, 22 ??? 2018 ?. ? 18:13, Brad King <brad.king at kitware.com>:

> On 05/22/2018 06:27 AM, Johannes Zarl-Zierl wrote:
> > There's more that we (as CMake community) could do to make it easier
for non-
> > cmake projects to add a config file...
> [snip]
> > not be much more work for the maintainer as pkg-config files.

> There is a proposal here:

>    https://mwoehlke.github.io/cps/

> for a new package specification format to supersede both CMake
> package configuration files and pkg-config .pc files with something
> sufficient for both use cases.  The "History" section documents
> the limitations of both existing approaches and why neither is
> sufficient on its own.

> Both pkg-config and CMake's find_package command could use the
> proposed `.cps` files.  Projects would only have to provide one
> kind of spec file that is buildsystem agnostic.


Hello, Brad.

When will CMake with cps support be available?

> -Brad
> --


-- 
Best Regards,
Sergei Nikulov

From brad.king at kitware.com  Tue May 22 11:24:56 2018
From: brad.king at kitware.com (Brad King)
Date: Tue, 22 May 2018 11:24:56 -0400
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <CAE7Ac0Bt5_Z05y128PSy24qVZhzmjbxbKRcU5hVfTyH_sYWnsQ@mail.gmail.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <CAE7Ac0Bt5_Z05y128PSy24qVZhzmjbxbKRcU5hVfTyH_sYWnsQ@mail.gmail.com>
Message-ID: <171022a1-6c47-8acd-8449-5b08c77bcd53@kitware.com>

On 05/22/2018 11:21 AM, Sergei Nikulov wrote:
>>    https://mwoehlke.github.io/cps/
> 
> When will CMake with cps support be available?

The work is still in the design phase of the CPS format itself.
I've added its author in Cc.

-Brad

From mateusz at loskot.net  Tue May 22 16:53:06 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Tue, 22 May 2018 22:53:06 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <1893894.FklTHkCckZ@ersa>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa>
Message-ID: <CABUeae9Ef0c_LVMwN-gNye=tYnRGEgLLn3SG9vyFj_obwng7qw@mail.gmail.com>

On 22 May 2018 at 12:27, Johannes Zarl-Zierl <johannes.zarl-zierl at jku.at> wrote:
> On Montag, 21. Mai 2018 19:39:16 CEST Mateusz Loskot wrote:
>> The FindLZ4 discussion basically ended with suggestion from Brad that,
>> instead of adding Find-module to CMake, I should approach LZ4 project
>> and add Config-file to the library itself.
>> Then I argued taht Config-files are more complex and I don't feel like
>> asking projects, which I don't maintain myself, to accept the extra
>> complexity
>
> There's more that we (as CMake community) could do to make it easier for non-
> cmake projects to add a config file, and I think this is a worthwhile goal.
>
> Currently, if the maintainer of an autotools-based project is willing to add a
> cmake config file, he or she basically needs to be an expert on cmake. There's
> no official template or guide on how to create a cmake config file without relying
> on a cmake module to do the work.

Hi Johannes,

I can onl agree.
In fact, I called the Config-files approach complex partially due to lack of
easy to follow tutorial.
Partially due to beign too lazy to figure step-by-step procedure from
https://cmake.org/cmake/help/v3.11/manual/cmake-packages.7.html

> If there was a good guide, or maybe even some tooling, cmake config files would
> not be much more work for the maintainer as pkg-config files.

This should be no-brainer.
This should be no-brainer to such extend that for cases of canonical
configurations
CMake should generate all the required *-{config|version}.cmake
And, the CMake documentation should tell what to do, how to fix my
CMakeLists.txt
to make help CMake generate all the files.

>> I call CMake to accept *any* Find-module, filtering only based on
>> quality of CMake
>> idiomatic scripting.
>
> "Filtering based on quality" being the important part.

Idiomatic quality of CMake scripts is very important.
I've seen enough cases of CMake scripting abuse to finally
strive for some linting reflex and must-obey conentions.

Very recently, I've proposed FindODBC
https://gitlab.kitware.com/cmake/cmake/merge_requests/2069
A trivial script one may think, but look at number of review-refine iterations
it too me to improve it (acceptance is still pending).

Here, I would like to thank Brad King a ton.
He's patience to review, suggest where and how to improve
every tiniest detail is priceless.
Have a look at the discussion comments for the MR 2069,
learning outcome from that MR alone makes a substantial
CMake coding guide to me.
I do realise such help consumes a lot of Brad's time  and
I do realise it might be one of reasons CMake may prefer to
avoid such heavy engagement of maintainers by 'outsource'
libraries look-up responsibility.
But, perhaps an easier solution would be to move things and relax requiremnets.

    Il meglio ? nemico del bene

I wish there was an official CMake coding guide.
(I'm hoping to collect my experience based on reviews of my
MR-s to FindJPEG, FindODBC and FindLZ4).

>> If CMake does not want Find-* modules within the source tree, then
>> - set up https://gitlab.kitware.com/cmake/find-modules
>> - move all existing Find-modules in there
>> - relax maintenance rules to accept *any* Find-module, provided
>> --- CMake scripting is decent quality (e.g no community downvotes or
>> rejecting reviews for period of quarantine)
>> --- CI passing tests
>> - finally, include the complete find-modules archive in the installer
>> so it is deployed
>>    aside of CMake itself
>
> That seems like a reasonable way to deal with the situation. Maybe this would
> also encourage better quality of the (current) core find-modules. If you take a
> look at those, they are in wildly different shape regarding their quality.


Yes, I have noticed the low quality modules.
I am taking baby steps to improve them, at least in (library) areas of
my interest.

My initial story started with the simple premise:
- Find-modules are very useful "guessers"
- Find-modules are going to stay as they complement preferred Config-files
- CMake installs selection of Find-modules which should be allowed to expand
- CMake installs Find-modules of good and bad or broken quality
- CMake does not suffer directly from hosting bad quality Find-modules
- CMake should let the community propose and maintain Find-modules
- CMake should not care if a Find-module becomes outdated as it would
not suffer directly (as per previous points)
...


Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

From mateusz at loskot.net  Tue May 22 17:30:34 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Tue, 22 May 2018 23:30:34 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <1bf883c890fddaa0069871dc913ce5b4@codelibre.net>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1bf883c890fddaa0069871dc913ce5b4@codelibre.net>
Message-ID: <CABUeae_DoO0GYRtoR=mdjdgf+g-cDr5uvQ=wdMQg5fHJu3YnSg@mail.gmail.com>

On 22 May 2018 at 13:36,  <rleigh at codelibre.net> wrote:
> On 2018-05-21 18:39, Mateusz Loskot wrote:
>>
>> I've been recently trying to update/add Find-modules to CMake:
>> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
> [?]
>>
>> The FindLZ4 discussion basically ended with suggestion from Brad that,
>> instead of adding Find-module to CMake, I should approach LZ4 project
>> and add Config-file to the library itself.
>> Then I argued taht Config-files are more complex and I don't feel like
>> asking projects, which I don't maintain myself, to accept the extra
>> complexity.
>> Finally, Brad replied that CMake doesn't need LZ4 itself and yet for some
>> reason is expected to know all about it: versions, headers, libraries,
>> etc.
>> and that it's not scalable to teach CMake about every project in the
>> world.
>
>
> It really doesn't scale.  I've contributed and provided ongoing fixes for a
> few Find modules out of practical necessity, for projects which are
> effectively incapable of adding a Config-file, either because the project
> was stagnant with no new releases (Xerces, Xalan), or where the project was
> so complex that it was effectively impossible to add (Boost).

It does not matter if it scales.
If there is enough interest within the community, Find-modules should be
allowed and maintained. If they are not, they will stagnate.
That will be the community choice.
Still, it will not hurt CMake principles which already does not care.

> However, that work should have been done by the upstream.
> The ongoing maintenance cost
> has been moved from the upstream development, where it belongs, to a
> volunteer (me).  It's work which I do because it provides value to me and my
> employer so I can use CMake with the projects I work on, but is otherwise
> unjustifiable.

Regarding FindBoost.cmake, being a Boost user, as well as
developer and maintainer of Boost libraries, I already know it is PITA.
I, however, have learned FindBoost.cmake is always step behind
and I have learned how to live with that.
There have been discussions about how Boost could take ove FindBoost.cmake
or provide Config-files, but it always ended with discussions about
(too) clever automatic solutions, Boost.Build integrations, bla bla bla
that literally no one is knowledgable enough or interested to maintain
in long term
- should read as "it's going to implode sooner or later anyway".

To me, FindBoost.cmake works in majority of cases (perhaps not quite
for 1.67 ;))
I know enough CMake scripting to be able to attempt to fix stuff.
Better is enemy of good. I prefer good as good enough to get things done.

Finally, Find-modules are just "guesser", they do not promise marksman-like
operating to find every variant of every version of every library.
Find-modules, however, should be there for most, even if lacking
they can serve as useful basis to develop improved Find-modules,
perhaps contribute it back.
If there is not CMake-provided Find-module, then there is cultivation of
chaos of mostly badly written Find-modules scattered caross GitHub
(thanks the spirits GitHub provides usable search engine).


> You simply can't expect every Find module to keep pace with
> upstream development without a small army of volunteers to keep them all up
> to date.

The point is, I do not expect that.
I have mentioned multiple times, Find-modules should be allowed to
become outdated,
awaiting for intersted volunteers to deliver necessary updates.
But, Find-modules should be there regardless.

> If they are provided with the upstream releases, they are de facto
> always up to date because they are directly matched to the library.

IMHO, that is a false expectation or perception.

> Note that for several of these projects (e.g. Xerces, libtiff), I have
> actually provided upstream CMake build systems which install Config-files,
> so in the future the Find modules can be deprecated and users can move to
> the Config-file as these releases make their way into distributions.


Again, my point is, there is no need for deprecating Find-modules.
CMake can automatically prefer Conig-files if present.
CMake users can conciously prefer one or the other.
Point being, there is choice and the choice is left to both sides,
users as well as maintainers, including Find-modules maintainers.

> That's semi-altruistic.  I've spent a lot of effort up front to make CMake
> infrastructure in these projects maintainable for the long term, and
> something which can be delegated to others for ongoing maintenance.

I do realise the hassle may be huge.
Why not simply shift the way we think about Find-modules
- let them in, without deprecating, and let them remain as fall-back
(regardless if
up-to-date, working or not).

>> This opinion does not surprise me and I understand the rationale.
>> I argue that CMake does need to know about every project in the world,
>> or every project that CMake users wish to use, directly or indirectly.
>> Without the knowledge CMake would simply be useless.
>
>
> Not useless, that's going a bit far.  It's requiring a little bit of extra
> work to be functional.  For libraries without Find modules, you can usually
> write your own in a couple of dozen lines.

Yet another point being, I do not want to write my own, maintain
'cmake' subfolder
in numerous projects of mine, I do not want that.
I buy in to CMake to get it covered by CMake
(even if it means I write a Find-module myself and contribute it to CMake).


> At that point your options are:
>
> - to upstream it as a Config-file template to the upstream developers
> - to maintain it independently in your project
> - to upstream it to cmake.git

I aim to eliminate the 2nd option, but sometimes the 3rd option is not feasible
due to CMake bouncing the responsibility to 1st option.

>> If a library is strictly GNU Autoconf, I'm on lost position trying to
>> convince
>> maitnainers to accept CMake stuff and even if they do, they won't be
>> willing to
>> maintain it - broken Config-files may be deployed with new packages.
>> That puts users of CMake and such library on lost position:
>> CMake says no to Find-module, the library does not care either.
>
>
> If it's using Autoconf, then it can still provide and install CMake
> configuration files.  It can use @var@ substitutions in the Config-file.in
> template and then install it.  Just like for pkg-config templates.

Unless, a religious unwillingless plays an important role.

> Individual projects may have their own policies, and some might not want to
> have CMake support.  In general though, if you were to provide a tested
> patch that creates the Config-file in AC_OUTPUT and then install as e.g.
> cmake_pkgconfig_DATA in Makefile.am, add a distcheck hook and/or CI logic to
> test it, and most projects are in my experience willing to accept the patch.
> The only way to find out is to create and submit the patch, and have a
> conversation with them about the cost/benefit of including it.  Some might
> be worried about the maintenance burden, so explain the value of it and
> maybe commit to maintaining it as required.  Since you'd likely be
> maintaining it /anyway/, it's not a big task.

As I have explained in my initial post, I may not always be
intersested in maintaining
CMake support in N different locations/projects/repositories (for
variety of reasons).
I, however, may be happy to maintain it in the single CMake upstream repository.

>> As CMake user I don't want to be left to the discretion of package
>> maintainers.
>> Packages may ignore CMake Config-file existence.
>> Packages of libraries which provide CMake and alternative build
>> configurations
>> may not deploy Config-files or Find-modules.
>>
>> IMHO, CMake should encourage contributions of new Find-modules.
>
>
> As with all things, in my opinion this really comes down to these questions:
> "who is going to do the work", and "who is paying for their time".
> Contribution also has implied ongoing maintenance obligations.

That is excatly what I'm arguing against.

I have submitted number of m4 modules to GNU Autoconf Archive
and nobody objected (unless a module was technically ill-formed)
or asked me if I'm going to maintain those modules.
In fact, I have not done any maintenance for long time, but I have received
numerous patches from users (which I submitted back to the Archive, of course).


> If Find modules are contributed and then not maintained, they will become broken
> over time, and who will be expected to keep them updated?  The CMake core
> maintainers?  The submitter?  Users who need it?
> If it's upstreamed, it's much less of a liability.

I will repeat myself once again: CMake aleady does not care or at least can not
promise a Find-module is up to date. So, there is no harm of a collection of
*official* CMake modules installed aside of CMake is left to be
maintained by community.

> For the stuff I've contributed, it's mostly been
> done on my paid work time because it has value for the work projects,
> enabling easy building and testing on a large range of platforms for both
> our developers and end users.  But when I move onto new projects or a new
> job, I'll find it difficult to justify doing this in my spare time, as much
> as I might like to.  If you take a look at the bug list for e.g. FindBoost,
> there are a lot of open issues, but it's so huge and complex that I don't
> have the resources (different systems) to address all of the defects--that
> requires contributions from the people who can actually test these systems I
> can't.  The huge complexity here squarely belongs upstream.  FindBoost is
> one of the more complex modules, and I can fully sympathise with the desire
> to avoid more of these maintenance nightmares.  It's already a large burden
> upon both people like me, and I suspect also the CMake core maintainers in
> creating, testing and reviewing changes for every Boost release and for
> every platform it's expected to run on.  Multiply that by the total number
> of Find modules (approximately 150 at present).


A module can naturally become outdated. If there is nobody submitting patches,
there should be no problem and CMake should not suffer at all.
It already does not promise up to date Find-modules.
But, IMHO, existence of FindX.cmake increase chances a contributor
will arrive with updates.
If there is no FindX.cmake, there is nothing to update, because there
is nothing to maintain.


> One thing I do think could be improved is the behaviour of find_package and
> MODULE|NO_MODULE|CONFIG.  In order to allow more transparent migration from
> Find modules to Config-files it would be nice if in the absence of any of
> these flags, it would firstly try the Config-file and if it was missing,
> then fall back to a Find module.


I agree. That is should be a must-have feature.

I would even dare to judge that lack of this feature is one of reasons
CMake maintainers dislike Find-modules :-)


Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From pfultz2 at yahoo.com  Tue May 22 21:46:09 2018
From: pfultz2 at yahoo.com (Paul Fultz II)
Date: Tue, 22 May 2018 20:46:09 -0500
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <1bf883c890fddaa0069871dc913ce5b4@codelibre.net>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1bf883c890fddaa0069871dc913ce5b4@codelibre.net>
Message-ID: <A461C2AB-4B57-4249-9D8F-819A0E25FD5B@yahoo.com>


> On May 22, 2018, at 6:36 AM, rleigh at codelibre.net wrote:
> 
> On 2018-05-21 18:39, Mateusz Loskot wrote:
>> I've been recently trying to update/add Find-modules to CMake:
>> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
> [?]
>> The FindLZ4 discussion basically ended with suggestion from Brad that,
>> instead of adding Find-module to CMake, I should approach LZ4 project
>> and add Config-file to the library itself.
>> Then I argued taht Config-files are more complex and I don't feel like
>> asking projects, which I don't maintain myself, to accept the extra complexity.
>> Finally, Brad replied that CMake doesn't need LZ4 itself and yet for some
>> reason is expected to know all about it: versions, headers, libraries, etc.
>> and that it's not scalable to teach CMake about every project in the world.
> 
> It really doesn't scale.  I've contributed and provided ongoing fixes for a few Find modules out of practical necessity, for projects which are effectively incapable of adding a Config-file, either because the project was stagnant with no new releases (Xerces, Xalan), or where the project was so complex that it was effectively impossible to add (Boost).  However, that work should have been done by the upstream.  The ongoing maintenance cost has been moved from the upstream development, where it belongs, to a volunteer (me).  It's work which I do because it provides value to me and my employer so I can use CMake with the projects I work on, but is otherwise unjustifiable.  You simply can't expect every Find module to keep pace with upstream development without a small army of volunteers to keep them all up to date.  If they are provided with the upstream releases, they are de facto always up to date because they are directly matched to the library.
> 
> Note that for several of these projects (e.g. Xerces, libtiff), I have actually provided upstream CMake build systems which install Config-files, so in the future the Find modules can be deprecated and users can move to the Config-file as these releases make their way into distributions.  That's semi-altruistic.  I've spent a lot of effort up front to make CMake infrastructure in these projects maintainable for the long term, and something which can be delegated to others for ongoing maintenance.
> 
>> This opinion does not surprise me and I understand the rationale.
>> I argue that CMake does need to know about every project in the world,
>> or every project that CMake users wish to use, directly or indirectly.
>> Without the knowledge CMake would simply be useless.
> 
> Not useless, that's going a bit far.  It's requiring a little bit of extra work to be functional.  For libraries without Find modules, you can usually write your own in a couple of dozen lines.  At that point your options are:
> 
> - to upstream it as a Config-file template to the upstream developers
> - to maintain it independently in your project
> - to upstream it to cmake.git
> 
> Depending upon the library in question, I've done all three at various times.
> 
>> As a CMake user, I expect to be able to install CMake and get my dependencies
>> recognised by CMake as CMake's responsibility
> 
>> If a library is strictly GNU Autoconf, I'm on lost position trying to convince
>> maitnainers to accept CMake stuff and even if they do, they won't be willing to
>> maintain it - broken Config-files may be deployed with new packages.
>> That puts users of CMake and such library on lost position:
>> CMake says no to Find-module, the library does not care either.
> 
> If it's using Autoconf, then it can still provide and install CMake configuration files.  It can use @var@ substitutions in the Config-file.in template and then install it.  Just like for pkg-config templates.

If a project already uses pkg-config, a user could just use that for its usage requirements. Even more, why couldn?t cmake support this natively? That is the user can just write something like `find_package(zlib CONF)` to get zlib?s usage requirements. This would simplify when a cmake project wants to generate config cmake which uses a pkg-config file, as we can just write `find_dependency(zlib CONF)`.

Paul


From pfultz2 at yahoo.com  Tue May 22 22:06:17 2018
From: pfultz2 at yahoo.com (Paul Fultz II)
Date: Tue, 22 May 2018 21:06:17 -0500
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
Message-ID: <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>


> On May 22, 2018, at 10:13 AM, Brad King <brad.king at kitware.com> wrote:
> 
> On 05/22/2018 06:27 AM, Johannes Zarl-Zierl wrote:
>> There's more that we (as CMake community) could do to make it easier for non-
>> cmake projects to add a config file...
> [snip]
>> not be much more work for the maintainer as pkg-config files.
> 
> There is a proposal here:
> 
>  https://mwoehlke.github.io/cps/
> 
> for a new package specification format to supersede both CMake
> package configuration files and pkg-config .pc files with something
> sufficient for both use cases.  The "History" section documents
> the limitations of both existing approaches and why neither is
> sufficient on its own.

Or pkg-config could be extended to fix the issues. A `Replaces:` field could be added to support resolving c++11 and c++14 language flags(although changing c++ languages version is a very bad idea and can cause ABI breakage, which why it should be a property of the toolchain).

Also, the link line could support passing the full path to the library rather than using `-L` and `-l` flags. 

> 
> Both pkg-config and CMake's find_package command could use the
> proposed `.cps` files.  Projects would only have to provide one
> kind of spec file that is buildsystem agnostic.

In the Boost Cmake Modules, we support generating both pkg-config and cmake config files automatically from the cmake targets:

http://bcm.readthedocs.io/en/latest/src/BCMExport.html#bcm-auto-export
http://bcm.readthedocs.io/en/latest/src/BCMPkgConfig.html#bcm-auto-pkgconfig

Paul


From johannes.zarl-zierl at jku.at  Wed May 23 06:27:07 2018
From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl)
Date: Wed, 23 May 2018 12:27:07 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
Message-ID: <2748322.kxF4Q14XCf@ersa>

On Dienstag, 22. Mai 2018 11:13:18 CEST Brad King wrote:
> > not be much more work for the maintainer as pkg-config files.
> 
> There is a proposal here:
> 
>   https://mwoehlke.github.io/cps/

This looks quite promising!
Do you know whether there's a shared interest on the pkg-config and autotools 
side?

Even without pkg-config joining the effort, it should be much easier to 
convince projects to create a .cps file than some "arcane" cmake-config scripts.

Cheers,
  Johannes

From markand at malikania.fr  Wed May 23 10:37:32 2018
From: markand at malikania.fr (David Demelier)
Date: Wed, 23 May 2018 16:37:32 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
Message-ID: <c4aa8316b8a028c63b4036fd2c06aeff672b15ec.camel@malikania.fr>

On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:
> Hi,
> 
> I've been recently trying to update/add Find-modules to CMake:
> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
> 
> Discussion during review of the FindLZ4 [1] ended with some
> surprising
> conclusions which I, as someone who relies on CMake and occacionally
> contributes to CMake, don't necessarily agree with.
> I'd like to share some of my thoughts.
> 
> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_4
> 12640
> 
> A bit of a extract from the brief discussion [1]:
> 
> The FindLZ4 discussion basically ended with suggestion from Brad
> that,
> instead of adding Find-module to CMake, I should approach LZ4 project
> and add Config-file to the library itself.

Yes, that's the way to go. It's not the CMake role to add find module
for every single library that exist on earth.

Packages configuration file are not that hard to write and Find
packages are not necessarily easier to write too. You need to create
imported target, check versions, check components and such. All of this
is managed by configuration files automatically when using appropriate
install+export features.

> I understand CMake maintainers try to shift the responsibility of
> recognising
> "every project in the world" away from the CMake itself as not
> scalable.

If you look at pkg-config from Linux world, when you install pkg-config 
you just have the tool that inspects .pc files, it does not come with
all libraries implemented in the world. That exactly what should happen
with CMake too.

> Good approach to avoid need to scale up the maintenance efforts,
> but that is a bad news for CMake users.
> 
> As a CMake user, I expect to be able to install CMake and get my
> dependencies
> recognised by CMake as CMake's responsibility
> I do not want to care if library A which I depend on is actually
> CMake-ignorant or not.
> I do not want to learn why library A does not support CMake, as often
> that is
> philosopical reason and asking about it ends up with a rough
> responses.
> (Imagine, there are libraries on GitHub which maintainers do not
> accept
> addition of ***non-intrusive*** single .travis.yml file, because they
> don't trust it.)
> If a library is strictly GNU Autoconf, I'm on lost position trying to
> convince
> maitnainers to accept CMake stuff and even if they do, they won't be
> willing to
> maintain it - broken Config-files may be deployed with new packages.
> That puts users of CMake and such library on lost position:
> CMake says no to Find-module, the library does not care either.
> 
> As CMake user I don't want to be left to the discretion of package
> maintainers.
> Packages may ignore CMake Config-file existence.

Try to convince them to incorporate a patch, or if they won't I usually
keep a custom FindModule in my own repo and reuse it if required.

> Packages of libraries which provide CMake and alternative build
> configurations
> may not deploy Config-files or Find-modules.
> 
> IMHO, CMake should encourage contributions of new Find-modules.

No.

What if CMake 3.12 has a FindFooBar module shipped in your package
manager. But upstream decided to break everything? Change component
name, change library name? We won't have time to inspect all find
modules and update them *because* upstream decided to change.

> I want to contribute Find-module into a **central place** where I can
> easily
> access it as well as monitor its state and submit fixes if necessary.
> From a contributor POV, that is much more effective than jumping
> between
> variety of issue trackers, creating new accounts for one time use or
> even
> sending patches via e-mails to maitnainers - not everything lives in
> GitHub yet.
> 
> Since CMake is still de-facto a standard for building C++ software,
> from end-user POV the current situation feels almost like vendor
> lock-in.
> 
> I call CMake to accept *any* Find-module, filtering only based on
> quality of CMake
> idiomatic scripting.
> 
> If CMake does not want Find-* modules within the source tree, then
> - set up https://gitlab.kitware.com/cmake/find-modules
> - move all existing Find-modules in there
> - relax maintenance rules to accept *any* Find-module, provided
> --- CMake scripting is decent quality (e.g no community downvotes or
> rejecting
>      reviews for period of quarantine)
> --- CI passing tests
> - finally, include the complete find-modules archive in the installer
> so it is deployed
>    aside of CMake itself

This sounds like more of a reasonable proposal. CMake should by itself
not propose any Find* package anymore. A user-managed repository where
everyone could push their module could be a good idea (just like AUR,
PPA, copr, and such do for distribution packages)


Regards,

-- 
David

From mateusz at loskot.net  Wed May 23 11:18:19 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Wed, 23 May 2018 17:18:19 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <c4aa8316b8a028c63b4036fd2c06aeff672b15ec.camel@malikania.fr>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <c4aa8316b8a028c63b4036fd2c06aeff672b15ec.camel@malikania.fr>
Message-ID: <CABUeae9offXhRTc=-ZLKOf=uG1CJGJ=V14Jr8z=5OZiyjiBn9A@mail.gmail.com>

On 23 May 2018 at 16:37, David Demelier <markand at malikania.fr> wrote:
> On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:
>>
>> I've been recently trying to update/add Find-modules to CMake:
>> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
>>
>> Discussion during review of the FindLZ4 [1] ended with some
>> surprising
>> conclusions which I, as someone who relies on CMake and occacionally
>> contributes to CMake, don't necessarily agree with.
>> I'd like to share some of my thoughts.
>>
>> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_4
>> 12640
>>
>> A bit of a extract from the brief discussion [1]:
>>
>> The FindLZ4 discussion basically ended with suggestion from Brad
>> that,
>> instead of adding Find-module to CMake, I should approach LZ4 project
>> and add Config-file to the library itself.
>
> Yes, that's the way to go.

I hoped it will draw clear from my earlier thoughts that I consider discussion
*if* CMake should encourage Find-modules as pointless, or at least
off-topic here.
We should be discussing not *if*, but *how* to keep Find-modules,
enourage new ones, fix existing ones and make both Find-modules and
Config-files coexist.

Hence, I'm not going to address any of your points trying to convince me
to give up my position. If I do, we will be making circles forever.

>> Packages of libraries which provide CMake and alternative build
>> configurations
>> may not deploy Config-files or Find-modules.
>>
>> IMHO, CMake should encourage contributions of new Find-modules.
>
> No.

Yes.

> What if CMake 3.12 has a FindFooBar module shipped in your package
> manager. But upstream decided to break everything? Change component
> name, change library name? We won't have time to inspect all find
> modules and update them *because* upstream decided to change.

Nothing. That is already the case and nobody expects Find-modules are
100% solid across CMake X versions of libraries it can recognise.

Find-modules are "guessers" and as such CMake does not give hard promises.
That is already the case. I will repeat the premise points from earlier:

- Find-modules are very useful "guessers"
- CMake installs Find-modules of good and bad or broken quality (that
is happening today!)
- CMake does not suffer directly from hosting bad quality Find-modules
- CMake should not care if a Find-module becomes outdated as it would
not suffer directly (as per previous points)

>> I want to contribute Find-module into a **central place** where I can
>> easily
>> access it as well as monitor its state and submit fixes if necessary.
>> From a contributor POV, that is much more effective than jumping
>> between
>> variety of issue trackers, creating new accounts for one time use or
>> even
>> sending patches via e-mails to maitnainers - not everything lives in
>> GitHub yet.
>>
>> Since CMake is still de-facto a standard for building C++ software,
>> from end-user POV the current situation feels almost like vendor
>> lock-in.
>>
>> I call CMake to accept *any* Find-module, filtering only based on
>> quality of CMake
>> idiomatic scripting.
>>
>> If CMake does not want Find-* modules within the source tree, then
>> - set up https://gitlab.kitware.com/cmake/find-modules
>> - move all existing Find-modules in there
>> - relax maintenance rules to accept *any* Find-module, provided
>> --- CMake scripting is decent quality (e.g no community downvotes or
>> rejecting
>>      reviews for period of quarantine)
>> --- CI passing tests
>> - finally, include the complete find-modules archive in the installer
>> so it is deployed
>>    aside of CMake itself
>
> This sounds like more of a reasonable proposal. CMake should by itself
> not propose any Find* package anymore. A user-managed repository where
> everyone could push their module could be a good idea (just like AUR,
> PPA, copr, and such do for distribution packages)

I'm glad we agree here.

I'd like to see such bundle of Find-modules always installed by CMake.
I'd like to see it hosted on gitlab.kitware.com
I'd like to stick to some form of community-powered dictatorship to
ensure minimum quality.
If there is not enough community to maintain it and keep modules up to
date that is fine
- single high quality but outdated FindX.cmake is worth a ton more
than dozen shitty FindX.cmake dangling on GitHub.
CMake scripting lazyness should be kapt away from
gitlab.kitware.com/cmake-find-modules.


Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From elvis.stansvik at orexplore.com  Thu May 24 02:45:30 2018
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 24 May 2018 08:45:30 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <CABUeae9offXhRTc=-ZLKOf=uG1CJGJ=V14Jr8z=5OZiyjiBn9A@mail.gmail.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <c4aa8316b8a028c63b4036fd2c06aeff672b15ec.camel@malikania.fr>
 <CABUeae9offXhRTc=-ZLKOf=uG1CJGJ=V14Jr8z=5OZiyjiBn9A@mail.gmail.com>
Message-ID: <CAE-7VJk1U2uui74wsD5SCgLOe-Ku_XUgKYw+ca-uzRLrtpdOtQ@mail.gmail.com>

Den ons 23 maj 2018 17:18Mateusz Loskot <mateusz at loskot.net> skrev:

> On 23 May 2018 at 16:37, David Demelier <markand at malikania.fr> wrote:
> > On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:
> >>
> >> I've been recently trying to update/add Find-modules to CMake:
> >> updated FindJPEG, proposed FindODBC and most recently FindLZ4.
> >>
> >> Discussion during review of the FindLZ4 [1] ended with some
> >> surprising
> >> conclusions which I, as someone who relies on CMake and occacionally
> >> contributes to CMake, don't necessarily agree with.
> >> I'd like to share some of my thoughts.
> >>
> >> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_4
> >> 12640
> >>
> >> A bit of a extract from the brief discussion [1]:
> >>
> >> The FindLZ4 discussion basically ended with suggestion from Brad
> >> that,
> >> instead of adding Find-module to CMake, I should approach LZ4 project
> >> and add Config-file to the library itself.
> >
> > Yes, that's the way to go.
>
> I hoped it will draw clear from my earlier thoughts that I consider
> discussion
> *if* CMake should encourage Find-modules as pointless, or at least
> off-topic here.
> We should be discussing not *if*, but *how* to keep Find-modules,
> enourage new ones, fix existing ones and make both Find-modules and
> Config-files coexist.
>
> Hence, I'm not going to address any of your points trying to convince me
> to give up my position. If I do, we will be making circles forever.
>
> >> Packages of libraries which provide CMake and alternative build
> >> configurations
> >> may not deploy Config-files or Find-modules.
> >>
> >> IMHO, CMake should encourage contributions of new Find-modules.
> >
> > No.
>
> Yes.
>

As for my part, I'll just have to agree to disagree with this. When I first
learned about CMake many years ago, I always thought it strange that it
came bundled with a bunch of Find modules (compared to say the pkg-config
approach), because it seemed to me such an obviously futile effort to get
coverage/keep them up to date.

Maybe the bundled modules served (and continues to serve) a purpose in that
they encourage the uptake of CMake. But I think CMake has grown so much by
now, and has such leverage (people generally are not opposed to being
"CMake compatible"), that efforts are better spent making it easy to write
config files, and supporting initiatives like that cps thing.

I also don't agree that it doesn't hurt CMake to have a growing number of
outdated find modules. It leads to a lot of bug reports. If it's there,
people will expect it to work, and when it doesn't they become
disappointed. If it wasn't there from the beginning there's no expectation.

My 2 cents


> > What if CMake 3.12 has a FindFooBar module shipped in your package
> > manager. But upstream decided to break everything? Change component
> > name, change library name? We won't have time to inspect all find
> > modules and update them *because* upstream decided to change.
>
> Nothing. That is already the case and nobody expects Find-modules are
> 100% solid across CMake X versions of libraries it can recognise.
>
> Find-modules are "guessers" and as such CMake does not give hard promises.
> That is already the case. I will repeat the premise points from earlier:
>
> - Find-modules are very useful "guessers"
> - CMake installs Find-modules of good and bad or broken quality (that
> is happening today!)
> - CMake does not suffer directly from hosting bad quality Find-modules
> - CMake should not care if a Find-module becomes outdated as it would
> not suffer directly (as per previous points)
>
> >> I want to contribute Find-module into a **central place** where I can
> >> easily
> >> access it as well as monitor its state and submit fixes if necessary.
> >> From a contributor POV, that is much more effective than jumping
> >> between
> >> variety of issue trackers, creating new accounts for one time use or
> >> even
> >> sending patches via e-mails to maitnainers - not everything lives in
> >> GitHub yet.
> >>
> >> Since CMake is still de-facto a standard for building C++ software,
> >> from end-user POV the current situation feels almost like vendor
> >> lock-in.
> >>
> >> I call CMake to accept *any* Find-module, filtering only based on
> >> quality of CMake
> >> idiomatic scripting.
> >>
> >> If CMake does not want Find-* modules within the source tree, then
> >> - set up https://gitlab.kitware.com/cmake/find-modules
> >> - move all existing Find-modules in there
> >> - relax maintenance rules to accept *any* Find-module, provided
> >> --- CMake scripting is decent quality (e.g no community downvotes or
> >> rejecting
> >>      reviews for period of quarantine)
> >> --- CI passing tests
> >> - finally, include the complete find-modules archive in the installer
> >> so it is deployed
> >>    aside of CMake itself
> >
> > This sounds like more of a reasonable proposal. CMake should by itself
> > not propose any Find* package anymore. A user-managed repository where
> > everyone could push their module could be a good idea (just like AUR,
> > PPA, copr, and such do for distribution packages)
>
> I'm glad we agree here.
>
> I'd like to see such bundle of Find-modules always installed by CMake.
> I'd like to see it hosted on gitlab.kitware.com
> I'd like to stick to some form of community-powered dictatorship to
> ensure minimum quality.
> If there is not enough community to maintain it and keep modules up to
> date that is fine
> - single high quality but outdated FindX.cmake is worth a ton more
> than dozen shitty FindX.cmake dangling on GitHub.
> CMake scripting lazyness should be kapt away from
> gitlab.kitware.com/cmake-find-modules.
>
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180524/f6fd4a40/attachment.html>

From mateusz at loskot.net  Thu May 24 03:53:32 2018
From: mateusz at loskot.net (Mateusz Loskot)
Date: Thu, 24 May 2018 09:53:32 +0200
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <CAE-7VJk1U2uui74wsD5SCgLOe-Ku_XUgKYw+ca-uzRLrtpdOtQ@mail.gmail.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <c4aa8316b8a028c63b4036fd2c06aeff672b15ec.camel@malikania.fr>
 <CABUeae9offXhRTc=-ZLKOf=uG1CJGJ=V14Jr8z=5OZiyjiBn9A@mail.gmail.com>
 <CAE-7VJk1U2uui74wsD5SCgLOe-Ku_XUgKYw+ca-uzRLrtpdOtQ@mail.gmail.com>
Message-ID: <CABUeae_z2mRtHHgS3yfR9_YuH0Qe2sYwWhXuwaod6fZRsFTirA@mail.gmail.com>

On 24 May 2018 at 08:45, Elvis Stansvik <elvis.stansvik at orexplore.com> wrote:
> Den ons 23 maj 2018 17:18Mateusz Loskot <mateusz at loskot.net> skrev:
>> On 23 May 2018 at 16:37, David Demelier <markand at malikania.fr> wrote:
>> > On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote:
>> >>
>> >>
>> >> IMHO, CMake should encourage contributions of new Find-modules.
>> >
>> > No.
>>
>> Yes.
>
>
> As for my part, I'll just have to agree to disagree with this.
> [...]
> But I think CMake has grown so much by
> now, and has such leverage (people generally are not opposed to being "CMake
> compatible"), that efforts are better spent making it easy to write config
> files, and supporting initiatives like that cps thing.

Those will take years to get into production state for CMake.
Find-modules can solve issues now, without "want to drive? build your
own car first"
appraoch, but  basic CMake scripting knowledge.
I'm very supportive to the cps, but I can not help it move forward.
I, however, can help updating/adding Find-modules.

> I also don't agree that it doesn't hurt CMake to have a growing number of
> outdated find modules. It leads to a lot of bug reports.

In the times of GitHub-like pace of development, we should really learn to use
https://github.com/apps/stale or equivalents.

> If it's there, people will expect it to work, and when it doesn't they become disappointed.
> If it wasn't there from the beginning there's no expectation.

There is nothing wrong with it, as long as status of Find-modules is clearly
stated in the documentation and users learn correctly what Find-modules are
- guessers about future without promises, not configurators about present state.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

From brad.king at kitware.com  Thu May 24 09:07:05 2018
From: brad.king at kitware.com (Brad King)
Date: Thu, 24 May 2018 09:07:05 -0400
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
Message-ID: <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>

On 05/22/2018 10:06 PM, Paul Fultz II wrote:
> Or pkg-config could be extended to fix the issues.

The `.pc` file format is too flat to lend itself well to representing
all the information we need.  A goal of `.cps` files is to teach
pkg-config to parse them and respond to its standard queries with the
same output format as now.

> In the Boost Cmake Modules, we support generating both pkg-config and
> cmake config files automatically from the cmake targets:

That's fantastic but until there is no such thing as a Boost installation
that doesn't support both tools the problems will persist.  They mangle
their library names in such a way that it's impossible to use boost without
a build system that memorizes dozens of mangling conventions that vary
with the version of boost, version of the compiler, architecture, etc.

-Brad

From francesco.bbt at gmail.com  Thu May 24 12:48:57 2018
From: francesco.bbt at gmail.com (Francesco Abbate)
Date: Thu, 24 May 2018 18:48:57 +0200
Subject: [CMake] problem with CMake not including library's path (with
 pkg-config)
Message-ID: <CAABEgWp1J18ZtQng__Q-M1RNX3zu2NXS6Mxeb0m3XKBYWnws4g@mail.gmail.com>

Hi all,

I stumbled in a problem with CMake. Everything is working fine except
that, for two libraries that I locate with pkg-config, cmake does not
include during linking the library's path (-L<path>) which is given by
pkg-config.


Here an extract of the CMakeLists.txt:


[...]

include(FindPkgConfig)
pkg_search_module(AGG REQUIRED libagg)

[...]

target_link_libraries(libcanvas ${AGG_LIBRARIES})
target_include_directories(libcanvas PUBLIC
${PROJECT_SOURCE_DIR}/include ${AGG_INCLUDE_DIRS})
[...]

When I run pkg-config everything is correct:

> pkg-config --libs libagg
-Lc:/fra/local_msys64/lib -lagg -lm

One can notice that pkg-config provides a non-standard path for the library.

By inspecting CMakeCache.txt I found a trace of the library's path.
See below an extract:

AGG_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_CFLAGS_I:INTERNAL=
AGG_CFLAGS_OTHER:INTERNAL=
AGG_FOUND:INTERNAL=1
AGG_INCLUDEDIR:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_LDFLAGS_OTHER:INTERNAL=
AGG_LIBDIR:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBRARIES:INTERNAL=agg;m
AGG_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBS:INTERNAL=
AGG_LIBS_L:INTERNAL=
AGG_LIBS_OTHER:INTERNAL=
AGG_LIBS_PATHS:INTERNAL=
AGG_PREFIX:INTERNAL=c:/fra/local_msys64
AGG_STATIC_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_STATIC_CFLAGS_I:INTERNAL=
AGG_STATIC_CFLAGS_OTHER:INTERNAL=
AGG_STATIC_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_STATIC_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_STATIC_LDFLAGS_OTHER:INTERNAL=
AGG_STATIC_LIBDIR:INTERNAL=
AGG_STATIC_LIBRARIES:INTERNAL=agg;m
AGG_STATIC_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_STATIC_LIBS:INTERNAL=
AGG_STATIC_LIBS_L:INTERNAL=
AGG_STATIC_LIBS_OTHER:INTERNAL=
AGG_STATIC_LIBS_PATHS:INTERNAL=
AGG_VERSION:INTERNAL=2.5.0
AGG_libagg_INCLUDEDIR:INTERNAL=
AGG_libagg_LIBDIR:INTERNAL=
AGG_libagg_PREFIX:INTERNAL=
AGG_libagg_VERSION:INTERNAL=

but in the Ninja build file the library's path is not given (below an extract):

----------
#############################################
# Link the executable tests\test-window.exe

build tests/test-window.exe: CXX_EXECUTABLE_LINKER__test-window tests/CMakeFiles
/test-window.dir/test-window.cpp.obj | win32/liblibcanvaswin32.a src/liblibcanva
s.a || src/liblibcanvas.a win32/liblibcanvaswin32.a
  LINK_LIBRARIES = win32/liblibcanvaswin32.a src/liblibcanvas.a -lagg
-lm -lfreetype -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
------------

So the behavior of CMake looks wrong to me. Pkg-config is giving
explicitly a non-standard library path but CMake just decided to not
include it in the linker options.

To finish let me report that I'am using CMake 3.11.1 on a Windows
system using MSYS2.

I can also mention that a similar Meson build just works fine but this
is only to make you, CMake guys, jealous.

Ok, just kidding :-)

Thank you in advance for any help.

Kind regards
Francesco





-- 
Francesco

From Andreas-Naumann at gmx.net  Thu May 24 16:38:28 2018
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Thu, 24 May 2018 22:38:28 +0200
Subject: [CMake] problem with CMake not including library's path (with
 pkg-config)
In-Reply-To: <CAABEgWp1J18ZtQng__Q-M1RNX3zu2NXS6Mxeb0m3XKBYWnws4g@mail.gmail.com>
References: <CAABEgWp1J18ZtQng__Q-M1RNX3zu2NXS6Mxeb0m3XKBYWnws4g@mail.gmail.com>
Message-ID: <894e3440-2618-f321-5e10-7d86c84be03d@gmx.net>

Dear Francesco,

I use the pkg-config module with IPopt and had the same problem. 
According to the documentation, the library paths are in 
<XPREFIX>_LIBRARY_DIRS. In your case, you should find the paths in the 
variable AGG_LIBRARY_DIRS or all flags in the variable? AGG_LDFLAGS .

Regards,
Andreas
Am 24.05.2018 um 18:48 schrieb Francesco Abbate:
> Hi all,
>
> I stumbled in a problem with CMake. Everything is working fine except
> that, for two libraries that I locate with pkg-config, cmake does not
> include during linking the library's path (-L<path>) which is given by
> pkg-config.
>
>
> Here an extract of the CMakeLists.txt:
>
>
> [...]
>
> include(FindPkgConfig)
> pkg_search_module(AGG REQUIRED libagg)
>
> [...]
>
> target_link_libraries(libcanvas ${AGG_LIBRARIES})
> target_include_directories(libcanvas PUBLIC
> ${PROJECT_SOURCE_DIR}/include ${AGG_INCLUDE_DIRS})
> [...]
>
> When I run pkg-config everything is correct:
>
>> pkg-config --libs libagg
> -Lc:/fra/local_msys64/lib -lagg -lm
>
> One can notice that pkg-config provides a non-standard path for the library.
>
> By inspecting CMakeCache.txt I found a trace of the library's path.
> See below an extract:
>
> AGG_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
> AGG_CFLAGS_I:INTERNAL=
> AGG_CFLAGS_OTHER:INTERNAL=
> AGG_FOUND:INTERNAL=1
> AGG_INCLUDEDIR:INTERNAL=c:/fra/local_msys64/include/agg2
> AGG_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
> AGG_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
> AGG_LDFLAGS_OTHER:INTERNAL=
> AGG_LIBDIR:INTERNAL=c:/fra/local_msys64/lib
> AGG_LIBRARIES:INTERNAL=agg;m
> AGG_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
> AGG_LIBS:INTERNAL=
> AGG_LIBS_L:INTERNAL=
> AGG_LIBS_OTHER:INTERNAL=
> AGG_LIBS_PATHS:INTERNAL=
> AGG_PREFIX:INTERNAL=c:/fra/local_msys64
> AGG_STATIC_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
> AGG_STATIC_CFLAGS_I:INTERNAL=
> AGG_STATIC_CFLAGS_OTHER:INTERNAL=
> AGG_STATIC_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
> AGG_STATIC_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
> AGG_STATIC_LDFLAGS_OTHER:INTERNAL=
> AGG_STATIC_LIBDIR:INTERNAL=
> AGG_STATIC_LIBRARIES:INTERNAL=agg;m
> AGG_STATIC_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
> AGG_STATIC_LIBS:INTERNAL=
> AGG_STATIC_LIBS_L:INTERNAL=
> AGG_STATIC_LIBS_OTHER:INTERNAL=
> AGG_STATIC_LIBS_PATHS:INTERNAL=
> AGG_VERSION:INTERNAL=2.5.0
> AGG_libagg_INCLUDEDIR:INTERNAL=
> AGG_libagg_LIBDIR:INTERNAL=
> AGG_libagg_PREFIX:INTERNAL=
> AGG_libagg_VERSION:INTERNAL=
>
> but in the Ninja build file the library's path is not given (below an extract):
>
> ----------
> #############################################
> # Link the executable tests\test-window.exe
>
> build tests/test-window.exe: CXX_EXECUTABLE_LINKER__test-window tests/CMakeFiles
> /test-window.dir/test-window.cpp.obj | win32/liblibcanvaswin32.a src/liblibcanva
> s.a || src/liblibcanvas.a win32/liblibcanvaswin32.a
>    LINK_LIBRARIES = win32/liblibcanvaswin32.a src/liblibcanvas.a -lagg
> -lm -lfreetype -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
> -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
> ------------
>
> So the behavior of CMake looks wrong to me. Pkg-config is giving
> explicitly a non-standard library path but CMake just decided to not
> include it in the linker options.
>
> To finish let me report that I'am using CMake 3.11.1 on a Windows
> system using MSYS2.
>
> I can also mention that a similar Meson build just works fine but this
> is only to make you, CMake guys, jealous.
>
> Ok, just kidding :-)
>
> Thank you in advance for any help.
>
> Kind regards
> Francesco
>
>
>
>
>


From dwootton at us.ibm.com  Thu May 24 16:22:59 2018
From: dwootton at us.ibm.com (David Wootton)
Date: Thu, 24 May 2018 16:22:59 -0400
Subject: [CMake] Unresolved symbol VerifyFortran with clang C compiler and
 xlf_r Fortran compiler
Message-ID: <OF71B5579D.A94B3C76-ON00258297.006C4DB1-85258297.006FF7FD@notes.na.collabserv.com>



I'm trying to build the lapack library I obtained from
http://www.netlib.org/lapack/lapack-3.8.0.tar.gz.  using the clang C
compiler and the xlf Fortran compiler with cmake 3.11. I'm using a Power 9
Linux system running Red Hat 7

The default behavior for the xlf compiler is to mangle Fortran so the
external symbol name is folded to all lower case with no trailing '_', In
this case, VerifyFortran should be mangled tp verifyfortran.

When I attempt to build it, my build system issues these error messages
     99         CMakeFiles/VerifyFortranC.dir/main.c.o: In function `main':
  >>
100    /nfshome/drw/spack/spack/opt/spack/linux-rhel7-ppc64le/gcc-4.8.5/cm

ake-3.11.1-rcn6qgw6pldsuuk2gkijnn4dalajl4wr/share/cmake-3.11/Module
            s/FortranCInterface/Verify/main.c:(.text+0x24): undefined
reference
             to `VerifyFortran'
  >> 101        clang-3.8: error: linker command failed with exit code 1
(use -
            v to see invocation)
  >> 102        gmake[3]: *** [VerifyFortranC] Error 1
     103        gmake[3]: Leaving directory
`/tmp/drw/spack-staging/spack-stage

/spack-stage-h3S7X1/lapack-3.8.0/spack-build-static/CMakeFiles/Fort
            ranCInterface/VerifyC'

where cmake is attempting to verify Fortran/C compatibility for this pair
of compilers.

I tried to track this down by extracting this tar file in a scratch
directory. The build process requires cmake to be invoked in a separate
drectory from the source code so I created a 'build' directory in the
parent directory where my lapack-3.8.0 source resided, cd to that directory
and ran the command 'cmake ../lapack-3.8.0 -DCBLAS=ON' I get these messages
    cd /nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC
&& /nfshome/drw/cmake/bin/cmake -E cmake_depends "Unix
Makefiles" /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify /nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC /nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC /nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortranC.dir/DependInfo.cmake
    Scanning dependencies of target VerifyFortranC
    gmake[3]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
    /bin/gmake -f CMakeFiles/VerifyFortranC.dir/build.make
CMakeFiles/VerifyFortranC.dir/build
    gmake[3]: Entering directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
    [ 60%] Building C object CMakeFiles/VerifyFortranC.dir/main.c.o
    /opt/clang-coral/bin/clang
-I/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC  -O3
-DNDEBUG   -o CMakeFiles/VerifyFortranC.dir/main.c.o
-c /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/main.c
    [ 80%] Building C object CMakeFiles/VerifyFortranC.dir/VerifyC.c.o
    /opt/clang-coral/bin/clang
-I/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC  -O3
-DNDEBUG   -o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o
-c /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/VerifyC.c
    [100%] Linking C executable VerifyFortranC
    /nfshome/drw/cmake/bin/cmake -E cmake_link_script
CMakeFiles/VerifyFortranC.dir/link.txt --verbose=1
    /opt/clang-coral/bin/clang -O3 -DNDEBUG
CMakeFiles/VerifyFortranC.dir/main.c.o
CMakeFiles/VerifyFortranC.dir/VerifyC.c.o  -o VerifyFortranC
-L/opt/ibm/xlsmp/5.1.0/lib  -L/opt/ibm/xlmass/9.1.0/lib
-L/opt/ibm/xlf/16.1.0/lib libVerifyFortran.a -lxlf90_r -lxlopt -lxlomp_ser
-lxl -lxlfmath -ldl -lrt -lpthread -lm
    CMakeFiles/VerifyFortranC.dir/main.c.o: In function `main':

/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Verify/main.c:(.text
+0x24): undefined reference to `VerifyFortran'
    clang-3.8: error: linker command failed with exit code 1 (use -v to see
invocation)
    gmake[3]: *** [VerifyFortranC] Error 1
    gmake[3]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
    gmake[2]: *** [CMakeFiles/VerifyFortranC.dir/all] Error 2
    gmake[2]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
    gmake[1]: *** [CMakeFiles/VerifyFortranC.dir/rule] Error 2
    gmake[1]: Leaving directory
`/nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface/VerifyC'
    gmake: *** [VerifyFortranC] Error 2

I tried to figure out what's happening by running cmake with the
--trace-expand flag.

When I backtrack thru the log, I see these error messages related to
VerifyFortranC.

/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(24):  unset(FortranCInterface_VERIFIED_C CACHE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(25):  unset(FortranCInterface_VERIFIED_CXX CACHE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(27):  set(_result )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(30):  set(CMAKE_TRY_COMPILE_CONFIGURATION Release )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(31):  try_compile
(FortranCInterface_COMPILED /nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface /nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface
 FortranCInterface FortranCInterface CMAKE_FLAGS -DCMAKE_C_FLAGS:STRING=
-DCMAKE_Fortran_FLAGS:STRING=-qfree  -qthreaded -qhalt=e -qnosave
-qstrict=none -qfixed -DCMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-O OUTPUT_VARIABLE
FortranCInterface_OUTPUT )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(42):  set(FortranCInterface_COMPILED FALSE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(43):  unset(FortranCInterface_COMPILED CACHE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(46):  if(FortranCInterface_COMPILED )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(54):  else()
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(55):  set(_result Failed to compile )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(56):  set(FortranCInterface_EXE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(57):  file
(APPEND /nfshome/drw/spack/lapack/build/CMakeFiles/CMakeError.log Fortran/C
interface test project failed with the following output:
 Change Dir: /nfshome/drw/spack/lapack/build/CMakeFiles/FortranCInterface

Run Build Command:"/bin/gmake" "FortranCInterface"
Scanning dependencies of target myfort
[  2%] Building Fortran object CMakeFiles/myfort.dir/my_module.f90.o
COMMAND LINE  1520-022 (W) The FREE option has been replaced by the option
FREE(F90).
"/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/my_module.f90",
 line 1.0: 1515-005 (S) Continuation line is not permitted at beginning of
program or after INCLUDE, EJECT, @PROCESS statements or comment directive.
Line is ignored.
"/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/my_module.f90",
 line 2.0: 1515-005 (S) Continuation line is not permitted at beginning of
program or after INCLUDE, EJECT, @PROCESS statements or comment directive.
Line is ignored.
"/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/my_module.f90",
 line 3.0: 1515-005 (S) Continuation line is not permitted at beginning of
program or after INCLUDE, EJECT, @PROCESS statements or comment directive.
Line is ignored.
"/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/my_module.f90",
 line 4.3: 1515-017 (S) Label contains characters that are not permitted.
Label is ignored.
"/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/my_module.f90",
 line 7.3: 1515-017 (S) Label contains characters that are not permitted.
Label is ignored.
"/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/my_module.f90",
 line 8.20: 1515-030 (E) END INTERFACE card is missing.  One is assumed.
"/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/my_module.f90",
 line 8.20: 1515-002 (S) END card is missing.  One is assumed.
"/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/my_module.f90",
 1515-002 (S) END card is missing.  One is assumed.
** _main   === End of Compilation 1 ===
1501-511  Compilation failed for file my_module.f90.
gmake[3]: *** [CMakeFiles/myfort.dir/my_module.f90.o] Error 1
gmake[2]: *** [CMakeFiles/myfort.dir/all] Error 2
gmake[1]: *** [CMakeFiles/FortranCInterface.dir/rule] Error 2
gmake: *** [FortranCInterface] Error 2

 )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(63):  set(FortranCInterface_SYMBOLS )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(64):  if(FortranCInterface_EXE )
/nfshome/drw/cmake/share/cmake-3.11/Modules/FortranCInterface/Detect.cmake
(72):  elseif(NOT _result )

These messages seem to result because the -qfixed flag is passed in the xlf
invocation, while my_module.f90 is written in free format, so based on
compiler options, the compiler error messages are legitimate.

My problem is that I don't know if VerifyFortranC is doing somthing that is
expected to fail and then recover from by alternate action or if something
is broken.

Can someone offer insight or resolution?

Thanks

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180524/cce44fa1/attachment-0001.html>

From darrell.langford at yahoo.com  Thu May 24 16:39:14 2018
From: darrell.langford at yahoo.com (Darrell Langford)
Date: Thu, 24 May 2018 14:39:14 -0600
Subject: [CMake] (no subject)
Message-ID: <1527194363.Lx18fA87AxryjLx19fABXC@mf-smf-ucb034c2>

http://excellent.trackthatboat.com

Darrell Langford

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180524/a8318776/attachment.html>

From pfultz2 at yahoo.com  Thu May 24 19:39:57 2018
From: pfultz2 at yahoo.com (Paul Fultz II)
Date: Thu, 24 May 2018 18:39:57 -0500
Subject: [CMake] Contribute Find-module to CMake vs Config-file to
 upstream
In-Reply-To: <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
Message-ID: <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>


> On May 24, 2018, at 8:07 AM, Brad King <brad.king at kitware.com> wrote:
> 
> On 05/22/2018 10:06 PM, Paul Fultz II wrote:
>> Or pkg-config could be extended to fix the issues.
> 
> The `.pc` file format is too flat to lend itself well to representing
> all the information we need.  

What do you mean? What information can?t be represented?



From eike at sf-mail.de  Fri May 25 03:39:33 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Fri, 25 May 2018 09:39:33 +0200
Subject: [CMake] problem with CMake not including library's path (with
 pkg-config)
In-Reply-To: <CAABEgWp1J18ZtQng__Q-M1RNX3zu2NXS6Mxeb0m3XKBYWnws4g@mail.gmail.com>
References: <CAABEgWp1J18ZtQng__Q-M1RNX3zu2NXS6Mxeb0m3XKBYWnws4g@mail.gmail.com>
Message-ID: <4d9c1154232d25c1f7f64c6be071828e@sf-mail.de>

Am 2018-05-24 18:48, schrieb Francesco Abbate:
> Hi all,
> 
> I stumbled in a problem with CMake. Everything is working fine except
> that, for two libraries that I locate with pkg-config, cmake does not
> include during linking the library's path (-L<path>) which is given by
> pkg-config.
> 
> 
> Here an extract of the CMakeLists.txt:
> 
> 
> [...]
> 
> include(FindPkgConfig)
> pkg_search_module(AGG REQUIRED libagg)
> 
> [...]
> 
> target_link_libraries(libcanvas ${AGG_LIBRARIES})
> target_include_directories(libcanvas PUBLIC
> ${PROJECT_SOURCE_DIR}/include ${AGG_INCLUDE_DIRS})
> [...]

Yes, this is a known shortcoming. But there is already help available!

For CMake >= 3.7 you can ask FindPkgConfig to create an imported target 
for you, which will then include not only the library paths, but also 
the include directories, so you do not need to explicitely call 
target_include_directories() anymore:

pkg_search_module(AGG REQUIRED IMPORTED_TARGET libagg)

target_link_libraries(libcanvas PkgConfig::AGG)

I strongly encourage you to go this way as it also drags in needed 
defines and the like.

If you can't go that route for whatever reason you need to do

link_directories(${AGG_LIBRARY_DIRS})

Side note: this is the only place I can still accept the usage of that 
command.

And since it's crappy that you have the full library path in the target, 
but not in a variable, there will be <PREFIX>_LINK_LIBARIES from CMake 
3.12 on, which would be the thing you pass to target_link_libraries() 
instead and which has the exact same information the imported target 
already has.

Greetings,

Eike

From brad.king at kitware.com  Fri May 25 09:07:37 2018
From: brad.king at kitware.com (Brad King)
Date: Fri, 25 May 2018 09:07:37 -0400
Subject: [CMake] pkg-config file format versus CMake packages
In-Reply-To: <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
 <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
Message-ID: <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>

On 05/24/2018 07:39 PM, Paul Fultz II wrote:
>> On May 24, 2018, at 8:07 AM, Brad King wrote:
>> The `.pc` file format is too flat to lend itself well to representing
>> all the information we need.  
> 
> What do you mean? What information can't be represented?

Try running CMake's ExportImport test and take a look at the
files generated by export() and install(EXPORT).  If anyone
can use `.pc` files as a package representation for everything
that test does on all platforms then I'd like to see a proposal.

-Brad

From francesco.bbt at gmail.com  Fri May 25 12:53:43 2018
From: francesco.bbt at gmail.com (Francesco Abbate)
Date: Fri, 25 May 2018 18:53:43 +0200
Subject: [CMake] problem with CMake not including library's path (with
 pkg-config)
In-Reply-To: <4d9c1154232d25c1f7f64c6be071828e@sf-mail.de>
References: <CAABEgWp1J18ZtQng__Q-M1RNX3zu2NXS6Mxeb0m3XKBYWnws4g@mail.gmail.com>
 <4d9c1154232d25c1f7f64c6be071828e@sf-mail.de>
Message-ID: <CAABEgWqEjy56sWaXo8oU9oShww_9g8ssg9Cf53sp_V9dDAfXhg@mail.gmail.com>

Hi,

thank you for the help.

As suggested by Andreas, AGG_LDFLAGS does what I think should be done
and it works for me.

As for the IMPORTED_TARGET approach, I still need to explicitly call
target_include_directories() and in addition the options given to the
linker with PkgConfig::AGG seems to be wrong. I am quite inclined to
forgot about this IMPORTED_TARGET approach, I prefer to use the more
simple approach that works.

If I can suggest something to the cmake developers: please make a more
extensive introduction by covering more common cases. For example the
standard cmake introduction does not mention how to find and use with
an external library. I had to use google and stackoverflow to find the
bit of information I needed. just my two cents.

Kind regards
Francesco

From burlen.loring at gmail.com  Fri May 25 13:16:12 2018
From: burlen.loring at gmail.com (Burlen Loring)
Date: Fri, 25 May 2018 10:16:12 -0700
Subject: [CMake] integrating cmake configured library with other GNU based
 build system?
Message-ID: <1a41ab6f-6f73-5e60-95bf-c56fa161db8a@gmail.com>

Hi All,

Can cmake generate .pc files? Can cmake generate .la files (gnu 
convenience libraries)? Cmake internally generates all the requisite 
info, how can it be accessed?

I have to integrate a cmake based library into a GNUMake build. The 
project has a cmake config file 
<https://gitlab.kitware.com/sensei/sensei/blob/master/CMake/SENSEIConfig.cmake.in> 
which works great with cmake's find_package command when integrating 
with another project using cmake. What do we do when a GNUMake based 
project wants to import our library?

I hacked a cmake script 
<https://gitlab.kitware.com/sensei/sensei/blob/master/tools/sensei_config/CMakeLists.txt> 
to recursively walk our libraries dependencies and inspect 
INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_LINK_LIBRARIES to put 
together a unique list of libraries and include dirs, which can be used 
to generate the necessary info. Unfortunately so far I can only make it 
work as an external cmake project which is configured after we install 
our library.

I would like to have a solution that generates the GNU compatible 
configuration file (.pc,.la, etc)  integrated into our build rather than 
as an additional separate post install step. How have others solved this 
issue?

Thanks
Burlen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180525/4b886e02/attachment.html>

From eike at sf-mail.de  Fri May 25 13:39:17 2018
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Fri, 25 May 2018 19:39:17 +0200
Subject: [CMake] problem with CMake not including library's path (with
 pkg-config)
In-Reply-To: <CAABEgWqEjy56sWaXo8oU9oShww_9g8ssg9Cf53sp_V9dDAfXhg@mail.gmail.com>
References: <CAABEgWp1J18ZtQng__Q-M1RNX3zu2NXS6Mxeb0m3XKBYWnws4g@mail.gmail.com>
 <4d9c1154232d25c1f7f64c6be071828e@sf-mail.de>
 <CAABEgWqEjy56sWaXo8oU9oShww_9g8ssg9Cf53sp_V9dDAfXhg@mail.gmail.com>
Message-ID: <4963184.3PRdgd0ZAv@daneel.sf-tec.de>

Am Freitag, 25. Mai 2018, 18:53:43 schrieb Francesco Abbate:
> Hi,
> 
> thank you for the help.
> 
> As suggested by Andreas, AGG_LDFLAGS does what I think should be done
> and it works for me.
> 
> As for the IMPORTED_TARGET approach, I still need to explicitly call
> target_include_directories() and in addition the options given to the
> linker with PkgConfig::AGG seems to be wrong. I am quite inclined to
> forgot about this IMPORTED_TARGET approach, I prefer to use the more
> simple approach that works.

I would like to hear that story, just in case the module still has bugs. But 
please try with a recent development snapshot of CMake as there have been some 
additional fixes to the module recently.

Eike
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <https://cmake.org/pipermail/cmake/attachments/20180525/4e514059/attachment.sig>

From pfultz2 at yahoo.com  Fri May 25 19:52:43 2018
From: pfultz2 at yahoo.com (Paul Fultz II)
Date: Fri, 25 May 2018 18:52:43 -0500
Subject: [CMake] pkg-config file format versus CMake packages
In-Reply-To: <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
 <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
 <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>
Message-ID: <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>


> On May 25, 2018, at 8:07 AM, Brad King <brad.king at kitware.com> wrote:
> 
> On 05/24/2018 07:39 PM, Paul Fultz II wrote:
>>> On May 24, 2018, at 8:07 AM, Brad King wrote:
>>> The `.pc` file format is too flat to lend itself well to representing
>>> all the information we need.  
>> 
>> What do you mean? What information can't be represented?
> 
> Try running CMake's ExportImport test and take a look at the
> files generated by export() and install(EXPORT).  If anyone
> can use `.pc` files as a package representation for everything
> that test does on all platforms then I'd like to see a proposal.

Yes, and what seems to be missing from pkg-config to represent that information is the ability to put a direct path to the library(instead of using the -l and -L flags), and support for a `Replaces` field. 

This is also the same shortcomings talked about in the CPS document as well. Resolving these shortcomings, will allow pkg-config to represent the same thing as CPS and cmake. What else is missing? 

The reason I say this is that extending pkg-config seems like it would help adoption rather then creating a completely new format. There is already a good portion of open source projects that already support pkg-config, so tweaking them to support more complicated scenarios seems easier than converting everything to a new format.

Paul

From lectem at gmail.com  Sat May 26 06:08:01 2018
From: lectem at gmail.com (Lectem)
Date: Sat, 26 May 2018 12:08:01 +0200
Subject: [CMake] pkg-config file format versus CMake packages
In-Reply-To: <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa>
 <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
 <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
 <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>
 <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>
Message-ID: <5b093200.1c69fb81.910d4.c4f9@mx.google.com>


Hi,
I?ll start by saying that I love the fact we?re now talking about a common representation of packages?!

? The reason I say this is that extending pkg-config seems like it would help adoption rather then creating a completely new format. There is already a good portion of open source projects that already support pkg-config, so tweaking them to support more complicated scenarios seems easier than converting everything to a new format.

I?m not very familiar with pkg-config (working more in the Windows world) so excuse me if I?m wrong.

>From what I remember it is very basic and relies on compiler flags being the same everywhere (ie gcc-like flags), and does not provide any information about things such as ABI, C-runtime Library used (arguably could be represented as a package??). As far as I know, it assumes that the libraries are always compiled with the same compiler on the same system, hence has no knowledge of compatibility between compiler versions. 
As you mentionned, it currently relies on -l for both libraries and linker flags, which would need to be changed.

? so tweaking them to support more complicated scenarios seems easier than converting everything to a new format.

Wouldn?t that create more confusion?? I fear it?d end up as a python2 python3 issue, where both versions look alike but are incompatible.


Have a nice Week-end,
Lectem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180526/1a0234da/attachment.html>

From post at hendrik-sattler.de  Sat May 26 07:07:35 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Sat, 26 May 2018 13:07:35 +0200
Subject: [CMake] pkg-config file format versus CMake packages
In-Reply-To: <5b093200.1c69fb81.910d4.c4f9@mx.google.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
 <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
 <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>
 <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>
 <5b093200.1c69fb81.910d4.c4f9@mx.google.com>
Message-ID: <6BD27CB2-76AA-4404-BBDE-DB7D1926E85C@hendrik-sattler.de>

Hi,

I often found pkg-config files to be even wrong. Many library authors do not seem to know the rules for transitive linking. Often, the differences between static and dynamic linking is not or wrongly expressed in .pc files. Cross compiling with pkg-config is also not being the most fun unless the library author thought about it or you fix the files yourself.

You don't have to care so much about ABI, different compilers and such. On most systems, these need different directories and thus separate .pc files.

CMake also fails late at linking even pointing it to Qt 64bit libraries for a 32bit compiler even though they use config modules! At some point, it's the responsibility of the developer to organize his environment correctly.

Regards,

HS



Am 26. Mai 2018 12:08:01 MESZ schrieb Lectem <lectem at gmail.com>:
>
>Hi,
>I?ll start by saying that I love the fact we?re now talking about a
>common representation of packages?!
>
>? The reason I say this is that extending pkg-config seems like it
>would help adoption rather then creating a completely new format. There
>is already a good portion of open source projects that already support
>pkg-config, so tweaking them to support more complicated scenarios
>seems easier than converting everything to a new format.
>
>I?m not very familiar with pkg-config (working more in the Windows
>world) so excuse me if I?m wrong.
>
>From what I remember it is very basic and relies on compiler flags
>being the same everywhere (ie gcc-like flags), and does not provide any
>information about things such as ABI, C-runtime Library used (arguably
>could be represented as a package??). As far as I know, it assumes that
>the libraries are always compiled with the same compiler on the same
>system, hence has no knowledge of compatibility between compiler
>versions. 
>As you mentionned, it currently relies on -l for both libraries and
>linker flags, which would need to be changed.
>
>? so tweaking them to support more complicated scenarios seems easier
>than converting everything to a new format.
>
>Wouldn?t that create more confusion?? I fear it?d end up as a python2
>python3 issue, where both versions look alike but are incompatible.
>
>
>Have a nice Week-end,
>Lectem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180526/938ba452/attachment-0001.html>

From zer0__0ne at outlook.com  Sat May 26 19:09:51 2018
From: zer0__0ne at outlook.com (zer0 0ne)
Date: Sat, 26 May 2018 23:09:51 +0000
Subject: [CMake] cmake -E env equivalent in 2.8
Message-ID: <CY4PR01MB3205D9DAA35A53D7104C5294BA680@CY4PR01MB3205.prod.exchangelabs.com>

Hi,

I am new to cmake and i am working with CMakefile with -E env option written for 3.1 and I am backporting it to 2.8. What is the compatible or equivalent option in 2.8?

https://github.com/CZ-NIC/turris-os/blob/master/package/system/ubus/patches/001-python.patch

The line I am dealing with is
+ADD_CUSTOM_TARGET(python ALL
+ COMMAND ${CMAKE_COMMAND} -E env "CC=${CMAKE_C_COMPILER} ${CMAKE_C_COMPILER_ARG1}" "LDSHARED=${LDSHARED}" "CFLAGS=${PYTHON_CFLAGS}" ${PYTHON} ${SETUP_PY} build
+ DEPENDS ubus "${CURRENT_SOURCE_DIR}/ubus_python.c"
+)
+
+INSTALL(
+ CODE "execute_process(COMMAND ${CMAKE_COMMAND} -E env \"CC=${CMAKE_C_COMPILER} ${CMAKE_C_COMPILER_ARG1}\" \"LDSHARED=${LDSHARED}\" \"CFLAGS=${PYTHON_CFLAGS}\" ${PYTHON} ${SETUP_PY} install --prefix=${CMAKE_INSTALL_PREFIX})"
+)

Thanks
Zer0 0ne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180526/b2497e12/attachment.html>

From pfultz2 at yahoo.com  Sun May 27 00:33:16 2018
From: pfultz2 at yahoo.com (Paul Fultz II)
Date: Sat, 26 May 2018 23:33:16 -0500
Subject: [CMake] pkg-config file format versus CMake packages
In-Reply-To: <5b093200.1c69fb81.910d4.c4f9@mx.google.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
 <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
 <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>
 <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>
 <5b093200.1c69fb81.910d4.c4f9@mx.google.com>
Message-ID: <541F8B2B-45C8-4869-A627-97B53F41E4F6@yahoo.com>


> On May 26, 2018, at 5:08 AM, Lectem <lectem at gmail.com <mailto:lectem at gmail.com>> wrote:
> 
>  
> Hi,
> I?ll start by saying that I love the fact we?re now talking about a common representation of packages !
>  
> The reason I say this is that extending pkg-config seems like it would help adoption rather then creating a completely new format. There is already a good portion of open source projects that already support pkg-config, so tweaking them to support more complicated scenarios seems easier than converting everything to a new format.
>  
> I?m not very familiar with pkg-config (working more in the Windows world) so excuse me if I?m wrong.
>  
> From what I remember it is very basic and relies on compiler flags being the same everywhere (ie gcc-like flags),

The flags are only written gcc-like for include paths, defines, library paths. Pkg-config(and cmake) converts these flags to the native versions. Outside of these flags they are tied to the compiler, which is the same for cmake as well.

> and does not provide any information about things such as ABI, C-runtime Library used (arguably could be represented as a package ?).

Yes, this can be another package that can be added to the `Requires` field.

> As far as I know, it assumes that the libraries are always compiled with the same compiler on the same system, hence has no knowledge of compatibility between compiler versions. 
> As you mentionned, it currently relies on -l for both libraries and linker flags, which would need to be changed.
>  
> so tweaking them to support more complicated scenarios seems easier than converting everything to a new format.
>  
> Wouldn?t that create more confusion ? I fear it?d end up as a python2 python3 issue, where both versions look alike but are incompatible.

These changes are all backwards-compatible(that is the current pkg-config files will continue to work). Having standard packages to represent different ABI or requirements can be supported with the current pkg-config. And, pkg-config already supports a `Provides` field(ie `Replaces` field).

Allowing a file instead of -l flag is a minor change. Pkg-config file format has not been static and has changed and evolved over the years(like adding the private fields or dollar sign escaping).

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180526/f774034a/attachment.html>

From alexander.sizov at arpanet.ru  Sun May 27 18:19:21 2018
From: alexander.sizov at arpanet.ru (alexander.sizov at arpanet.ru)
Date: Mon, 28 May 2018 01:19:21 +0300
Subject: [CMake] externalproject_add & install( target ... )
Message-ID: <4698111527459561@iva4-f774db2b5297.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180528/e8fc59b7/attachment.html>

From greenc at fnal.gov  Tue May 29 17:37:45 2018
From: greenc at fnal.gov (Chris Green)
Date: Tue, 29 May 2018 16:37:45 -0500
Subject: [CMake] Is there a way to obtain the current compiler standard flag?
Message-ID: <f2d1bd57-5b40-1edf-bf3b-3272fab1fc1b@fnal.gov>

Hi,

We have to use a utility (Root's rootcling/genreflex tool) as part of a 
custom command to parse some C++ headers. We are in the process of 
migrating from using raw -std= additions to compilation flags to use of 
CMAKE_CXX_STANDARD and friends. We need to pass the correct compiler 
flag to the invocation of rootcling in order to ensure headers are 
parsed correctly based on the CXX_STANDARD and CXX_EXTENSIONS 
properties, but we don't appear to be able to discover what it is. We 
could generate it from scratch like we did before, but it seems like it 
would be preferable to be able to pass it to the command as already 
calculated by CMake, perhaps via a generator expression.

Is there some way to do this already that I missed, or would this be an 
enhancement?

Thanks,

Chris.


From r030t1 at gmail.com  Tue May 29 22:33:36 2018
From: r030t1 at gmail.com (R0b0t1)
Date: Tue, 29 May 2018 21:33:36 -0500
Subject: [CMake] How to Compile with -municode for MinGW-w64
Message-ID: <CAAD4mYjK8LCKQdgTgGiefNCJU4Kunt9ZY0v0+hCwOFcZZoE2Mg@mail.gmail.com>

Hello,

I pass -municode in add_definitions but GCC still complains about the
wrong type on WinMain, citing it needs an LPSTR argument. With
-municode set it should require a LPWSTR and should be named wWinMain.
If I name the function wWinMain the linker complains about a missing
WinMain, which makes no sense. This works when I create a Makefile
myself.

CMakeLists.txt as follows.

cmake_minimum_required (VERSION 3.5)
project (mtktool)

list (
  APPEND
  CMAKE_MODULE_PATH
  "${CMAKE_CURRENT_LIST_DIR}/cmake"
)

set (mtktool_VERSION_MAJOR 0)
set (mtktool_VERSION_MINOR 0)
set (mtktool_VERSION_PATCH 0)

configure_file (
  "${PROJECT_SOURCE_DIR}/config.h.in"
  "${PROJECT_SOURCE_DIR}/config.h"
)

include_directories (
  "${CMAKE_CURRENT_SOURCE_DIR}"
)

add_definitions (
  -municode
  -mwindows
)

add_executable (
  mtktool
  mtktool.c
)

Cheers,
     R0b0t1

From petr.kmoch at gmail.com  Wed May 30 03:25:00 2018
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Wed, 30 May 2018 09:25:00 +0200
Subject: [CMake] How to Compile with -municode for MinGW-w64
In-Reply-To: <CAAD4mYjK8LCKQdgTgGiefNCJU4Kunt9ZY0v0+hCwOFcZZoE2Mg@mail.gmail.com>
References: <CAAD4mYjK8LCKQdgTgGiefNCJU4Kunt9ZY0v0+hCwOFcZZoE2Mg@mail.gmail.com>
Message-ID: <CAKohaZce+LMJ+tvS2GP6cNMYrSmD6qpjXes+mFEn1b=FhRdAhA@mail.gmail.com>

Hi R0b0t1,

add_definitions() is for adding preprocessor macro definitions (-D
options), not for general compilation options such as -m. You should set
the options as compilation options instead, using target_compile_options.
Also, -mwindows should probably not be passed directly; instead, use
CMake's built-in WIN32 argument in add_executable. Overall, it would look
like this:

include_directories (
  "${CMAKE_CURRENT_SOURCE_DIR}"
)

add_executable (
  mtktool
  WIN32
  mtktool.c
)

target_compile_options(
  mtktool PRIVATE -municode
)


Petr

On 30 May 2018 at 04:33, R0b0t1 <r030t1 at gmail.com> wrote:

> Hello,
>
> I pass -municode in add_definitions but GCC still complains about the
> wrong type on WinMain, citing it needs an LPSTR argument. With
> -municode set it should require a LPWSTR and should be named wWinMain.
> If I name the function wWinMain the linker complains about a missing
> WinMain, which makes no sense. This works when I create a Makefile
> myself.
>
> CMakeLists.txt as follows.
>
> cmake_minimum_required (VERSION 3.5)
> project (mtktool)
>
> list (
>   APPEND
>   CMAKE_MODULE_PATH
>   "${CMAKE_CURRENT_LIST_DIR}/cmake"
> )
>
> set (mtktool_VERSION_MAJOR 0)
> set (mtktool_VERSION_MINOR 0)
> set (mtktool_VERSION_PATCH 0)
>
> configure_file (
>   "${PROJECT_SOURCE_DIR}/config.h.in"
>   "${PROJECT_SOURCE_DIR}/config.h"
> )
>
> include_directories (
>   "${CMAKE_CURRENT_SOURCE_DIR}"
> )
>
> add_definitions (
>   -municode
>   -mwindows
> )
>
> add_executable (
>   mtktool
>   mtktool.c
> )
>
> Cheers,
>      R0b0t1
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180530/4283f8b8/attachment.html>

From robert.maynard at kitware.com  Wed May 30 15:38:48 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 30 May 2018 15:38:48 -0400
Subject: [CMake] Is there a way to obtain the current compiler standard
 flag?
In-Reply-To: <f2d1bd57-5b40-1edf-bf3b-3272fab1fc1b@fnal.gov>
References: <f2d1bd57-5b40-1edf-bf3b-3272fab1fc1b@fnal.gov>
Message-ID: <CAFzjYVpp8b98o3oUjo89qcruBygXvxmZCZTk33nX4T44mUwXhg@mail.gmail.com>

I am pretty sure you currently can't extract the compile flag information.
This would be an enhancement and would have to be done as a generator
expression.
On Tue, May 29, 2018 at 5:37 PM Chris Green <greenc at fnal.gov> wrote:

> Hi,

> We have to use a utility (Root's rootcling/genreflex tool) as part of a
> custom command to parse some C++ headers. We are in the process of
> migrating from using raw -std= additions to compilation flags to use of
> CMAKE_CXX_STANDARD and friends. We need to pass the correct compiler
> flag to the invocation of rootcling in order to ensure headers are
> parsed correctly based on the CXX_STANDARD and CXX_EXTENSIONS
> properties, but we don't appear to be able to discover what it is. We
> could generate it from scratch like we did before, but it seems like it
> would be preferable to be able to pass it to the command as already
> calculated by CMake, perhaps via a generator expression.

> Is there some way to do this already that I missed, or would this be an
> enhancement?

> Thanks,

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

From chuck.atkins at kitware.com  Wed May 30 16:12:16 2018
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Wed, 30 May 2018 16:12:16 -0400
Subject: [CMake] Is there a way to obtain the current compiler standard
 flag?
In-Reply-To: <CAFzjYVpp8b98o3oUjo89qcruBygXvxmZCZTk33nX4T44mUwXhg@mail.gmail.com>
References: <f2d1bd57-5b40-1edf-bf3b-3272fab1fc1b@fnal.gov>
 <CAFzjYVpp8b98o3oUjo89qcruBygXvxmZCZTk33nX4T44mUwXhg@mail.gmail.com>
Message-ID: <CAOXZzG5kcL_A=RadzcJsDmh9esYBTY=ry-NUSEurHLm9kUab=w@mail.gmail.com>

Hi Chris.

Try using the the CMAKE_CXX${std}_STANDARD_COMPILE_OPTION variable.  For
example, the folowing piece of CMake code:
cmake_minimum_required(VERSION 3.9)

project(foo CXX)

foreach(std IN ITEMS 98 11 14 17)
  message("C++${std} std flags: ${CMAKE_CXX${std}_STANDARD_COMPILE_OPTION}")
  message("C++${std} ext flags:
${CMAKE_CXX${std}_EXTENSION_COMPILE_OPTION}")
endforeach()

Wll generate for GCC on Linux:
-- The CXX compiler identification is GNU 8.1.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -std=c++98
C++98 ext flags: -std=gnu++98
C++11 std flags: -std=c++11
C++11 ext flags: -std=gnu++11
C++14 std flags: -std=c++14
C++14 ext flags: -std=gnu++14
C++17 std flags: -std=c++1z
C++17 ext flags: -std=gnu++1z
-- Configuring done

PGI on Linux:
-- The CXX compiler identification is PGI 18.4.0
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++ --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -A
C++98 ext flags: --gnu_extensions
C++11 std flags: --c++11;-A
C++11 ext flags: --c++11;--gnu_extensions
C++14 std flags: --c++14;-A
C++14 ext flags: --c++14;--gnu_extensions
C++17 std flags: --c++17;-A
C++17 ext flags: --c++17;--gnu_extensions
-- Configuring done


And for IBM XL on AIX:
-- The CXX compiler identification is XL 13.1.3
-- Check for working CXX compiler: /usr/bin/xlC
-- Check for working CXX compiler: /usr/bin/xlC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -qlanglvl=strict98
C++98 ext flags: -qlanglvl=extended
C++11 std flags: -qlanglvl=extended0x
C++11 ext flags: -qlanglvl=extended0x
C++14 std flags:
C++14 ext flags:
C++17 std flags:
C++17 ext flags:
-- Configuring done
-- Generating done

- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180530/b6138a92/attachment.html>

From dnadavewa at yahoo.com  Thu May 31 05:57:01 2018
From: dnadavewa at yahoo.com (David Henderson)
Date: Wed, 30 May 2018 23:57:01 -1000
Subject: [CMake] (no subject)
Message-ID: <1527760629.OKKMfuHOWNw9HOKKTf0UYb@mf-smf-ucb029c2>

http://moreover.singlepotatoes.com
David Henderson




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180530/9522d4c1/attachment.html>

From brad.king at kitware.com  Thu May 31 10:12:39 2018
From: brad.king at kitware.com (Brad King)
Date: Thu, 31 May 2018 10:12:39 -0400
Subject: [CMake] pkg-config file format versus CMake packages
In-Reply-To: <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
 <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
 <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>
 <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>
Message-ID: <c4c2158c-aac0-4079-c9fc-9b397b18ecb0@kitware.com>

On 05/25/2018 07:52 PM, Paul Fultz II wrote:
> What else is missing? 

The `.pc` format focuses on flat command-line strings that drop much
of the information used to generate them.  For example, if library
A depends on library B then the `.pc` file will record the link flags

   -L/path/to/A/lib -L/path/to/B/lib -lA -lB

There is no deep knowledge that the flags for "A" come from the current
package and the flags for "B" come from another package.  This
is okay as the *output* of a pkg-config query but such results could
be produced from an *input* format with a richer model.

The richer model is important when using more than one package at a
time.  If two packages have dependencies on B like the above example then
the -lB flags get duplicated.  Generating the proper combined order requires
deeper knowledge of the dependencies.  CMake's package configuration files
have this.

Some CMake "find modules" try to extract information from `.pc` files
by running pkg-config to get command lines.  They inevitably have to
parse the command lines and manually reconstruct things that could have
been put in the packaging files in a structured way in the first place.

> extending pkg-config seems like it would help adoption rather then
> creating a completely new format.

It would be nice if that would work.  However, most `.pc` files already
leave out much of the deeper information CMake likes to have.  Even
if we found a good way to represent that information in `.pc` files
projects would still need big updates to produce that information.

So long as the .pc or .cps format is supported by the pkg-config tool
I think adoption will be okay.

-Brad

From pfultz2 at yahoo.com  Thu May 31 13:41:06 2018
From: pfultz2 at yahoo.com (paul)
Date: Thu, 31 May 2018 12:41:06 -0500
Subject: [CMake] pkg-config file format versus CMake packages
In-Reply-To: <c4c2158c-aac0-4079-c9fc-9b397b18ecb0@kitware.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa>
 <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
 <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
 <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>
 <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>
 <c4c2158c-aac0-4079-c9fc-9b397b18ecb0@kitware.com>
Message-ID: <1e4471490bbaf7e9b935924f00dfcc6b2f6129cf.camel@yahoo.com>

On Thu, 2018-05-31 at 10:12 -0400, Brad King wrote:
> On 05/25/2018 07:52 PM, Paul Fultz II wrote:
> > What else is missing? 
> 
> The `.pc` format focuses on flat command-line strings that drop much
> of the information used to generate them.  For example, if library
> A depends on library B then the `.pc` file will record the link flags
> 
>    -L/path/to/A/lib -L/path/to/B/lib -lA -lB

No, it would record it as:

Requires: B

It would only record it as `-L/path/to/A/lib -L/path/to/B/lib -lA -lB` if B
didnt support pkg-config. This same problem exists for cmake if the user
doesn't use a separate target for library B.

> 
> 
> Some CMake "find modules" try to extract information from `.pc` files
> by running pkg-config to get command lines.  They inevitably have to
> parse the command lines and manually reconstruct things that could have
> been put in the packaging files in a structured way in the first place.

This is because cmake lacks native support for pkg-config. It only uses the
pkg-config CLI, which works fine for makefiles.

Instead cmake needs to make a target for each `.pc` found. This could be
possible if it used libpkgconf instead.

Even more so, we could support a `cmake_target` variable so .pc files could
specify the cmake target name.

> 
> > extending pkg-config seems like it would help adoption rather then
> > creating a completely new format.
> 
> It would be nice if that would work.  However, most `.pc` files already
> leave out much of the deeper information CMake likes to have.  Even
> if we found a good way to represent that information in `.pc` files
> projects would still need big updates to produce that information.

Projects would need to be updated for cps as well, but it seems a few tweaks
to pkg-config is more likely to be accepted than adding a new file format.

Paul

From brad.king at kitware.com  Thu May 31 14:01:37 2018
From: brad.king at kitware.com (Brad King)
Date: Thu, 31 May 2018 14:01:37 -0400
Subject: [CMake] pkg-config file format versus CMake packages
In-Reply-To: <1e4471490bbaf7e9b935924f00dfcc6b2f6129cf.camel@yahoo.com>
References: <CABUeae8TgD+qrbqAE1x0rmQTscbVTAN4DAk=9eCkcG9XOX-k_Q@mail.gmail.com>
 <1893894.FklTHkCckZ@ersa> <08e401f5-d705-e78e-f615-f413ed1ca654@kitware.com>
 <DCD9D595-378A-442D-8893-89F9B27007C7@yahoo.com>
 <cd2ecca0-082d-78b4-c43a-1e2f51af191a@kitware.com>
 <99555D27-8D59-47F6-91D9-D54343F9B7D4@yahoo.com>
 <2ee7d444-1273-7d5e-4fb7-d71c322b94c1@kitware.com>
 <AFF60858-0439-440D-B0B0-8ABEA199B585@yahoo.com>
 <c4c2158c-aac0-4079-c9fc-9b397b18ecb0@kitware.com>
 <1e4471490bbaf7e9b935924f00dfcc6b2f6129cf.camel@yahoo.com>
Message-ID: <8eeef840-fa2e-748a-b375-3ec745211bf1@kitware.com>

On 05/31/2018 01:41 PM, paul wrote:
> This is because cmake lacks native support for pkg-config. It only uses the
> pkg-config CLI, which works fine for makefiles.
> 
> Instead cmake needs to make a target for each `.pc` found. This could be
> possible if it used libpkgconf instead.

That sounds like a great feature that should be worked out first
to see how far it gets us.  Please bring it up on the developer list.

Thanks,
-Brad

From robert.maynard at kitware.com  Thu May 31 16:11:47 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 31 May 2018 16:11:47 -0400
Subject: [CMake] [ANNOUNCE] CMake 3.11.3 available for download
Message-ID: <CAFzjYVoNBSZj721hU076wxVavUrACR-1nGbjt31n9TiiZXp0Tg@mail.gmail.com>

We are pleased to announce that CMake 3.11.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.11.3 since 3.11.2:

Brad King (3):
      cmSystemTools: Revert GetRealPath implementation on Windows
      CPack: Fix cross-compilation of WiX generator
      CMake 3.11.3

Sander Vrijders (1):
      TestDriver: Replace strncpy with strcpy