Re: [CMake] Build dependent targets

[Eric Noulard]

Le mar. 19 nov. 2019 à 11:52, Ellon Paiva  a écrit :

> Hi Eric,
>
> On 11/19/19 11:10 AM, Eric Noulard wrote:
>
>
>
> Le mar. 19 nov. 2019 à 11:03, Ellon Paiva  a écrit :
>
>> Hi,
>>
>> I was wondering: is there any way to compile all targets that depend on
>> a given target ? (i.e. the "dependent targets", if my English does not
>> fail).
>>
>> In my particular case, I have a huge project that contains many libs and
>> executables, and I would like to check that the targets that depend on
>> the library I'm working on do not break with my modifications, but I
>> wouldn't like to compile the whole project every time since not all
>> targets depends on my lib.
>>
>
> Correct me if I'm wrong but if you build the whole project once, then
> modify the lib,
> the next "whole build"  should only rebuild the necessary part ? i.e.
> it'll rebuild
> the lib and all targets that depends on it.
>
>
> Indeed, if I "whole build' once and modify the lib I would only rebuild
> the necessary part, except that I do not work alone on this project, and
> sometimes some rebase is needed to incorporate changes from other people on
> code not related to the lib I'm working on, and this would trigger more
> build than my changes would.
>

Yes I see this is to be expected.
Avoiding this kind of rebuild may be tricky because any
addition/modification of a CMakeLists.txt will trigger a CMake rerun anyway.


> Also it may happen that a new dependent to the lib I'm working on may be
> added to the code base by one of these rebases. In this case the only way
> for me to check if my changes broke anything would be to do a whole build
> again, but this would also build many things not related to my work... I
> hope I'm being clear here. :-)
>

Yes you are.

I think that to achieve what you want you need to craft yourself some
tooling using cmake file api.
Your tool would be able to instrospect the dependent targets using
https://cmake.org/cmake/help/git-stage/manual/cmake-file-api.7.html#codemodel-version-2-target-object
and trigger the build of the list of dependent target.

I would like to avoid rebuilding targets due to changes introduced by my
> workmates that are not related to the part of the code base I'm working on.
>

I don't know your team workflow but avoiding rebuild due to other change
may reduce to avoiding rebasing you current work on top of other work?
AIFAIK each time you rebase, you may face whole rebuild, this is not really
a CMake issue.

If the unwanted rebase is indeed necessary then may be your team can try to
setup a shared compilation cache in order to speed-up the rebuild?
see: https://crascit.com/2016/04/09/using-ccache-with-cmake/ for using
ccache with CMake.
sse: https://ccache.dev/manual/latest.html#_sharing_a_cache on how to share
a ccache directory.

-- 
Eric
-- 

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Build dependent targets

[Eric Noulard]

Le mar. 19 nov. 2019 à 11:03, Ellon Paiva  a écrit :

> Hi,
>
> I was wondering: is there any way to compile all targets that depend on
> a given target ? (i.e. the "dependent targets", if my English does not
> fail).
>
> In my particular case, I have a huge project that contains many libs and
> executables, and I would like to check that the targets that depend on
> the library I'm working on do not break with my modifications, but I
> wouldn't like to compile the whole project every time since not all
> targets depends on my lib.
>

Correct me if I'm wrong but if you build the whole project once, then
modify the lib,
the next "whole build"  should only rebuild the necessary part ? i.e. it'll
rebuild
the lib and all targets that depends on it.

Do you you want to avoid building the whole project in the first place or
does the
second whole build trigger more than necessary target build?



-- 
Eric
-- 

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] CHECK_CXX_COMPILER_FLAG doesn't give correct result for -fsanitize=address

[Eric Noulard]

Le jeu. 24 oct. 2019 à 22:32, Turner, Adrian Keith via CMake <
cmake@cmake.org> a écrit :

> Hi CMake Mailing List,
>
>
> I am using the CHECK_CXX_COMPILER_FLAG directive in a CMake file to
> detect whether the compiler uses the "-fsanitize=address" compiler flag.
> I'm using the g++ 7.3.0 compiler which supports this flag but the 
> CHECK_CXX_COMPILER_FLAG
> directive incorrectly determines that this flag is not supported.
>

You get appropriate answers to your initial question.

I'll add an alternative to your hand-crafted way to get sanitizers working.

I'm using: https://github.com/arsenm/sanitizers-cmake
and I find it easy to use and convenient when compiling with either clang
or gcc.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Alternative locations for boost in cmake

[Eric Noulard]

Le ven. 25 oct. 2019 à 09:55, Mahmood Naderan via CMake  a
écrit :

> Even with the latest 3.15.4, I get the same error
>
>
> $ cmake --version
> cmake version 3.15.4
>
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
> $ cmake -DBoost_NO_SYSTEM_PATHS=ON
> -DBOOST_INCLUDE_DIR=/storage/users/mnaderan/boost_1_65_1/build/include/
> -DBoost_LIBRARY_DIRS=/storage/users/mnaderan/boost_1_65_1/build/lib/
> -DBoost_ADDITIONAL_VERSIONS=1.65.1 ..
>


could you try:
$ cmake -DBoost_NO_SYSTEM_PATHS=ON
-DBOOST_ROOT=/storage/users/mnaderan/boost_1_65_1
-DBoost_ADDITIONAL_VERSIONS=1.65.1

you have a "case discrepancy" between:
BOOST_INCLUDE_DIR
and
Boost_LIBRARY_DIRS

and the error says:

"missing: Boost_INCLUDE_DIR"

FindBoost should be case tolerant for backward compat' issue but may be
this does not work when specifying hint var in mixed case (wild guess).

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Help request for hierarchical directory example

[Eric Noulard]

Le ven. 18 oct. 2019 à 12:53, David Aldrich 
a écrit :

> Hi
>
>
>
> I'm learning how to use hierarchical directories in CMake and am trying to
> get an example to work that I saw on YouTube. The example isn't doing what
> I expect so I would be grateful for some help in understanding why.
>
>
>
> I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.
>
>
>
> I have a project called 'cmake-good' that should build library
> 'libsay-hello.a' and executable 'cmake-good'.
>
>
>
> Here's the directory tree (excluding CMake artifacts which I don't think I
> need to show):
>
>
>
> ├── CMakeLists.txt
>
> ├── build
>
> │   ├── CMakeCache.txt
>
> │   ├── CMakeFiles
>
> │   ├── Makefile
>
> │   ├── cmake_install.cmake
>
> │   ├── hello-exe
>
> │   │   ├── Makefile
>
> │   │   ├── cmake-good
>
> │   └── say-hello
>
> │   ├── Makefile
>
> │   └── libsay-hello.a
>
> ├── hello-exe
>
> │   ├── CMakeLists.txt
>
> │   └── main.cpp
>
> ├── say-hello
>
> ├── CMakeLists.txt
>
> └── src
>
> └── say-hello
>
> ├── hello.cpp
>
> └── hello.hpp
>
>
>
> Here are the CMakeLists.txt files:
>
>
>
> 1) Top level CMakeLists.txt:
>
>
>
> cmake_minimum_required(VERSION 3.10)
>
> project(MyProject VERSION 1.0.0)
>
> add_subdirectory(say-hello)
>
> add_subdirectory(hello-exe)
>
>
>
> 2) hello_exe/CMakeLists.txt:
>
>
>
> add_executable(cmake-good main.cpp )
>
> target_link_libraries(cmake-good PRIVATE say-hello)
>
>
>
> 3) say-hello/CMakeLists.txt:
>
>
>
> add_library(
>
> say-hello
>
> src/say-hello/hello.hpp
>
> src/say-hello/hello.cpp
>
> )
>
> target_include_directories(say-hello PUBLIC
> "${CMAKE_CURRENT_SOURCE_DIR}/src")
>
>
>
> My problem is that I expect to see:
>
>
>
> hello-exe/cmake-good
>
> say-hello/libsay-hello.a
>
>
>
> but I see:
>
>
>
> build\hello-exe\cmake-good
>
> build\say-hello\libsay-hello.a
>
>
>
> Why is that?
>

Because build/ is your build directory and you apparently did an
out-of-source build (which is good practice)
see :
https://gitlab.kitware.com/cmake/community/wikis/FAQ#out-of-source-build-trees

You should have done something like:

cd cmake-good/build
cmake ..
make

In this case everything the build is generating (CMake artefact, build
artefact etc...) gets written build/
the directory hierarchy in build will have the same structure as your
source tree.

This is an expected behaviour.



-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 14:30, Eric Noulard  a
écrit :

>
>
> Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
> jakub.zakrzew...@scheer-group.com> a écrit :
>
>> --
>> *From:* CMake  on behalf of Eric Noulard <
>> eric.noul...@gmail.com>
>> *Sent:* 10 October 2019 12:05
>> *To:* DIXON, MARK C.
>> *Cc:* cmake@cmake.org
>> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling
>>
>>
>> > No they can't because the maximum size is burried into the binary ELF
>> file,
>> > that why CMake "reserve" some space with many "" in order to replace
>> BUILD_RPATH with INSTALL_RPATH when doing
>> > 'install'.
>>
>> Interesting.
>> So you're saying that this:
>> https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319
>> does not really work? (An honest question)
>>
>
> Nope I meant that my manual page forr chrpath says:
>-r  | --replace 
>   Replace current rpath or runpath setting with the path
> given.  The new path must be shorter or the same length as the current path.
>
> patchelf does not seem to have this limitation.
> I remember trying and being hit by that issue, but I did not tried it
> recently.
> I'll try again and come back to you.
>

with chrpath try to replace an rpath with a longer one I get:
new rpath '/../lib:/purposely/too/long/rpath/hdsjds/dshkjhdsk/dsgdjsj' too
large; maximum length 104

with patchelf is works with an intriguing warning:
warning: working around a Linux kernel bug by creating a hole of 2093056
bytes in ‘/path/to/executable’

which seems to be a resolved issue:
https://github.com/NixOS/patchelf/issues/92

after that on the modified executable,
chrpath is printing weird output when asking to read rpath.
patchelf does properly print modified rpath.

I think the SO article gives enough reference for this:
https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary

So I was wrong, thank you for your honest question Jakub.
I learned something usefull thanks to you.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
jakub.zakrzew...@scheer-group.com> a écrit :

> --
> *From:* CMake  on behalf of Eric Noulard <
> eric.noul...@gmail.com>
> *Sent:* 10 October 2019 12:05
> *To:* DIXON, MARK C.
> *Cc:* cmake@cmake.org
> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling
>
>
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many "" in order to replace
> BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Interesting.
> So you're saying that this:
> https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319
> does not really work? (An honest question)
>

Nope I meant that my manual page forr chrpath says:
   -r  | --replace 
  Replace current rpath or runpath setting with the path
given.  The new path must be shorter or the same length as the current path.

patchelf does not seem to have this limitation.
I remember trying and being hit by that issue, but I did not tried it
recently.
I'll try again and come back to you.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 13:08, DIXON, MARK C.  a
écrit :

> On Thu, 10 Oct 2019, Eric Noulard wrote:
> ...
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many "" in order to replace
> > BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Hi Eric,
>
> Interesting - any ideas on how big the padding is?
>


Not sure, but I bet CMake is reserving as much space as needed for the
forthcoming INSTALL_RPATH
(as opposed to BUILD_RPATH) he knows when specified in the CMakeLists.txt
I you rebuild the concerned from source try configuring it with a stupidly
long CMAKE_INSTALL_RPATH
i.e.

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath


Then, you can surely have a look using  chrpath -l lib_or_exe.


> > Note however that you should be able to "delete" RPATH: chrpath -d
> > and then rely on LD_LIBRARY_PATH, ld.so.config, etc
> >
> > The thing I don't quite understand why you need to replace/amend RPATH.
> In
> > my (very personal) use case when I have to integrate third-party
> software:
>
> My use case is where:
>
> - I install some software, made available to others via environment
>modules (http://modules.sourceforge.net/).
>
> - The installed software is dynamically linked to other libraries, also
>installed via environment modules.
>
> - I don't want to make people load modules for prerequisite libraries
>(and prerequisites for the prerequisites...) to use the software.
>


ok I see, I did use modules a long time ago on some now oldish supercomputer
in order to play with various compilers of library versions.


>
> A complication is that I end up having to build lots of copies of the same
> software but built with different prerequisites... so it has to be
> automated on top of the upstream project's build system.
>
> For applications using libraries, I've tended to use wrapper scripts as it
> means fewer arguments with build systems. But for libraries using
> libraries, rpath's the only real option.
>

No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
Removing rpath is easy; chrpath -d lib_or_exe


> My rpath can get quite long.
>

Yes now I see why, depending on the number of  prerequisite you have and
how many
modules are loaded.


> ...
> > If the developers of the software you are using have chosen in their
> CMake
> > build-system to define an install RPATH your only safe bet
> > is probably to build & install the software at your favorite location or
> > propose an upstream patch for supporting unspecified RPATH.
> >
> > But may be I miss something in your use case?
>
> I guess I should be proposing upstream patches but, there are so many
> software projects to do this for, it has always been simpler to carry
> forward a small patch or patches. Perhaps I should be a better citizen.
>

It may not be tractable to file dozen of upstream patch and wait for
feedback
but in the case the build system does not offer a way to chose install
rpath content I think you are stucked
(beside remove rpath).


In this case, what feels easiest is to keep a patch commenting out the
> developer's RPATH definition in CMakeLists.txt, identified by Jakub
> earlier.
>

Yes I agree. However I my hypothesis of space reservation in RPATH by cmake
is write
you may want to replace with something that fits your needs and not simply
commenting it out.
Or may be  commenting it out and specify CMAKE_INSTALL_RPATH on the command
line:

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath

https://cmake.org/cmake/help/v3.15/variable/CMAKE_INSTALL_RPATH.html

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] lintian errors when using cpack

[Eric Noulard]

Le jeu. 10 oct. 2019 à 11:58, Gillman, Matthew  a
écrit :

> Hi Kerstin
>
>
>
> Sorry, I forgot to list them. Right now I only have the following set:
>
>
>
> SET(CPACK_GENERATOR "DEB")
>
> SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me ")
>
> INCLUDE(CPack)
>
>
>
> I will try adding the two you suggest and see how it goes, but I wouldn’t
> be surprised if there were others I need too.
>

You may review CPack Deb feature in the documentation as well:
https://cmake.org/cmake/help/v3.15/cpack_gen/deb.html

I’ve had a look and I can’t see a file called `postint`.
>
>
>
> Thanks for your help
>
>
>
> Matthew
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 10:36, DIXON, MARK C.  a
écrit :

> On Wed, 9 Oct 2019, Aaron Cohen wrote:
>
> > Is it not feasible to just let the build system do whatever it is going
> to
> > and use "chrpath" or "patchelf" to change the rpath after-the-fact?
>
> Thanks for the suggestion, but I need to add directories to the rpath: I
> believe that neither utility allows it to increase in size.
>


No they can't because the maximum size is burried into the binary ELF file,
that why CMake "reserve" some space with many ";;;" in order to replace
BUILD_RPATH with INSTALL_RPATH when doing
'install'.

Note however that you should be able to "delete" RPATH: chrpath -d
and then rely on LD_LIBRARY_PATH, ld.so.config, etc

The thing I don't quite understand why you need to replace/amend RPATH. In
my (very personal) use case when I have to integrate third-party software:

1a) I compile them from source and install them using the install prefix *I
need*. For cmake enabled build
 the RPATH will be updated with the one I need *during install*

2a) I use relocatable binary package (of any kind rpm, deb, or even tar.gz)
for which I know that RPATH are
  relative which can adapt to the location where I put them.
  If I cannot find a relocatable binary package then I go back to 1a).

As noted by Hendrik not every software developer are aware of the need for
relocation so they may bury non-relocatable rpath in their buildsystem.

Note that there is usually 2 options for CMake buildsystem and install
RPATH.
You can either:
 1. set some install RPATH (preferably in a relocatable way using $ORIGIN)
 2. don't specify install RPATH at all and let the final user/integrator
setup LD_LIBRARY_PATH or ld.so.config etc...

This is quite well summarized here:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

If the developers of the software you are using have chosen in their CMake
build-system to define an install RPATH your only safe bet
is probably to build & install the software at your favorite location or
propose an upstream patch for supporting unspecified RPATH.

But may be I miss something in your use case?

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] ?= Looking for an explanation: What exactly means "install" in cmake language

[Eric Noulard]

Le mar. 8 oct. 2019 à 12:52, Cornelis Bockemühl  a
écrit :

> One more finding: the "magic" that QtCreator does to start example also
> without any additional fiddling with the RPATH: it already contains a
> RUNPATH, and this points to the shared library libshlibbu.so in it's build
> tree location, not in the installed location - and the same with
> libshlibbu.so.
>
> And the "install" process indeed handles the RPATH/RUNPATH: it simply
> removes it!
>
> Meaning: it I want to end up what I initially expected, I have to do two
> additional things manually (or maybe there is an automatic way??):
>
> 1) copy the shared libraries to the "example" install directory tree
> 2) add some RPATH or RUNPATH setting to all the binaries that need it
>

You should read how RPATH handling is done with CMake.
see:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

As you already noted there is a build RPATH and an install RPATH.
The first is used when building the second replace the first after
installation takes place.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Looking for an explanation: What exactly means "install" in cmake language?

[Eric Noulard]

Le lun. 7 oct. 2019 à 16:49, Cornelis Bockemühl  a
écrit :

> Thanks to both you and J Decker: I would say that this is still the part
> that I understood! So basically the word "install" in cmake language could
> be replaced by "copy" more or less in common human language - right?
>

Nope I oversimplified.
This is not a bare copy, e.g. the runtime path (a.k.a. RPATH or RUNPATH) is
updated as well.

But then, if it is about "installing" a "target", which is libraries in my
> case, I would expect the shared libraries to be copied - no?
>

Yes the shared lib should be coped and its RPATH updated.


> And this is exactly what does not happen - for no obvious reason! Because
> some days ago it even happened in my project ONCE - and then not any more.
> But debugging is not easy because since that moment I changed many things,
> and basically the reason for my question is that I have no clear idea what
> EXACTLY should happen if I put a
>
> install(TARGETS mylibrary)
>
> into my CMakeLists.txt. Well, like you explained, and like what I also
> thought I had understood: nothing should happen during the configure and
> generate runs of cmake, and also not during the "ninja all" build run, but
> only during the "ninja install". or else cmake --build . --target install
> (which in turn calls ninja in my case). Indeed I observed that it does a
> build for "all" first if the initial project is not up to date.
>
> But then it tells me that it is successfully "installing" mylibrary, but I
> see no shared library appearing in the install tree! Or rather: it happened
> once, but not any more - and I should find out what is missing...
>

.
Are building out-of-tree? (Are your source tree and build tree separate
dir?)
If so, did you try removing the entire build tree and try again ?


May be there is probably some mixup with your install DESTINATION in your
install command.

>
> My current workaround is indeed that I am trying to avoid the install step
> altogether and build a crazy construction with configure_file stuff in
> order to get the libraries to the right place - and I know pretty well that
> this is NOT the way how things should be done properly. But I am afraid I
> will be ready with this workaround way faster than I will understand what
> is going on during this miraculous "install" process!


Provide us with a stripped down non-working example and we may dig into it.
Otherwise it is very difficult to guess what is happening in your
particular case.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Looking for an explanation: What exactly means "install" in cmake language?

[Eric Noulard]

I'll try some answer.
In order to illustrate my words have a look at this figure:
https://raw.githubusercontent.com/dev-cafe/cmake-cookbook/master/figures/cmake-times/cmake-times.jpg

1) When cmake "runs" (both cmake and generation times) you get your build
tree configured and populated
2) At build times all build artefact are constructed *in the build tree*
somewhere
3) Then when you *install* you copy files/targetd/... from the build tree
down to the "install location".

The fact that CMake install command are "processed" during 1) does not copy
anything before actual [generated] install command are executed during 3).

Le lun. 7 oct. 2019 à 15:44, Cornelis Bockemühl  a
écrit :

> Constantly I am stumbling over the word "install" in the context of cmake
> scripts - while it is pretty clear that the word cannot mean what nowadays
> people would understand by that term! But even reading the docs forwards
> and backwards, studying examples and some generic cmake tutorials I still
> do hot have a PRECISE idea about what it is actually doing and what the
> purpose is. Well, I can see everywhere HOW it is done - but it is sometimes
> an advantage if you also know WHAT!
>
> I know that this question is probably so stupid that I do not really
> expect anybody to answer it here in the mailing list, but maybe somebody
> can point me to a resource that explains it in a language that a "mere
> mortal programmer" can follow?
>
> So far I have a certain kind of understanding, and sometimes it looks like
> this is correct, but then again I have my certain doubts. I am using
> install(TARGETS), install(FILES) and install(EXPORT) so far, and the way I
> am doing it I mostly picked from some general intros and tutorials. And
> from what I understand, this is what I expect to happen:
>
> install(FILES): some files are copied from some location in the build tree
> to some installation location
> install(EXPORT): some cmake script is written that a "derived" project can
> call (through find_package) in order to get knowledge about my project
> install(TARGET): not really an idea what should happen: also some copying
> from build tree to installation tree I suppose
>
> Now I also learned that the install step does not happen during a normal
> build "all" - like "ninja all", but requires an extra "ninja install" step.
> And also I saw that you can adapt the target of the installation process
> like this in your project - if you never ever expect the build to be
> "installed" anywhere else:
>
> set(CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR}/../install CACHE PATH
> "" FORCE)
>
> With this I would expect to generate an install folder in parallel to the
> bin, lib64 and other folders in the build tree, collecting there all the
> "products" of the build for further processing by a derived project.
>

Nope. CMake will be using the declarative install(...) command
and CMAKE_INSTALL_xxx variables values *at CMake times* in order to
generate scripts
that will be run when you do "ninja install" / "make install".



> But what I see is actually - almost nothing!
>
> Well, the install(FILES) actually copies a file, and the install(EXPORT)
> indeed generates a cmake script, but from the install(TARGET) I see no
> effect: the install folder remains completely empty! Still I see in the log
> many things like "Installing: /.../install/bin/" - but I never
> find then  in that indicated location. But yes, it said
> "installing", not "copying" - so I am back to my initial question: what the
> hell is "installing" in cmake language?
>

Copying some build tree artefact to the specified install location.


> So basically my problem is: I cannot judge whether my script is working
> because I simply do not know what SHOULD be the effect of install(TARGET)!
>
> Ah yes, my build tree is after a "normal build" ("all", not "install")
> full of cmake_install.cmake files that would probably have something to do
> with that "installation" process, but what? Am I supposed to call them on
> any occasion or are they supposed to be called automatically at some moment?
>

cmake_install.cmake are cmake scripts that are executed when you do
"ninja install" i.e. when you build the pseudo target "install".


> Finally, I managed to get also some find_package() working for my project.
> The "heart" of this is a Config.cmake script that I am generating
> during the project build, and which I can write in whatever way I want. For
> example, I am reading everywhere that I am supposed to do an
> install(EXPORT) in order to make that find_package() happen, but since I do
> not really understand what it is supposed to do, and I also see that I can
> simply write that Config file in such a way that it picks things from where
> the build process puts them, I do not really see the point.
>
> In other words: I tend to simply write config scripts for the import that
> rely on the build tree and simply skip that install step - because getting
> this to work is so 

Re: [CMake] Adding CRC32 to ELF

[Eric Noulard]

Le lun. 7 oct. 2019 à 14:41, Vincent van Beveren 
a écrit :

> Hello everyone,
>
> I'm setting up a new build targeting an embedded platform (LM32) and
> trying to integrate a CRC32 into the resulting ELF. I have previously
> done this using plain Makefiles with the following steps (pseudo code):
>
> target.elf: 
> link  --symbol CRC_VALUE=0 intermediate.elf
> objcopy --binary intermediate.elf intermediate.bin
> link  --symbol CRC_VALUE=`crc32 intermediate.bin` target.elf
> rm intermediate.bin
>
> Now I would like to achieve the same thing with CMake. I'm using
> add_executable with multiple targets. The end of my CMakeLists.txt looks
> like this, where F_GEN contains generic source files and F__* source
> files specific for that variant of the build:
>
> # [...defining of cross compiler, and source files, some compile flags,
> etc...]
> # Educate the linker
> add_link_options(
>  -nostartfiles
>  -nodefaultlibs
>  -nostdlib
>  -Wl,--gc-sections
>  -T ${CMAKE_SOURCE_DIR}/${P_SRC}/romram.ld
>  -Wl,--defsym=CRC_VALUE=0
>  -Wl,--defsym=_start=0
>  )
>
> # DOM v2 target
> add_executable( clb_v2_dom.elf ${F_GEN} ${F__DOM} )
> target_compile_definitions(clb_v2_dom.elf PUBLIC -DDOM -DCLBV2 )
>
> # BASE v2 target
> add_executable( clb_v2_base.elf ${F_GEN} ${F__BASE} )
> # TODO migrate define 'DUBASE' -> 'BASE'
> target_compile_definitions(clb_v2_base.elf PUBLIC -DDUBASE -DBASE -DCLBV2)
>
> # Golden v2 target
> add_executable( clb_v2_golden.elf ${F_GEN} ${F__GLD} )
> target_compile_definitions( clb_v2_golden.elf PUBLIC -DGOLDEN -DCLBV2 )
>
> ==
>
> As you can see CRC_VALUE is now simply defined 0 for every target. Which
> works well for compiling but during runtime poses a problem to the ROM
> verification procedure. What would a 'proper' way be of adding a CRC to
> an ELF file be using CMake, and be different for each target. Any help
> is welcome!
>

I would try to add a set of custom command as POST_BUILD event.
https://cmake.org/cmake/help/v3.15/command/add_custom_command.html#build-events

add_custom_command(TARGET clb_v2_base.elf POST_BUILD

 COMMAND crc32 $
> $.crc32
   COMMAND ${CMAKE_C_COMPILER}
--symbol $.crc32
 $
  )

I don't know if the linker can read the computed crc32 from the previously
generated file but you get the idea.
Moreover if you want to easily collect objects used for linking a target
you may need to use an intermediate
OBJECT library in order to be able to retrieve $
see:
https://cmake.org/cmake/help/latest/command/add_library.html#object-libraries
i.e. replace:
add_executable( clb_v2_dom.elf ${F_GEN} ${F__DOM} )

by
add_library(clb_v2_dom.objs OBJECT ${F_GEN} ${F__DOM})
add_executable(clb_v2_dom.elf  $)

and then:

add_custom_command(TARGET clb_v2_dom.elf POST_BUILD

 COMMAND crc32 $
> $.crc32
   COMMAND
${CMAKE_C_COMPILER} $
--symbol $.crc32  $
  )

If this looks ok to you I would then write my own

lm32_add_executable that would wraps this up in order to be called as:

lm32_add_executable(EXECUTABLE clb_v2_dom.elf
 SOURCES ${F_GEN} ${F__DOM})




> Kind regards,
> Vincent
>
>
>
> --
> National Institute for Subatomic Physics Nikhef
> Department of Computer Technology
> Science Park 105
> 1098 XG AMSTERDAM
>
> tel.  : +31 (0)20 592 2032
> e-mail: v.van.beve...@nikhef.nl
> site  : http://www.nikhef.nl/~vincentb
>
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Packaging a directory with CPack RPM

[Eric Noulard]

Le lun. 16 sept. 2019 à 18:12, Ashish Sadanandan <
ashish.sadanan...@gmail.com> a écrit :

> On Thu, Sep 12, 2019 at 4:57 AM Eric Noulard 
> wrote:
> >
> >
> >
> > Le jeu. 12 sept. 2019 à 02:27, Ashish Sadanandan <
> ashish.sadanan...@gmail.com> a écrit :
>
> >
> > Now may be you can tell CPack to ignore some of you installed
> files/directory by using: CPACK_RPM_USER_FILELIST
> >
> https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator
> >
>
> Sorry, I should've mentioned in the original email that the files are
> required, so ignoring is not what I want.
>

My answer wasn't clear, using   CPACK_RPM_USER_FILELIST enables you to
specify the de %file and/or %dir
directive you want and it thus make CPackRPM avoid using its ownn generated
file list  (i.e. ignore it).

You can somehow override the builtin file and dir discovery of CPack.

As the doc says:
"Since the CPack RPM generator is generating the list of files (and
directories) the user specified files of the
CPACK_RPM__USER_FILELIST list will be removed from the generated
list. If referring to directories do not add a trailing slash."

>> I'm not claiming this is the reason for CPack being slow, I came across
> this while investigating performance and if nothing else, this will result
> in a cleaner looking spec file.
> >
> >
> > For performance sake you can try CPACK_RPM_USER_BINARY_SPECFILE,
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> > and handcraft your "user" spec file in order to see if it helps the
> packaging performance.
> > and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more
> timed traces of CPackRPM execution.
> >
>
> Thanks, this looks promising but I'm having trouble getting CPack to
> use my custom spec file. This is what I've added to my CMakeLists.txt
> so far (using cmake 3.6.3)
>


Then be sure to read the corresponding documentation:
https://cmake.org/cmake/help/v3.6/module/CPackRPM.html



> # We're already using component install
> set(CPACK_RPM_COMPONENT_INSTALL ON)
> set(CPACK_RPM_TESTS_FILE_NAME
>
> "${CPACK_PACKAGE_NAME}-tests-${CPACK_PACKAGE_VERSION}-${CPACK_RPM_PACKAGE_RELEASE}.${CMAKE_SYSTEM_PROCESSOR}.rpm"
> )
> install(DIRECTORY ${CMAKE_BINARY_DIR}/tests
> DESTINATION tests
> COMPONENT tests
> )
> set(CPACK_RPM_TESTS_USER_BINARY_SPECFILE
> "${CMAKE_CURRENT_SOURCE_DIR}/tests.spec"
> )
>
> But CPack is still generating a spec file for the tests RPM instead of
> using my spec file. I've even tried using an absolute path to the spec
> file but still the same behavior. What am I doing wrong?
>

Difficult to say without seeing your CMakeLists.txt or verbose CPack output.

Did you set those variables before or after include(CPack) ?
Those vars should be set *before*  include(CPack) otherwise they won't be
taken into account.

Did you try running CPack in debug mode:

cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

in order to have more verbose output?
-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Packaging a directory with CPack RPM

[Eric Noulard]

Le jeu. 12 sept. 2019 à 02:27, Ashish Sadanandan <
ashish.sadanan...@gmail.com> a écrit :

> Hello,
> I'm using CPack to create RPMs for an application. I have this working but
> the CPack step is quite slow. While investigating this, I noticed that all
> files in a directory I'm packaging, which contains a large number of small
> files, is being listed in the spec file.
>
> For instance, say I have
>
> set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
> install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
> DESTINATION foo
> COMPONENT myapp
> )
>
> In the %files section I see
>
> %files
> %dir /opt/myapp/foo
> " /opt/myapp/foo/file1"
> " /opt/myapp/foo/file2"
> ...
> " /opt/myapp/foo/file6"
>
> If I were writing the spec file by hand, this entire section could be
> replaced by a single line
>
> %files
> /opt/myapp/foo
>

CPack has no idea that the list of files are coming from an installed
*directory*, because CPack is not doing the install CMake is.
Thus CPackRPM and other CPack generators collect all installed bits inside
a given [temporary] prefix directory.

Now may be you can tell CPack to ignore some of you installed
files/directory by using: CPACK_RPM_USER_FILELIST

https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator



> RPM will package all files within the directory if you specify the
> directory under %files (
> http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the
> "The %dir Directive" section)
> Is there an option to list just the directory instead of recursively
> listing all contained files within the directory?
>

AFAIK, No there is not.


I'm not claiming this is the reason for CPack being slow, I came across
> this while investigating performance and if nothing else, this will result
> in a cleaner looking spec file.
>

For performance sake you can
try CPACK_RPM_USER_BINARY_SPECFILE,
CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
and handcraft your "user" spec file in order to see if it helps the
packaging performance.
and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more timed
traces of CPackRPM execution.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to use --build and --parallel?

[Eric Noulard]

Le ven. 9 août 2019 à 06:44, Heng Zhou  a écrit :

> I am working on ubuntu 16.04, so the generator is the default "Unix
> Makefiles" which I did not specify. I don't think it is related to the lack
> of the parallel job number (I added 4 but with the same error). I just
> wanna confirm whether I wrote the syntax correctly. An example would
> suffice.
>

this sequence works for me on Debian 9 and CMake 3.13.2:

cd buildir
cmake -G /path/to/srcdir
cmake --build --parallel .


What kind or error do you get when you do that?



> On Fri, Aug 9, 2019 at 12:25 AM Eric Noulard 
> wrote:
>
>>
>>
>> Le ven. 9 août 2019 à 04:40, Heng Zhou  a écrit :
>>
>>> Hi,
>>>
>>> I want to build a project using all cores of the machine. After cmake
>>> .., I have tried
>>>
>>> cmake --build --parallel .
>>>
>>> and
>>>
>>> cmake --build . --parallel
>>>
>>> , but none of them works. So, what is the correct usage of --build and
>>> --parallel when using them together? I have read the documentation
>>> https://cmake.org/cmake/help/latest/manual/cmake.1.html#build-tool-mode
>>> but still could not figure out. Thanks for your help.
>>>
>>
>> Try providing a number of parallel job after the --parallel option.
>> Depending on the native build tool used you won't get automatic number of
>> parallel jobs.
>> Which CMake generator are you using?
>>
>>> --
>>>
>>> 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
>>>
>>

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to use --build and --parallel?

[Eric Noulard]

Le ven. 9 août 2019 à 04:40, Heng Zhou  a écrit :

> Hi,
>
> I want to build a project using all cores of the machine. After cmake ..,
> I have tried
>
> cmake --build --parallel .
>
> and
>
> cmake --build . --parallel
>
> , but none of them works. So, what is the correct usage of --build and
> --parallel when using them together? I have read the documentation
> https://cmake.org/cmake/help/latest/manual/cmake.1.html#build-tool-mode
> but still could not figure out. Thanks for your help.
>

Try providing a number of parallel job after the --parallel option.
Depending on the native build tool used you won't get automatic number of
parallel jobs.
Which CMake generator are you using?

> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] find_file - strange behavior when using Android toolchain

[Eric Noulard]

Le mer. 31 juil. 2019 à 11:19, Stephan Menzel  a
écrit :

> Thank you, Eric and Ugesh,
>
> Am Mi., 31. Juli 2019 um 09:16 Uhr schrieb Eric Doenges  >:
>
>> My experience has been that find_file and friends behave in unexpected
>> ways when you set CMAKE_SYSROOT. In our toolchain files, we set
>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>>
>> as suggested in the cmake-toolchains(7) documentation. We then add the
>> path to the top-level directory where we keep all our thirdparty
>> dependencies to CMAKE_FIND_ROOT_PATH, as otherwise find_package and
>> find_path cannot find anything even when we give them the absolute path
>> where to search (the find_file documentation suggests that the elements of
>> the CMAKE_FIND_ROOT_PATH are prepended to the paths specified in the
>> find_file arguments, but that does not seem to happen if the search paths
>> are subpaths of the CMAKE_FIND_ROOT_PATH). My guess would be that the NDK
>> does something similar, meaning you would need to add the path where to
>> look for AWS to CMAKE_FIND_ROOT_PATH.
>>
>
> I have just looked that up and yes, it would explain what I'm seeing.
> CMAKE_SYSROOT is being set by the toolchain file and it would appear as
> this would make all search hints and paths implicitly relative.
>
> I'm now trying to restructure my 3rd party management for this target to
> enable me to install my dependencies into the subdirs set as sysroot,
> hoping that they will then be found.
>
> Thanks for the suggestion, that looks promising. I will get back with more
> info on if and how that turned out.
>
>> CMake feature request: it would be real nice to have a verbose mode for
>> the find_XXX functions that tell you exactly where CMake is looking for
>> stuff and why to help debug problems like this.
>>
> Seconded.
>

+1


> I always insert debug message() statements all over the place and then
> often forget to clean them up. Also, this way I can only verify the search
> paths are correct but not why find_file fails.
>

In CMake 3.15 message command learned DEBUG mode:
https://cmake.org/cmake/help/v3.15/release/3.15.html and
https://cmake.org/cmake/help/v3.15/command/message.html#command:message
so that you my leave your message(DEBUG ...) message while not being
displayed at default loglevel.

You may use the --loglevel command line option to get them. The default
level being displayed is STATUS.
See: https://cmake.org/cmake/help/v3.15/manual/cmake.1.html


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to specify Redhat Developer Toolset compiler?

[Eric Noulard]

I would bet that enabling the toolset before launching CMake will do the
trick.
Otherwise set CC and/or CXX env var to the desired path before launching
CMake.

Le jeu. 20 juin 2019 à 17:39, David Aldrich 
a écrit :

> My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed:
>
> $ /usr/bin/x86_64-redhat-linux-g++ --version
> x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
>
> I have a very simple CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
> project(hello_world LANGUAGES CXX)
>
> add_executable(hello_world "")
>
> target_sources(hello_world
>   PRIVATE
> main.cpp
> Message.hpp
> Message.cpp)
>
> I also have Redhat Developer Toolset 7 installed which I can enable in my
> bash shell:
>
> $ scl enable devtoolset-7 bash
> $ which g++
> /opt/rh/devtoolset-7/root/usr/bin/g++
> $ g++ --version
> g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
>
> How can I get CMake to use the later version of g++ instead of 4.8.5?
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Why do executables link static libs that shared libs were built from?

[Eric Noulard]

Le lun. 17 juin 2019 à 02:01, Paul Smith  a écrit :

> On Sun, 2019-06-16 at 21:42 +0200, Eric Noulard wrote:
> > Le dim. 16 juin 2019 à 18:26, Paul Smith  a
> > écrit :
> > > But, that's not the only way to use shared libraries.  I'm trying
> > > to collect a number of static libraries with different interfaces
> > > into a single shared library that can be linked with executables.
> >
> > Correct me if I'm wrong but I guess that if your goal is to "collect"
> > all those static libs *into* a shared lib then what you need is to
> > make your STATIC libs,  OBJECT libs and then I think you'll get what
> > you expect.
>
> Yep, I'm familiar with OBJECT libs and if I could use them they would
> give the correct behavior, you're right.  Unfortunately it's not the
> case that OBJECT libraries are completely "drop-in" replaceable for
> STATIC libraries, and they cannot be substituted in my environment.
>
> See, for one example:
> https://gitlab.kitware.com/cmake/cmake/issues/19388
>
> I am not able to rework my system comprehensively enough to remove all
> mutual references between all my current libraries.  And there are
> other issues where OBJECT libraries aren't the equivalent of STATIC
> libraries.
>

Yes right.


> > Otherwise (at least in the way CMake currently works) any symbols
> > defined in foo.a STATIC lib will *stay* in it. So in the end when you
> > link an executable using bar.so SHARED lib only (which is using
> > foo.a) then you won't have the symbol you need from foo unless foo.a
> > is added to the link line ? Am I right?
>
> No, that's not right.
>
> The visibility of symbols depends on how your code is compiled and has
> nothing to do with cmake and whether cmake links into a shared or
> static library.
>
> On POSIX systems (gcc and clang), all symbols are public by default
> regardless of whether you are compiling them for a static or shared
> library.
>
> On Windows it's all more complicated, but in my situation I've added
> the WINDOWS_EXPORT_ALL_SYMBOLS property to my libraries.
>

Yes you are right and I know that, but AFAIK when (with CMake) you TLL a
shared lib to a static lib. You do not end up with any of the static lib
symbol in the shared lib.
At least none of them are visible with nm. (I did only test that on Linux).

> But how can you do that without either:
> >
> > 1) adding the static lib to any link line (including the one using bar)
> > 2) *merging* foo.a *into* bar.so which should be what you achieve by
> > making foo an OBJECT lib.
>
> I'm not sure what you mean by "merging foo.a into bar.so": you can't
> merge something into a shared library any more than you can merge
> something into an executable.  By putting "foo" into the TLL of "bar",
> I've added the static library to the creation of the shared library:
>
>   cc -shared -o bar.so bar.o libfoo.a
>
> Now when bar.so is created it will have the required contents of
> libfoo.a in it.
>

You mean that the part of libfoo.a which is actually used by some part of
bar.o gets in bar.so
or any [exported] symbol found in libfoo.a gets in bar.so with the same
export rule?

My test showed me something different but I'll check again, I must have
done something wrong.


> > If we can agree on that, then using the current rules of CMake
> > > inheritance this implies that we can NEVER add a static library as
> > > a PUBLIC TLL for a shared library.
> >
> > Exactly my point. I understand what you say, but if ever CMake was
> > doing that you simply couldn't switch (GLOBALLY) from SHARED to
> > STATIC using
> > https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
> > is a single SHARED lib was explicitely specified.
>
> I wasn't familiar with that option, but I don't think it makes a
> difference whether the libraries are made SHARED via this option or
> whether they are made SHARED via direct specification: the behavior is
> the same.
>
> > My opinion is that CMake may handle TLL(SHARED STATIC) differently
> > than TLL(SHARED SHARED) but forbidding the first would be a major
> > headache when you want to go from STATIC to SHARED lib one step after
> > another (I have a concrete example in mind in a legacy project).
>
> I didn't say it should be forbidden!!
>
> I said that as cmake is currently implemented it doesn't make sense to
> do it, implying that cmake might want to change its behavior in this
> area to be more useful.
>

OK now I get your point, thank you for clarifying.


> However, after more investigation I see that I was wrong about how
> linkers resolve symbols at least in POSIX

Re: [CMake] Why do executables link static libs that shared libs were built from?

[Eric Noulard]

Le dim. 16 juin 2019 à 18:26, Paul Smith  a écrit :

> Let me just mention up-front that I spent about 2 weeks earlier this
> year completely converting our circa-2011 cmake environment to ultra-
> modern cmake: switching completely to TLL, interfaces, removing
> virtually all if-statements and converting them into generator
> expressions, etc.  So I'm very familiar with CMake's model for PRIVATE,
> PUBLIC, and INTERFACE and how inheritance works.
>
> And, I see the paradigm you're operating under where a shared library
> provides a single "interface" that is public.
>
> But, that's not the only way to use shared libraries.  I'm trying to
> collect a number of static libraries with different interfaces into a
> single shared library that can be linked with executables (in my case I
> have 220 unit test programs which, when linked statically, not only
> take a very long time and a lot of memory, but use about 45G of disk
> space per build--I am collecting these into a shared library that can
> be linked with our unit tests.  In my testing this reduces the size of
> a sample unit test executable from 400M down to about 8M).
>

Correct me if I'm wrong but I guess that if your goal is to "collect" all
those static libs *into* a shared
lib then what you need is to make your STATIC libs,  OBJECT libs and then I
think you'll get what you expect.
I.e. in your CMakeLists.txt
replace
add_library(foo STATIC foo.c)
with
add_library(foo OBJECT foo.c)

Otherwise (at least in the way CMake currently works) any symbols defined
in foo.a STATIC lib will *stay* in it. So in the end when you link an
executable
using bar.so SHARED lib only (which is using foo.a) then you won't have the
symbol
you need from foo unless foo.a is added to the link line ? Am I right ?


> So: I need my shared library to export a combination of ALL the public
> interfaces of the static libraries it was built from, but not,
> obviously, export the static libraries themselves.
>

But how can you do that without either:

1) adding the static lib to any link line (including the one using bar)
2) *merging* foo.a *into* bar.so which should be what you achieve by
making foo an OBJECT lib.



> On Sat, 2019-06-15 at 23:10 -0700, Craig Scott wrote:
> > The behaviour is correct according to what you are telling CMake to
> > do. If you use PUBLC in a target_link_libraries() call, you are
> > saying that anything that links to your shared library should also
> > link to the static library.
>
> That simply does not make sense, from the point of view of how a
> program and a linker work (I understand it's how CMake works).
>
> Let me work backwards, starting with a fact that hopefully we can all
> agree on:
>
>It is NEVER appropriate to put a static library into the
>INTERFACE_LINK_LIBRARIES of a shared library.
>
> I'd be interested to hear counter-arguments, but even if there are any
> reasons for it my position is that in those very rare cases you should
> be listing the static library in the TLL of the executable directly.
>

Correct me if I'm wrong but you are saying that TLL(bar.so foo.a)  should
merge foo.a into bar.so ?
But TLL(myexe foo.a) should add foo.a in the link line of myexe?


> If we can agree on that, then using the current rules of CMake
> inheritance this implies that we can NEVER add a static library as a
> PUBLIC TLL for a shared library.
>

Exactly my point. I understand what you say, but if ever CMake was doing
that
you simply couldn't switch (GLOBALLY) from SHARED to STATIC
using https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
is a single SHARED lib was explicitely specified.

My opinion is that CMake may handle TLL(SHARED STATIC) differently than
TLL(SHARED SHARED) but forbidding the first would be a major headache when
you want to go from STATIC to SHARED lib one step after another (I have a
concrete
example in mind in a legacy project).

Even if I agree that this is a very bad idea
"to put a static library into the INTERFACE_LINK_LIBRARIES of a shared
library"

it currently works with CMake a may be saving a lot of time to many people
switching
gradually from a legacy build system doing just that.


> Which seems, to me, quite ridiculous because why shouldn't you want to
> allow INTERFACE_COMPILE_DEFINITIONS, INTERFACE_COMPILE_OPTIONS, and
> INTERFACE_COMPILE_DIRECTORIES of the static library to be inherited by
> the shared library into its PUBLIC interface?  That seems like a quite
> reasonable thing to want to do.
>

I don't follow, it seems to be that case when the shared lib TLL publicly
to the static lib?
I really think think the behavior you are expecting already works if you
replace your static lib with object lib.
https://cmake.org/cmake/help/v3.14/command/target_link_libraries.html#linking-object-libraries

But may be I missed something?

-- 
Eric
-- 

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 

Re: [CMake] Individualized compile_commands.json per executable target?

[Eric Noulard]

Le mar. 11 juin 2019 à 05:16, Staley, Martin Frank via CMake <
cmake@cmake.org> a écrit :

> I'm using the Clang/LLMV APIs to build a code analysis tool that gives my
> users some additional analysis of their C++ codes, above and beyond what
> the compiler, proper, provides.
>
> With a set(CMAKE_EXPORT_COMPILE_COMMANDS ON) in CMakeLists.txt, cmake
> emits a "compilation database" file, compile_commands.json, that contains
> exact compilation commands for all relevant source files. The .json can be
> consumed by my analysis tool to get what it needs. Except
>
> Here's the problem. (And I've tried various googles, but nothing panned
> out.) compile_commands.json contains data for *all* source files involved
> in *any* executable for which cmake emits Makefile rules. My analysis tool
> needs input that reflects those (and only those) source files that are
> involved in any *one* of the (generally more than one) executables.
>
> EXAMPLE. Say I have some general C++ constructs in a.cc, b.cc, and c.cc,
> and two C++ executables (roughly speaking, with a main()): foo.cc and
> bar.cc. Assume further that, linkage-wise, foo.cc needs the material from
> a.cc and b.cc (but not c.cc), while bar.cc needs the material from b.cc and
> c.cc (but not a.cc). These dependencies are of course programmed into a
> CMakeLists.txt.
>
> In this situation, cmake will emit a compile_commands.json that has
> commands for all five sources: {a.cc, b.cc, c.cc, foo.cc, bar.cc}. But my
> analysis tool, run thereon, doesn't know how to divvy up the various
> elements, and it ends up reporting, among other things, the moral
> equivalent of multiply-defined symbol errors.
>
> Ideally, I'd love to have a way that Cmake could emit, say, foo.json
> containing only the compile commands for {a.cc, b.cc, foo.cc}, and a
> bar.json containing only the commands for {b.cc, c.cc, bar.cc}. Basically,
> individualized compilation databases for each executable target.
>
> There are, of course, alternatives. Given additional input, my tool could
> pull (only) the proper entries from the current, aggregated
> compile_commands.json. Or, post-cmake, I could allow for a dry-run verbose
> make of a single executable, and parse out the requisite information. For
> users, however, and for simplicity's sake, I'm hoping for something more
> direct. CMake has what I need, in some form - it must, in order to create
> the Makefile! So, life would be absolutely fabulous if this existing
> knowledge could be used to create executable-specific .json databases as
> outlined above.
>

> Is this in fact available, and my googling skills aren't up to par?
>

This is not exactly what you are looking for but you may certainly use the
CMake file-api:
https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html#manual:cmake-file-api(7)
in order to get what you want (namelly the list of files for a given target)

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Conditional install() rules based on CPack generator

[Eric Noulard]

Le mer. 5 juin 2019 à 12:00, Mathieu Malaterre 
a écrit :

> Hi there,
>
> I am trying to use NuGet generator for GDCM project. Typically my
> install rules are as follow:
>
> add_library(foo SHARED foo.c)
> install(TARGETS foo
>   EXPORT ${MY_TARGETS_NAME}
>   RUNTIME DESTINATION ${MY_INSTALL_BIN_DIR} COMPONENT Applications
>   LIBRARY DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT Libraries
>   INCLUDES DESTINATION ${MY_INSTALL_INCLUDE_DIR}
>   ARCHIVE DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT DebugDevel
> )
>
> where:
>
> MY_INSTALL_BIN_DIR='bin'
> MY_INSTALL_LIB_DIR='lib'
> MY_INSTALL_INCLUDE_DIR='include'
>
> this works quite nicely for basic 'make install', as well as binary
> zip or NSIS installer.
> However this directory layout does not seems to be compatible with
> Windows RIDs[*]. For example my native *.dll files would need to be
> moved from the 'bin' directory to something like 'lib/win7-x64'.
>
> How can I handle conditional install() rules based on CPack generator
> (NuGet in my case) ?
>

I'm not sure you can.
install() rules are processed when CMake runs and generate all
cmake_install.cmake files.
then when CPack runs it triggers the install using the files generated at
CMake time.

So while you can achieve some conditional actions when CPack runs using
CPack project config file
https://cmake.org/cmake/help/v3.14/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE

AFAIK you cannot (re)write install rule because they have already been
processed.

What you could do (as a workaround) in your CMakeLists.txt is to define
both WinXX specific CPack components
and your "generic" CPack components that can be used as a default.
install(TARGETS foo
  EXPORT ${MY_TARGETS_NAME}
  RUNTIME DESTINATION ${MY_INSTALL_BIN_DIR} COMPONENT Applications
  LIBRARY DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT Libraries
  INCLUDES DESTINATION ${MY_INSTALL_INCLUDE_DIR}
  ARCHIVE DESTINATION ${MY_INSTALL_LIB_DIR} COMPONENT DebugDevel
)
install(TARGETS foo
  EXPORT ${MY_TARGETS_NAME}
  RUNTIME DESTINATION ${MY_WINXX_INSTALL_BIN_DIR} COMPONENT
Applications-Winxx
  LIBRARY DESTINATION ${MY_WINXX_INSTALL_LIB_DIR} COMPONENT Libraries-Winxx
  INCLUDES DESTINATION ${MY_WINXX_INSTALL_INCLUDE_DIR}
  ARCHIVE DESTINATION ${MY_WINXX_INSTALL_LIB_DIR} COMPONENT DebugDevel-Winxx
)

i.e. install the same thing twice in two places.
and then at CPack time (when CPack runs) code some logic in your CPack
Config file in order
to set  CPACK_COMPONENTS_ALL to appropriate value depending on the value of
https://cmake.org/cmake/help/v3.14/module/CPack.html#variable:CPACK_GENERATOR

something like
if ("${CPACK_GENERATOR}" STREQUAL "NuGet")
   set(CPACK_COMPONENTS_ALL
"Applications-Winxx;Libraries-Winxx;DebugDevel-Winxx")
else()
set(CPACK_COMPONENTS_ALL "Applications;Libraries;DebugDevel")
endif()

that way CPack depending on the generator will ship either "WinXX"
component or "generic" ones.

I think (not tested) it should work but this is clearly a workaround.


Eric



> Thanks,
>
> [*] https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
>
> --
> Mathieu
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Dependency cycle - why?

[Eric Noulard via CMake]

Le sam. 25 mai 2019 à 13:51, Bill Somerville  a
écrit :

> Hi Robert,
>
> thanks for that, the target name change does seem to help but I am still
> unable to achieve my goal. Here is a simplified example that demonstrates
> the problem:
>
> cmake_minimum_required (VERSION  3.1.0 FATAL_ERROR)
> project (demo LANGUAGES NONE)
> add_custom_target (prog_target COMMAND ${CMAKE_COMMAND} -E touch 
> prog${CMAKE_EXECUTABLE_SUFFIX})
> add_executable (prog IMPORTED)
> add_dependencies (prog prog_target)
> set_target_properties (prog PROPERTIES IMPORTED_LOCATION 
> ${CMAKE_CURRENT_BINARY_DIR}/prog${CMAKE_EXECUTABLE_SUFFIX})
> install (TARGETS prog RUNTIME DESTINATION bin)
>
> which gives the following error at CMake configuration:
>
> CMake Error at CMakeLists.txt:7 (install):
>   install TARGETS given target "prog" which does not exist.
>
>
> -- Configuring incomplete, errors occurred!
>
> So the target that 'add_executable(name IMPORTED)' creates is not a real
> executable target. I can change its properties but the 'install(TARGETS
> ...)' command thinks it does not exist. Note that a executable target is a
> very simple demonstration and I understand that I can use 'install(PROGRAM
> ...)' just about as easily, but when it comes to a shared library it gets a
> lot more complex when using, exporting, and instlling it, and it seems that
> IMPORTED targets fall well short of useful when they are actually produced
> by the current CMake project.
>
> I can understand that an IMPORTED target is perhaps not meant to be
> installable
>

Robert will give his advice on that but I bet IMPORTED target were never
meant to be drop-in *replacement* of genuine target.

They were meant to ease *reference to* object/lib:executable that are
outside the build of the project.
e.g the doc says:
https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
"An IMPORTED library target references a library file located outside the
project"

Nmelly a target that is "already installed somewhere" and that you want to
reference in your CMake build.


> but if so then your statement that "The goal that you have is fully
> supported by CMake" seems to be incorrect. To reiterate, I am trying to use
> foreign tools to make binary targets and wish to have CMake treat them *as
> if* they were created by supported languages like C, ++, or Fortran. Am I
> still missing something?
>

My opinion is that IMPORTED target are not designed (as of today) for that
purpose.

When you want to do what you seem to want you need to either:
1) add a "new LANGUAGE" (you seem to be willing to add golang)
see:
https://stackoverflow.com/questions/7978517/how-do-i-get-cmake-to-work-with-the-go-programming-language
and may be: https://github.com/aadidenko/golang-cmake-example (or fork
of this)

2) define a set of custom macros that mimic genuine target behaviour.
may be see: https://github.com/cpconduce/go_cmake

If you want to have a look at existing similar example shippped with CMake,
have a look at UseJava.cmake module (
https://cmake.org/cmake/help/latest/module/UseJava.html)
You'll see that you have
add_jar, which is similar to add_executable and create a custom target
and
install_jar which is similar to install on genuine target but plays with
target properties and install(FILES...) in order to mimic that.
see: https://github.com/Kitware/CMake/blob/master/Modules/UseJava.cmake

I'm not developing with golang but AFAIK go has a builtin "build system" so
bringing go as a language in CMake may not be the best option,
but again I am no Go expert.

The only reference of that kind of thing I found in the CMake mailing list
is oldish:
https://cmake.org/pipermail/cmake-developers/2011-August/013715.html

May be adding the support for "install" command for IMPORTED target is
doable but this seems to be a feature request to be discussed on developer
mailing list;
Regards,
Eric


> Regards
> Bill Somerville.
>
> On 24/05/2019 20:23, Robert Maynard wrote:
>
> Hi,
>
> The goal that you have is fully supported by CMake. You have just run
> into a bug in CMake, and you should report this 
> tohttps://gitlab.kitware.com/cmake/cmake/issues .
> Basically at a very high level the name out the add_executable target
> `callback_generator` is the same as the internal name that CMake is
> using for the add_custom_command. This than causes some logic in CMake
> (cmTargetTraceDependencies) to incorrectly build another link between
> the add_custom_command and your add_executable.
>
> The easiest way to solve this issue is name the add_executable target
> to have a different name than the output of your custom command minus
> file extension. So maybe something like  `callback_generator_exec`
>
> On Fri, May 24, 2019 at 2:02 PM Bill Somerville  
>  wrote:
>
> On 13/05/2019 12:03, Bill Somerville wrote:
>
> Hi folks,
>
> I am struggling to understand what the problem is with this:
>
> find_program (GO go)
> set (GOPATH "${CMAKE_CURRENT_BINARY_DIR}/go")
> file 

Re: [CMake] cmake doesn't run all tests

[Eric Noulard]

Le mar. 21 mai 2019 à 11:45, hex  a écrit :

> hello,
>
> I have two modules in my CMake project:
>
> *root*
> *├── foo*
> *│   ├── CMakeLists.txt*
> *│   ├── src*
> *│   │   └── foo.c*
> *│   └── tests*
> *│   ├── foo_unit_test.c*
> *│   └── CMakeLists.txt*
> *├── CMakeLists.txt*
> *└── moo*
> *├── CMakeLists.txt*
> *├── src*
> *│   └── moo.c*
> *└── tests*
> *├── CMakeLists.txt*
> *└── moo_unit_test.c*
>
> my root project has:
>
> *enable_testing()*
>
> *add_subdirectory(adder)*
> *add_subdirectory(viterbi_encoder)*
>
>
> and each module has:
>
> *add_subdirectory(tests)*
>
>
> For the tests I am using add_test() and make all test.
>
> yet, this only runs the tests within the first add_subdirectory. Other
> modules are ignored.
>
> Do the CMakeLists.txt in the sub-directory have their own project command
or is your main top-level CMakeLists.txt the only CMakeLists.txt with
project  command ?

How can I run all tests at once?
>
> How do yu run the tests?

make tests ?
ninja tests ?
ctest ?

What does
$ ctest -N
says?

This should work at least it "works-for-me" so there must be some
difference between the CMakeLists.txt in the directory that works and in
the directory that does not.
Do you have a sample setup which exhibit the issue that you can share?


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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS

[Eric Noulard]

Le ven. 22 mars 2019 à 18:30, Stewart, Robert  a
écrit :

> Have a look at the code I quoted from CPackRPM.cmake:
>
> if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT
> CPACK_RPM_USER_BINARY_SPECFILE)
>   set(RPMBUILD_FLAGS "-bb")
>
> If CPACK_RPM_USER_BINARY_SPECFILE is defined, then RPMBUILD_FLAGS is *not*
> set to -bb.
>

Sorry I missed your last answer.
My link to up-to-date code:
https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Internal/CPack/CPackRPM.cmake#L1658

shows that "-bb" is always set.

This was fixed some time ago:
https://gitlab.kitware.com/cmake/cmake/commit/574c81e28cef6737adc1619ce3b44b43bdcf308b
CMake 3.8.0 and after should include this fix.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS

[Eric Noulard]

Le mer. 6 mars 2019 à 21:33, Stewart, Robert  a
écrit :

> We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on
> different platforms).  In so doing, our CMake invocation of CPack to create
> RPMs now fails and I'm hoping someone can help.  I have a spec file and I
> want to run rpmbuild -bb, but I can't figure out how to do it.
>
>

>
> The result is that my attempt to port to the all-variable approach failed,
> so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as
> before.  Unfortunately, when I do so, CPackRPM.cmake doesn't set
> RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful.  The issue
> is in the following code:
>
> # We should generate a USER spec file template:
> #  - either because the user asked for it :
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> #  - or the user did not provide one : NOT
> CPACK_RPM_USER_BINARY_SPECFILE
> if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT
> CPACK_RPM_USER_BINARY_SPECFILE)
>   set(RPMBUILD_FLAGS "-bb")
>


I missed that. Do you mean that even though you
set(CPACK_RPM_USER_BINARY_SPECFILE /)

CPackRPM does not process the spec file with rpmbuild -bb ?

AFAIU from the source:

"-bb" flags are always setup when binary RPM is built.
https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Internal/CPack/CPackRPM.cmake#L1658

I am confused. Could restate the problem.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS

[Eric Noulard]

Le mer. 6 mars 2019 à 21:33, Stewart, Robert  a
écrit :

> We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on
> different platforms).  In so doing, our CMake invocation of CPack to create
> RPMs now fails and I'm hoping someone can help.  I have a spec file and I
> want to run rpmbuild -bb, but I can't figure out how to do it.
>
> We have been using a custom spec file all along, but I found information
> indicating that doing so is (now?) considered a hack and that everything
> should be possible merely by setting CPACK_* variables.  Unfortunately,
> that's not the case.


Which CPACK_xxx variables did you use?
CPACK_RPM_SPEC_MORE_DEFINE ?
CPACK_RPM_USER_FILELIST ?



> With the following %files entries, CPackRPM.cmake chokes:
>
> %defattr(-, %{user}, %{group}, 0755)
> %dir %{destination}
> %dir %{versioned}
> %dir %{foo}
> %{foo}/*.sh
> %attr(555, %{user}, %{group}) %{foo}/a
> %dir %{bar}
> %attr(544, %{user}, %{group}) %{bar}/b
> %attr(444, %{user}, %{group}) %{bar}/*common
> %{bar}/lib
>
> The result is that my attempt to port to the all-variable approach failed,
> so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as
> before.  Unfortunately, when I do so, CPackRPM.cmake doesn't set
> RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful.  The issue
> is in the following code:
>
> # We should generate a USER spec file template:
> #  - either because the user asked for it :
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> #  - or the user did not provide one : NOT
> CPACK_RPM_USER_BINARY_SPECFILE
> if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT
> CPACK_RPM_USER_BINARY_SPECFILE)
>   set(RPMBUILD_FLAGS "-bb")
>
> I tried just setting RPMBUILD_FLAGS to -bb in my CMakeLists.txt, where I
> include CPack, but that isn't propagated to CPackRPM.cmake.  I tried adding
> a custom target that invoked "${CMAKE_CPACK_COMMAND} -D
> RPMBUILD_FLAGS=-bb", but that didn't work either.
>

You cannot add flags meant to be used at CPack time in your CMakeLists.txt
because CMakeLists.txt is read when *cmake* runs not when *cpack* runs.
See:
https://github.com/dev-cafe/cmake-cookbook/tree/master/figures/cmake-times
for the description of various times

However you can use
https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE
for that purpose.
If you specify (in your CMakeLists.txt) the name of a file as
set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_CURRENT_BINARY}/mycpack_config.cmake)
then the 'mycpack_config.cmake' will be processed by CPack when it runs.
You can find an example usage here:
http://git.savannah.nongnu.org/cgit/certi.git/tree/CMakeLists.txt#n621
in this case the CERTICPackOptions.cmake.in  (in the source tree) is first
configure to CERTICPackOptions.cmake (in the build tree)
then
SET(CPACK_PROJECT_CONFIG_FILE "${CERTI_BINARY_DIR}/CERTICPackOptions.cmake")

indicate that CPack should use it at "CPack-time".

The process describing how "CPACK_PROJECT_CONFIG_FILE" is used is described
at the beginning of : https://cmake.org/cmake/help/v3.12/module/CPack.html

If the regex processing of the %files content were more robust, I wouldn't
> trip over the RPMBUILD_FLAGS issue,


Then may be you can file a patch for making those more robust?


> but either CPACK_RPM_USER_BINARY_SPECFILE is supported or it isn't, and
> since it is currently, it should be possible for me to set RPMBUILD_FLAGS.
>
> Ideas?


1) Use   CPACK_RPM_USER_BINARY_SPECFILE and CPACK_PROJECT_CONFIG_FILE.
2) propose a patch for

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] cmake server to cmake file api swicth

[Eric Noulard]

Hi there,

I saw that CMake was apparently switching from CMake server mode (
https://cmake.org/cmake/help/v3.14/manual/cmake-server.7.html) to file api (
https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html).

I first saw it in CMake 3.14 rc and final announce:
https://cmake.org/pipermail/cmake/2019-March/069155.html

However I didn't see much discussion about that on either developer or user
ML beside recent statement from Brad
https://cmake.org/pipermail/cmake-developers/2019-March/031129.html
telling that server mode will certainly be deprecated in favor of file api.

Can any CMake developer that has been participating in this new file api
shed some light on the rational of this foreseen switch?
I'm just curious about it. What was wrong/problematic with server mode?
Does the new file api solves some IDE integration issue?

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Troubles with include_directories

[Eric Noulard]

Le sam. 9 mars 2019 à 08:44, workbe...@gmx.at  a écrit :

> Hi everyone,
>
> i've a project setup that looks like this:
>
>
> abc.h
>
> def.h
>
> and all my other .cpp and .h files are in the folder intern. Now my
> CMakeLists.txt looks like this:
>
> cmake_minimum_required(VERSION 3.7)
> project(BS_Application)
> set(SRC
>  BS_AppTypes.hpp
>  BS_IEvent.hpp
>  BS_ISystem.hpp
>  BS_IWindow.hpp
>  BS_ITimerTask.hpp
>  BS_IEventConsumer.hpp
>  BS_Application.cpp
>  BS_Button.cpp
>  BS_ContextSDL.cpp
>  BS_ISystem.cpp
>  BS_System.cpp
>  BS_SystemSDL.cpp
>  BS_WindowSDL.cpp
>  BS_ContextSDL.cpp
>  BS_DisplayManagerSDL.cpp
>  BS_Button.cpp
>  BS_EventManager.cpp
>  BS_EventPrinter.cpp
>  BS_ModifierKeys.cpp
>  BS_DisplayManager.cpp
> )
> set(INC
>  intern
> )
> include_directories(${INC})
> add_library(BS_Application STATIC ${SRC})
>
> Where all files above BS_Application.cpp are in the folder intern but he
> is not able to find BS_Application.cpp but i added it to the
> include_direcotires, what am i doing wrong here ?
>

First of all usage of include_directories is a discouraged old-style
variable oriented CMake.
You should prefer target oriented rule.
Namelly target_include_directories().
You can have a look at:
https://steveire.wordpress.com/2017/11/05/embracing-modern-cmake/ and/or
refered presentation from Daniel Pfeifer or Mathieu Ropert there in.
It'll get you a broad view of the "Modern CMake way to go".

Now both commands (target_include_directories or include_directories)
influence where *header* file are found.
So that if you say

include_directories(${INC})
add_library(BS_Application STATIC BS_Application.cpp)

CMake won't go looking for "BS_Application.cpp" inside ${INC}.
You should refer to your source files with the proper path:
i.e.
add_library(BS_Application STATIC ${INC}/BS_Application.cpp)

You may consider having a look at how to use target_source as well.
Craig Scott published a nice blog entry about that:
https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/

Regards,
Eric


> best regards!
>
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Remove folders created by install

[Eric Noulard]

There are some possible solutions and reference here:
https://stackoverflow.com/questions/41471620/cmake-support-make-uninstall

Le sam. 16 févr. 2019 à 15:48, Felix Crazzolara 
a écrit :

> Hi everyone
>
> For my smaller projects I'd like to have 'uninstall' functionality. To
> remove installed files I can call:
>
> xargs rm < build/install_manifest.txt
>
> Unfortunately this won't delete any folders generated by the
> installation. Is there a different file that keeps track of the created
> directories, or what is the recommended way to implement such
> functionality?
>
> Example:
> Suppose that I install _some_header.hpp in
> /include// using the command install(TARGETS
>  EXPORT -targets ARCHIVE DESTINATION lib
> PUBLIC_HEADER DESTINATION include/) then I want not only
> to remove
> /include//_some_header.hpp, but also
> the directory /include//.
>
> Cheers,
>
> Felix Crazzolara
>
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] requiring parallel building but sequential linking

[Eric Noulard]

Le lun. 18 févr. 2019 à 00:01, Craig Scott  a
écrit :

>
>
> On Mon, Feb 18, 2019 at 9:35 AM Domen Vrankar 
> wrote:
>
>> Hi,
>>
>> I'm building llvm project with CMake.
>> While build process is compiling the code I prefer running "make -j3" on
>> my 4 core pc (bumping processor to 100% on 3 of 4 cores and using up ~5 GB
>> of ram - part of it is system and not build related).
>> While build process is linking I must run "make" with a single job
>> because otherwise I run out of memory (cores do little work but ram usage
>> goes past 23 GB).
>>
>> Currently I'm handling this so that I first run "make -j3" and once I get
>> to about 90% (first larger linking) I hit ctrl+c and run "make".
>>
>> Is there a feature in CMake that would support handling this transition
>> of parallel builds, sequential linking out of the box?
>> (while I'm mostly interested in Linux/make support, having the same
>> feature for Windows/nmake/ninja through the same command line cmake command
>> would be even better)
>>
>
> This is available for Ninja with the JOB_POOL_LINK
>  target
> property, the default for which can be set project-wide with the
> CMAKE_JOB_POOL_LINK
>  
> variable.
> You can control the number of parallel jobs for a given pool with the
> JOB_POOLS  global
> property.
>

I use that a lot and I shall add that, on my side, link jobs memory
consumption heavily depends on the type of build (debug, release,
profiling, etc...), moreover
the available memory amount vary a lot as well whether if the build occurs
on a "local" developer desktop or on some CI runner.
So we end up doing some very basic CMake computation in order to
automatically adapt to the local resource.
Nothing fancy but it has been proven very useful for us:

if (CMAKE_BUILD_TYPE STREQUAL "Debug")
   cmake_host_system_information(RESULT MYMEM QUERY TOTAL_PHYSICAL_MEMORY)
   # Compute the number of authorized number of link jobs by:
   #   - "saving" 4 GiB of memory
   #   - assume each debug link job may consume 2GiB
   math(EXPR NLJ "(${MYMEM}-4096)/2048")
   set_property(GLOBAL PROPERTY JOB_POOLS link_jobs=${NLJ})
   set(CMAKE_JOB_POOL_LINK link_jobs)
elseif (CMAKE_BUILD_TYPE STREQUAL "Release")
...
endif()

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

[Eric Noulard]

Le jeu. 14 févr. 2019 à 18:57, Timothy Wrona  a
écrit :

> The problem is it is very likely that there are some circular dependencies
> in the build tree -- which is why it was broken up to generation of all,
> then build all, then link all in the first place.
>

Yes, wrong solution to a real design issue :-)


>
> With circular dependencies there's no real way to sort these dependencies
> out without just running generation twice, but the first run will get a
> bunch of errors for missing packages.
>

I understand the situation, I did face that too in the past.
If there is not too much circular deps you may either break them by writing
(by hand) a bunch of imported target or you can merge in the same CMake
project the sub-projects belonging to the same cycle.
Feasibility depends on the amount of projects (and cycle) you have.




>
> On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard 
> wrote:
>
>>
>>
>> Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona  a
>> écrit :
>>
>>> I have a collection of interdependent CMake projects (lots of legacy
>>> code) that I want to convert to using CMake targets for linking. The code
>>> is built in such a way that all projects run cmake generation, then all
>>> projects build, then all projects link.
>>>
>>> I would like to export a CMake target from one of the projects and link
>>> to it in another, but the issue is the project I am exporting from runs its
>>> cmake generation AFTER the project I am linking the target in. This causes
>>> "find_package" to fail because the target has not been exported yet, but
>>> realistically the exported target is not needed until link-time.
>>>
>>
>> This heavily depends on the target. Modern CMake target convey compile
>> time information as well like compile flags, include directory etc...
>>
>> Can't you re-order the cmake generation order of your projects?
>> If you [ever] have the graph dependency of your projects you may
>> topologically sort them in order to avoid this issue and superbuild them in
>> appropriate order.
>>
>>
>>> Is there a way to delay "find_package" to not look for the package until
>>> link-time?
>>>
>>
>> I don't think so.
>>
>>
>>> At link-time the package will have been exported already and if
>>> "find_package" was not called until then, it would be found successfully
>>> and the target could be pulled in and linked to.
>>>
>>
>> But the build compile line options used to generate build system files
>> are computed during CMake configuration/generation step.
>> So I don't think what you ask is possible.
>>
>> --
>> Eric
>>
>

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Is there a way to delay "find_package" until link-time when the package is actually needed?

[Eric Noulard]

Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona  a
écrit :

> I have a collection of interdependent CMake projects (lots of legacy code)
> that I want to convert to using CMake targets for linking. The code is
> built in such a way that all projects run cmake generation, then all
> projects build, then all projects link.
>
> I would like to export a CMake target from one of the projects and link to
> it in another, but the issue is the project I am exporting from runs its
> cmake generation AFTER the project I am linking the target in. This causes
> "find_package" to fail because the target has not been exported yet, but
> realistically the exported target is not needed until link-time.
>

This heavily depends on the target. Modern CMake target convey compile time
information as well like compile flags, include directory etc...

Can't you re-order the cmake generation order of your projects?
If you [ever] have the graph dependency of your projects you may
topologically sort them in order to avoid this issue and superbuild them in
appropriate order.


> Is there a way to delay "find_package" to not look for the package until
> link-time?
>

I don't think so.


> At link-time the package will have been exported already and if
> "find_package" was not called until then, it would be found successfully
> and the target could be pulled in and linked to.
>

But the build compile line options used to generate build system files are
computed during CMake configuration/generation step.
So I don't think what you ask is possible.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Help with non-standard use of CMake

[Eric Noulard]

Hi Kyle & Donald,

ctest scripting is documented in here as well:
https://cmake.org/cmake/help/v3.13/manual/ctest.1.html#ctest-script

Since this is generated from in-source documentation:
https://github.com/Kitware/CMake/blob/master/Help/manual/ctest.1.rst

may be an explanation on how to use ctest without cmake directly in a
subsection of this manual would be  a way to keep it
more up-to-date along with the source.


Le mer. 2 janv. 2019 à 18:26, Kyle Edwards via CMake  a
écrit :

> On Wed, 2019-01-02 at 12:01 -0500, Donald MacQueen [|] wrote:
> > I looked at the example of Using ctest and cdash without cmake
> > (https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Using-CTE
> > ST-and-CDASH-without-CMAKE#steercmake)
> > and I think I will try to go in that direction.
>
> Donald,
>
> I just looked at that page, and it looks like it was written a very
> long time ago, before cmake_host_system_information() and
> execute_process() were created. The exec_program() command has been
> deprecated for years. I'm going to work on updating it a little bit
> right now.
>
> Kyle
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Idea for Multi-Toolchain Support

[Eric Noulard]

Le lun. 17 déc. 2018 à 22:04, Eric Noulard  a
écrit :

> Hi Kyle,
>
> Is your proposal a follow-up on the initial bunch of ideas launched in
> this thread launch by Eike in November
> https://cmake.org/pipermail/cmake-developers/2018-November/030913.html
> with follow-up ideas in in december:
> https://cmake.org/pipermail/cmake-developers/2018-December/030920.html
>
> or is it somehow unrelated?
>
>
> Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <
> cmake-developers@cmake.org> a écrit :
>
>> Hello everyone,
>>
>> One of the things that's long been requested of CMake is the ability to
>> have multiple toolchains - for instance, one host toolchain and one
>> cross toolchain, so that "utilities" needed for build can be built with
>> the host toolchain and then the "real" software can be built with the
>> cross toolchain.
>>
>> To solve this problem, I would like to propose the creation of a new
>> first-class object type, the "toolchain" type, which would replace the
>> current variable-based system, similar to how imported targets replaced
>> variable-based usage requirements.
>>
>> Every project would automatically receive one toolchain, the "DEFAULT"
>> toolchain, which would be either automatically configured or configured
>> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
>> toolchains could be added with the add_toolchain() command:
>>
>> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
>>
>
> This has some common design issue as my proposal:
> enable_cross_target(...)
> for which Eike has valuable doubt:
> https://cmake.org/pipermail/cmake-developers/2018-November/030919.html
>
>
>> Then, executables and libraries could have a toolchain specified:
>>
>> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
>> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>>
>> Note that the TOOLCHAIN argument is optional, and if omitted, the
>> DEFAULT toolchain is used.
>>
>
> So if you want to build both for host and cross toolchain you'll have to
> explicitely
> add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
> add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)
>
> If you follow the previously referred discussion you cannot assume that
> one lib/exe
> built for a toolchain is not built for another toolchain as well.
>
> How do you envision the cross-toolchain target dependency which was
> a question raised several time.
>
>
>> If a project uses multiple toolchains, we could have the option to
>> rename the default toolchain with an alternative add_toolchain()
>> syntax:
>>
>> add_toolchain(HostToolchain DEFAULT)
>>
>> Rather than adding a new toolchain, this would simply rename the
>> "DEFAULT" toolchain to "HostToolchain". Then the toolchain
>> specification for each target could look like this:
>>
>> add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
>> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>>
>> Two new global read-only properties would be added: TOOLCHAINS and
>> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
>> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
>> the DEFAULT toolchain (which could be changed with the alternative
>> add_toolchain() syntax.)
>>
>> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
>> setting variables:
>>
>> set(CMAKE_C_COMPILER /usr/bin/gcc)
>> set(CMAKE_C_COMPILER_ID gnu)
>> # etc.
>>
>> it would instead set properties on the selected toolchain:
>>
>> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
>> /usr/bin/gcc)
>> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
>> C_COMPILER_ID gnu)
>> # etc.
>>
>
> I don't see why we should change the syntax of current toolchain file, I
> don't see the benefit.
> CMake already knows when (and which) toolchain file is loaded and it could
> perfectly automatically
>

... sorry wrong key pressed...

CMake could perfectly automatically create the new "TOOLCHAIN" object by
loading the very
same toolchain file as we have today. We could simple add a new variable
CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name
them as he wants.
When there is no CMAKE_TOOLCHAIN_NAME this would be the default toolchain.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Idea for Multi-Toolchain Support

[Eric Noulard]

Hi Kyle,

Is your proposal a follow-up on the initial bunch of ideas launched in this
thread launch by Eike in November
https://cmake.org/pipermail/cmake-developers/2018-November/030913.html
with follow-up ideas in in december:
https://cmake.org/pipermail/cmake-developers/2018-December/030920.html

or is it somehow unrelated?


Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <
cmake-developers@cmake.org> a écrit :

> Hello everyone,
>
> One of the things that's long been requested of CMake is the ability to
> have multiple toolchains - for instance, one host toolchain and one
> cross toolchain, so that "utilities" needed for build can be built with
> the host toolchain and then the "real" software can be built with the
> cross toolchain.
>
> To solve this problem, I would like to propose the creation of a new
> first-class object type, the "toolchain" type, which would replace the
> current variable-based system, similar to how imported targets replaced
> variable-based usage requirements.
>
> Every project would automatically receive one toolchain, the "DEFAULT"
> toolchain, which would be either automatically configured or configured
> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
> toolchains could be added with the add_toolchain() command:
>
> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
>

This has some common design issue as my proposal:
enable_cross_target(...)
for which Eike has valuable doubt:
https://cmake.org/pipermail/cmake-developers/2018-November/030919.html


> Then, executables and libraries could have a toolchain specified:
>
> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>
> Note that the TOOLCHAIN argument is optional, and if omitted, the
> DEFAULT toolchain is used.
>

So if you want to build both for host and cross toolchain you'll have to
explicitely
add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)

If you follow the previously referred discussion you cannot assume that one
lib/exe
built for a toolchain is not built for another toolchain as well.

How do you envision the cross-toolchain target dependency which was
a question raised several time.


> If a project uses multiple toolchains, we could have the option to
> rename the default toolchain with an alternative add_toolchain()
> syntax:
>
> add_toolchain(HostToolchain DEFAULT)
>
> Rather than adding a new toolchain, this would simply rename the
> "DEFAULT" toolchain to "HostToolchain". Then the toolchain
> specification for each target could look like this:
>
> add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>
> Two new global read-only properties would be added: TOOLCHAINS and
> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
> the DEFAULT toolchain (which could be changed with the alternative
> add_toolchain() syntax.)
>
> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
> setting variables:
>
> set(CMAKE_C_COMPILER /usr/bin/gcc)
> set(CMAKE_C_COMPILER_ID gnu)
> # etc.
>
> it would instead set properties on the selected toolchain:
>
> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
> /usr/bin/gcc)
> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
> C_COMPILER_ID gnu)
> # etc.
>

I don't see why we should change the syntax of current toolchain file, I
don't see the benefit.
CMake already knows when (and which) toolchain file is loaded and it could
perfectly automatically


>
> where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain
> file either at the root or by the add_toolchain() command.
>
> If you want to read the value of C_COMPILER, etc. then just use
> get_property():
>
> get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER)
>
> Obviously this system would scale well to more than just two toolchains
> - just use as many add_toolchain() commands as you need.
>
> Backwards compatibility is going to be a challenge. Both the toolchain
> file and the project have to be aware of the new toolchain system,
> which means we have to handle four permutations:
>
> 1) old toolchain + old project
> 2) old toolchain + new project
> 3) new toolchain + old project
> 4) new toolchain + new project
>
> I propose adding a policy that both the toolchain file and the project
> can set separately, and which would have a slightly different meaning
> in each one. If the toolchain is OLD and the project is NEW, then the
> variables set by the toolchain file would be converted into properties
> on the toolchain for the project. If the toolchain is NEW and the
> project is OLD, then the properties on the toolchain would be converted
> into variables in the project. If both the toolchain and project have
> the same value, then no special 

Re: [CMake] Tracking progress of CMake TAR

[Eric Noulard]

Le lun. 17 déc. 2018 à 18:00, Person Withhats  a
écrit :

> I guess for now, anything that'll get it to work on Windows? That's the
> primary platform for this.
>

If you give up on portability then replace cmake -E tar with an external
program which has progress capability on Windows.
It looks like 7-zip can do that:
see: https://sevenzip.osdn.jp/chm/cmdline/switches/bs.htm
or: https://sourceforge.net/p/sevenzip/discussion/45797/thread/d10225f7/

I don't work on Windows those day so I won't be able to try it out.

Eric


>
> On Mon, Dec 17, 2018 at 8:53 AM Eric Noulard 
> wrote:
>
>>
>> Le lun. 17 déc. 2018 à 17:17, Person Withhats 
>> a écrit :
>>
>>> It's untarring around 1.5GB of SDK's, I don't think listing 1000's of
>>> files is going to help.
>>>
>>
>> Yes right.
>> You need some "size extraction progress" not number of files progress.
>>
>> I'm not sure classical un-archive program do have the feature.
>>
>> I'm pretty sure that "working progress bar" is most of the time very
>> difficult to implement:
>>
>> https://ux.stackexchange.com/questions/11881/progress-bars-why-are-they-never-useful
>>
>> I was hoping for some sort of progress bar or the like,
>>>
>>
>> I'm pretty sure cmake -E tar does not have this feature.
>> Genuine unix tar command does not have such feature and some people uses
>> 'pv' (http://www.ivarch.com/programs/pv.shtml)
>> for that very same purpose
>> e.g.
>> https://superuser.com/questions/168749/is-there-a-way-to-see-any-tar-progress-per-file
>>
>> I guess the issue is the same for other archive tool including zip:
>> https://askubuntu.com/questions/909918/q-how-to-show-unzip-progress
>>
>> CMake is using libarchive for handling various archive files (including
>> tar) libarchive seems to have
>> some feature for progress display (
>> https://github.com/libarchive/libarchive/wiki/ManPageArchiveReadExtract3)
>> but CMake code is not using it in any way.
>>
>>
>>> and yes I'm using cmake -E tar .-.
>>>
>>> Any ideas?
>>>
>>
>> Beside non-portable way no.
>>
>>
>>>
>>> On Mon, Dec 17, 2018 at 7:16 AM Eric Noulard 
>>> wrote:
>>>
>>>> I guess he is using
>>>>
>>>> cmake -E tar
>>>>
>>>> may be using 'v' verbose option from tar  should be enough.
>>>>
>>>> i.e.
>>>> cmake -E tar xvz your-archive.tar.gz
>>>>
>>>> It should display file names as they come out of the archive.
>>>> So unless your very big archive only contains relatively big files, the
>>>> output should evolve quite often.
>>>>
>>>> Eric
>>>>
>>>>
>>>> Le lun. 17 déc. 2018 à 15:46, Ian Cullen 
>>>> a écrit :
>>>>
>>>>> Are you calling tar via a custom command?  tar itself looks to have a
>>>>> few options to print progress:
>>>>>
>>>>> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>>>>>
>>>>> Although none of the options seem to know the archive's size, so
>>>>> aren't able to print a completion percentage.
>>>>>
>>>>>
>>>>> On 16/12/2018 21:31, Person Withhats wrote:
>>>>>
>>>>> When running tar via CMake (in order to use cross-platform
>>>>> work-ability and what not) it'd be great to have a progress bar of any
>>>>> sort.
>>>>>
>>>>> It's awkward to wait 30-60 minutes for file untarring with absolutely
>>>>> 0 information. I'm not aware of any way to do this through CMake directly,
>>>>> only alternative is e.g. python script that does the untar for me.
>>>>>
>>>>> Any suggestions? (sorry if this is reposted, can't remember if acc was
>>>>> approved before or after sending one time)
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> 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

Re: [CMake] Tracking progress of CMake TAR

[Eric Noulard]

Le lun. 17 déc. 2018 à 17:17, Person Withhats  a
écrit :

> It's untarring around 1.5GB of SDK's, I don't think listing 1000's of
> files is going to help.
>

Yes right.
You need some "size extraction progress" not number of files progress.

I'm not sure classical un-archive program do have the feature.

I'm pretty sure that "working progress bar" is most of the time very
difficult to implement:
https://ux.stackexchange.com/questions/11881/progress-bars-why-are-they-never-useful

I was hoping for some sort of progress bar or the like,
>

I'm pretty sure cmake -E tar does not have this feature.
Genuine unix tar command does not have such feature and some people uses
'pv' (http://www.ivarch.com/programs/pv.shtml)
for that very same purpose
e.g.
https://superuser.com/questions/168749/is-there-a-way-to-see-any-tar-progress-per-file

I guess the issue is the same for other archive tool including zip:
https://askubuntu.com/questions/909918/q-how-to-show-unzip-progress

CMake is using libarchive for handling various archive files (including
tar) libarchive seems to have
some feature for progress display (
https://github.com/libarchive/libarchive/wiki/ManPageArchiveReadExtract3)
but CMake code is not using it in any way.


> and yes I'm using cmake -E tar .-.
>
> Any ideas?
>

Beside non-portable way no.


>
> On Mon, Dec 17, 2018 at 7:16 AM Eric Noulard 
> wrote:
>
>> I guess he is using
>>
>> cmake -E tar
>>
>> may be using 'v' verbose option from tar  should be enough.
>>
>> i.e.
>> cmake -E tar xvz your-archive.tar.gz
>>
>> It should display file names as they come out of the archive.
>> So unless your very big archive only contains relatively big files, the
>> output should evolve quite often.
>>
>> Eric
>>
>>
>> Le lun. 17 déc. 2018 à 15:46, Ian Cullen  a
>> écrit :
>>
>>> Are you calling tar via a custom command?  tar itself looks to have a
>>> few options to print progress:
>>>
>>> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>>>
>>> Although none of the options seem to know the archive's size, so aren't
>>> able to print a completion percentage.
>>>
>>>
>>> On 16/12/2018 21:31, Person Withhats wrote:
>>>
>>> When running tar via CMake (in order to use cross-platform work-ability
>>> and what not) it'd be great to have a progress bar of any sort.
>>>
>>> It's awkward to wait 30-60 minutes for file untarring with absolutely 0
>>> information. I'm not aware of any way to do this through CMake directly,
>>> only alternative is e.g. python script that does the untar for me.
>>>
>>> Any suggestions? (sorry if this is reposted, can't remember if acc was
>>> approved before or after sending one time)
>>>
>>>
>>> --
>>>
>>> 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
>>>
>>
>>
>> --
>> Eric
>> --
>>
>> 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
>>
>

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tracking progress of CMake TAR

[Eric Noulard]

I guess he is using

cmake -E tar

may be using 'v' verbose option from tar  should be enough.

i.e.
cmake -E tar xvz your-archive.tar.gz

It should display file names as they come out of the archive.
So unless your very big archive only contains relatively big files, the
output should evolve quite often.

Eric


Le lun. 17 déc. 2018 à 15:46, Ian Cullen  a
écrit :

> Are you calling tar via a custom command?  tar itself looks to have a few
> options to print progress:
>
> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>
> Although none of the options seem to know the archive's size, so aren't
> able to print a completion percentage.
>
>
> On 16/12/2018 21:31, Person Withhats wrote:
>
> When running tar via CMake (in order to use cross-platform work-ability
> and what not) it'd be great to have a progress bar of any sort.
>
> It's awkward to wait 30-60 minutes for file untarring with absolutely 0
> information. I'm not aware of any way to do this through CMake directly,
> only alternative is e.g. python script that does the untar for me.
>
> Any suggestions? (sorry if this is reposted, can't remember if acc was
> approved before or after sending one time)
>
>
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Make errors when running ./bootstrap in Ubuntu 12.04

[Eric Noulard]

Did you try to pick a pre-compiled version of CMake?
https://cmake.org/download/

https://github.com/Kitware/CMake/releases/download/v3.13.2/cmake-3.13.2-Linux-x86_64.tar.gz
CMake is statically linked so installing a binary should work.

Le ven. 14 déc. 2018 à 17:48, Paul Jeffries  a
écrit :

> Dear list,
>
> I ultimately want to install a program called DosageConvertor that
> requires a version of cmake that is 3.2 or later. Therefore, I am trying to
> install a more recent version of cmake since the current version is 2.8.7.
>
> When I run ./bootstrap, I get a message that there were problems running
> make: 2 errors generated. make: *** [cmAddCustomCommandCommand.o] Error 1
> (I have added the complete output below.)
>
> I searched and found no clear solution to this problem. I did see that std
> should be set to gnu++11, but my output has “std=gnu++1y”.
>
> I specified the compiler because when I ran ./bootstrap by itself, I got
> an error message that there was no C++ compiler. Did I choose the wrong
> compiler? Am I missing a library?
>
> Any help would be appreciated.
>
> Paul
>
> paul@paul-VirtualBox:~/cmake-3.13.1$ CC=gcc ./bootstrap && make && sudo make 
> install-CMake 3.13.1, Copyright 
> 2000-2018 Kitware, Inc. and ContributorsC compiler on this system is: gcc 
>   C++ compiler on this system is: clang++  -std=gnu++1y Makefile 
> processor on this system is: makeclang++ has setenvclang++ has 
> unsetenvclang++ does not have environ in stdlib.hclang++ has stl 
> wstringclang++ has 
> -clang++ 
> -std=gnu++1y -I/home/paul/cmake-3.13.1/Bootstrap.cmk  
> -I/home/paul/cmake-3.13.1/Source -I/home/paul/cmake-
> 3.13.1/Source/LexerParser  -I/home/paul/cmake-3.13.1/Utilities  -c 
> /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx -o 
> cmAddCustomCommandCommand.o In file included from 
> /home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx:9:In file 
> included from /home/paul/cmake-3.13.1/Source/cmCustomCommand.h:9: 
> /home/paul/cmake-3.13.1/Source/cmListFileCache.h:127:3: error: exception 
> specification of explicitly defaulted move constructor does not match the 
> cmListFileBacktrace(cmListFileBacktrace&&) // NOLINT(clang-tidy)  ^ 
> /home/paul/cmake-3.13.1/Source/cmListFileCache.h:130:24: error: exception 
> specification of explicitly defaulted move assignment operator does not match 
> the calculated one cmListFileBacktrace& operator=(cmListFileBacktrace&&) // 
> NOLINT(clang-tidy)   ^2 errors generated.make: *** 
> [cmAddCustomCommandCommand.o] Error 
> 1-Error when bootstrapping 
> CMake:Problem while running 
> make-Log of errors: 
> /home/paul/cmake-3.13.1/Bootstrap.cmk/cmake_bootstrap.log-paul@paul-VirtualBox:~/cmake-3.13.1$
>
>
>
>
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mar. 11 déc. 2018 à 14:18, Rolf Eike Beer  a écrit :

> Eric Noulard wrote:
>
> > When ones do cross compile for the host + one or several target a
> > lighter
> > "add_superbuild" API could be design. I'll try to think about it more
> > thoroughly and do some proposal. Ideally we shouldn't need to provide
> > many
> > parameters beside the toolchain and a way to specify "the host build".
>
> I guess putting the host-build location in the toolchain file could be
> one way
> to just get it done. In case one has multiple builds that should share
> one host
> build then just set an absolute location, and if you don't it will be
> below your
> normal build directory.
>

Yes that seems a reasonable way to do it.

There are just 2 things that scare me a bit off: we surely want a way to
> break
> that into smaller pieces so we can introduce it over multiple releases,
> maybe even
> as a tech-preview so we can break things if we see that we have not
> taken a bigger
> usecase in account, and I currently don't see the points to slice that
> up.
>

We could add new builtin command along with an enable_preview command that
would bring the currently in preview commands.
If you don't call enable_preview CMake will issue an error telling that the
command you are trying to are in "preview" if it's the case.
When enabling preview you'll get the "in-preview" command plus a warning
telling you that enabling preview brings you command/features that are not
guaranteed to be backward compatible.

Equipped with that we could incubate a feature and switch it from preview
to prime-time when we are confident about it.


> And we really, really want a
> .cmake_no_freaking_in_source_build_under_any_circumstances
> or however we gonna call it, and we need that first. There has been
> wasted enough time
> with in-source builds, missing cleanups and all the weird side effects
> in our industry
> for decades, and sadly CMake hasn't stopped that nonsense entirely.
> There are still
> projects out there that can only build this way because they do some
> assumptions on
> where to pick up files, but for something that will end up mixed
> cross/host build this
> will never under any circumstances going to work.
>

Yeah you are damn right, and guess what, I was convinced by that near a
decade ago from now
https://cmake.org/Bug/view.php?id=6672 !!

The old ticket got reloaded in the "new" tracker as
https://gitlab.kitware.com/cmake/cmake/issues/6672


> I wonder if we can't just add it as extra argument to
> cmake_minimum_required(), in a
> way that you _have_ to specify ALLOW_IN_SOURCE_BUILD explicitely if you
> require a version
> newer than say 3.14, so anyone that is not explicitely requesting this
> to work will
> automagically end up in a "clean" setup. Of course we need to make sure
> that no file is
> written by CMake until that line is parsed (or any other command is
> encountered). Or
> simply do something similar when using toolchain files, which CMake can
> detect before
> even start parsing the main CMakeLists.txt.
>

There is two problems here.

1) AFAIR (there is some discussion about that in the old ticket) as soon as
CMake is parsing CMakeLists.txt it creates the CMakeCache.txt and you want
to avoid polluting the source before that thus the proposal from Ben & Brad
to add the no-in-source enforcement in an extra file.

2) Changing the default behavior of not accepting in-source is good for me
but it is clearly backward incompatible. Unless I'm wrong there has not
been any such backward-incompatible change in CMake as of now.
I doubt this would be widely accepted. Or may be for CMake 4.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] dependencies of cross compiliations

[Eric Noulard]

Le dim. 9 déc. 2018 à 12:24, Craig Scott  a écrit :

> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki 
> wrote:
>
>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
>> >
>> > My assumption are:
>> >  a) when you cross-compile your build is a "whole" and you shouldn't
>> have to setup some superbuild
>> >structure for building host tools ht_exe and another for target1
>> tool t1t_exe and another one for target2 tool t2t_exe.
>> >
>> >  b) what you want is to build:
>> >  ht_exe for the host
>> >  possibly use ht_exe during the build to generate some [source] file
>> >  t1t_exe for the [cross]target1
>> >  t2t_exe for the [cross]target2
>> >
>> >  c)  you seldomly compile the same source for the host AND the target,
>> but it may happen.
>>
>> In case, you are doing unit tests, it’s normal to have the same code
>> running in a test on the host platform and in the final binary on the
>> target.
>>
>> I think, having more than 1 target platform becomes more and more normal
>> as it becomes more usual to have multiple microcontrollers in a project.
>>
>
Yes that's why I thought it was worth going further than host + target, but
host + tgt1 + tg2 + 


>
>> Previously, I have encoded this in the build type. So instead of just
>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug,
>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very
>> much, that I have to run CMake 3 times to get all the binaries for a
>> release build. The problem that I have, are dependencies between this
>> builds. If I write a tool that (for example) generates source files for one
>> of the target platforms, the build for the host platform must run before
>> the build for that target platform. And when I make changes to that tool, I
>> want the build to regenerate the generated source files.
>>
>> Keeping track of this dependencies to solve this kind of ordering issues
>> and to allow minimum rebuilds, is the main purpose of any build system. To
>> solve this with CMake, I think we need a way to define the dependencies
>> between build types (in the example above, from the generator from the host
>> build to the generated source file in one of the target builds) and CMake
>> needs to know the build directory for all build types (not only the
>> current).
>>
>
> Perhaps a superbuild would be the cleanest approach here? The host tools
> would be one subproject and the cross-compile builds would depend on the
> host tools' build. You could then choose to build everything via the top
> level superbuild or just work on one of the subprojects if that's all you
> needed once the initial tools build had been done. You could even set up as
> many different sub-projects for the different architectures as needed.
> Packaging would require a little more work, but it shouldn't be
> prohibitively so.
>

I guess the tough part is to find a [light] way to specify dependencies
between host target build and the various target builds.


> Another alternative is the approach described in this stackoverflow
> article
> <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run>
> which performs the host tools build off to the side in a secondary build
> during configure. This works well when the host tools don't change much (we
> use it extensively at work with very large, complex hierarchical projects).
> It wouldn't help though if you need to build more than one cross-compiled
> architecture.
>
> > The wish-season is coming up, so that's sort of what I would like to
>> > have. Now it's your turn. No bikeshedding please, only deliveries ;)
>>
>> How about ``add_dependencies()`` allowing me to define dependencies
>> between different build types? :-)
>>
>
> A superbuild would already give you the equivalent capability.
>

Not as easy as it seems right?
I bet you know it well as you listed the dependencies shortcoming of adding
dependencies for External_ProjectAdd in your book (§27.1.4).

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le dim. 9 déc. 2018 à 12:24, Craig Scott  a écrit :

> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki 
> wrote:
>
>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
>> >
>> > My assumption are:
>> >  a) when you cross-compile your build is a "whole" and you shouldn't
>> have to setup some superbuild
>> >structure for building host tools ht_exe and another for target1
>> tool t1t_exe and another one for target2 tool t2t_exe.
>> >
>> >  b) what you want is to build:
>> >  ht_exe for the host
>> >  possibly use ht_exe during the build to generate some [source] file
>> >  t1t_exe for the [cross]target1
>> >  t2t_exe for the [cross]target2
>> >
>> >  c)  you seldomly compile the same source for the host AND the target,
>> but it may happen.
>>
>> In case, you are doing unit tests, it’s normal to have the same code
>> running in a test on the host platform and in the final binary on the
>> target.
>>
>> I think, having more than 1 target platform becomes more and more normal
>> as it becomes more usual to have multiple microcontrollers in a project.
>>
>
Yes that's why I thought it was worth going further than host + target, but
host + tgt1 + tg2 + 


>
>> Previously, I have encoded this in the build type. So instead of just
>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug,
>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very
>> much, that I have to run CMake 3 times to get all the binaries for a
>> release build. The problem that I have, are dependencies between this
>> builds. If I write a tool that (for example) generates source files for one
>> of the target platforms, the build for the host platform must run before
>> the build for that target platform. And when I make changes to that tool, I
>> want the build to regenerate the generated source files.
>>
>> Keeping track of this dependencies to solve this kind of ordering issues
>> and to allow minimum rebuilds, is the main purpose of any build system. To
>> solve this with CMake, I think we need a way to define the dependencies
>> between build types (in the example above, from the generator from the host
>> build to the generated source file in one of the target builds) and CMake
>> needs to know the build directory for all build types (not only the
>> current).
>>
>
> Perhaps a superbuild would be the cleanest approach here? The host tools
> would be one subproject and the cross-compile builds would depend on the
> host tools' build. You could then choose to build everything via the top
> level superbuild or just work on one of the subprojects if that's all you
> needed once the initial tools build had been done. You could even set up as
> many different sub-projects for the different architectures as needed.
> Packaging would require a little more work, but it shouldn't be
> prohibitively so.
>

I guess the tough part is to find a [light] way to specify dependencies
between host target build and the various target builds.


> Another alternative is the approach described in this stackoverflow
> article
> <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run>
> which performs the host tools build off to the side in a secondary build
> during configure. This works well when the host tools don't change much (we
> use it extensively at work with very large, complex hierarchical projects).
> It wouldn't help though if you need to build more than one cross-compiled
> architecture.
>
> > The wish-season is coming up, so that's sort of what I would like to
>> > have. Now it's your turn. No bikeshedding please, only deliveries ;)
>>
>> How about ``add_dependencies()`` allowing me to define dependencies
>> between different build types? :-)
>>
>
> A superbuild would already give you the equivalent capability.
>

Not as easy as it seems right?
I bet you know it well as you listed the dependencies shortcoming of adding
dependencies for External_ProjectAdd in your book (§27.1.4).

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mer. 28 nov. 2018 à 21:03, Rolf Eike Beer  a écrit :

> Am Dienstag, 27. November 2018, 19:55:56 CET schrieb Eric Noulard:
>
> > I think that most of the time specifying the toolchain on the command
> line
> > drives you to some superbuild structure.
>
> Which is not bad by itself, but I would like to see that CMake can provide
> things that avoid people reinventing the boilerplate code, and probably
> getting them wrong at least 80% of the time. Like they would do with
> dependencies and other things if they would write their Makefiles by hand
> instead of using CMake, just one level higher.
>

I do totally agree with this.
Superbuild is nice but you have to write a lot of boilerplate CMake code
*each time* you want to do it.
May be a good path would be to have a "builtin" support for superbuild in
CMake which
would make its usage lighter than the usual ExternalProject_Add.

When ones do cross compile for the host + one or several target a lighter
"add_superbuild"
API could be design. I'll try to think about it more thoroughly and do some
proposal.
Ideally we shouldn't need to provide many parameters beside the toolchain
and a way
to specify "the host build".


>
> > > The wish-season is coming up, so that's sort of what I would like to
> > > have. Now it's your turn. No bikeshedding please, only deliveries ;)
> >
> > I wish an integrated multi-target cross building support in CMake with
> > little or no flow-control scripting command in the CMakeLists.txt.
>
> That would mean introducing HOST and TARGET flags to every find_* call,
> I'm
> not sure if that is cleaner than explicit if()'s. But I'm not
> fundamentally
> opposed to it, I'm just not sure it's worth the effort.
>

Sure, I agree too.
May not be worth, let's dig the "light superbuild" approach a little
further first.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] New version forces rebuild all?

[Eric Noulard]

Le mar. 4 déc. 2018 à 11:44, Andy  a écrit :

> Problem are still.
> Alone make also give me problems.
>

Do you have stripped down project example?


> Ninja is replacement od cmake or make?
>

ninja (https://ninja-build.org/) is make replacement for which there is a
CMake generator.
https://cmake.org/cmake/help/v3.13/generator/Ninja.html


> How work with ninja?
>

1) install ninja (on debian the package is called ninja-build)
2) cmake -G Ninja
3) ninja

this would rule out generator specific issue.
-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Build and run an external project

[Eric Noulard]

Le mar. 4 déc. 2018 à 06:11, James Bigler  a écrit :

> Unfortunately I don't think your suggestion will work.
>
> I need to invoke a custom executable to build my project and not a
> msproject.  I also need to copy the executable into the build directory.
>

Sorry I miss the fact that you moved the executable around and was not a
"regular" compile.
I've read your message too fast, obviously, sorry.

I'm not much a Visual Studio user and it has been a long time since I need
to compile something on windows.

You basically require that an executable not built by VS appears as a
"runnable/debuggable" target in VS?
Are you able to do that from VS "manually" ?

Again I'm no VS/Windows specialist so others may have more valuable remark
on that.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Build and run an external project

[Eric Noulard]

Did you check whether if
https://cmake.org/cmake/help/latest/command/include_external_msproject.html

wouldn't be better in your case?


Le mar. 4 déc. 2018 01:43, James Bigler  a écrit :

> I have an external project that I would like to compile using their build
> system, and be able to set the VS_COMMAND to the result of the project so I
> can run it.
>
>   add_custom_target(${cmake_target}
> COMMAND make mytarget ${BUILD_ARGS}
> COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${PATH_TO_EXTERNAL}/mytarget.exe ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$
> WORKING_DIRECTORY ${PATH_TO_EXTERNAL}
> )
>   set_property( TARGET ${cmake_target} PROPERTY VS_DEBUGGER_COMMAND
> "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$/mytarget.exe" )
>
> The VS_DEBUGGER_COMMAND works for targets such as add_executable, but not
> for add_custom_target.
>
> Is there a way to get what I want?
>
> Note that this is part of a larger CMake project that builds most of the
> other stuff using CMake, but I have a few external projects that I would
> like as part of the main solution.
>
> Thanks,
> James
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer  a écrit :

> Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
>
I do agree with that quote I was quite surprised (a long time ago) that
CMake did not support cross-compiling.
Back then I was using recursive hand-written makefiles for cross-compiling.
When I wanted to build
the whole thing I only had to hit "make" and wait.

Moreover I think CMake cross-compiling support was biased by the fact CMake
wasn't designed for that initially.
Please don't take my remark as bare criticism I am using CMake for a long
time now, I do like CMake very much
and I was pleased to see the cross-compiling support coming.

However from my point of view and my cross-compiling experience when you
cross-compile you have:

1) the host compiler which is used to compile "host tools"
2) the target compiler (may be several of them) to "cross-compile"

My assumption are:
 a) when you cross-compile your build is a "whole" and you shouldn't have
to setup some superbuild
   structure for building host tools ht_exe and another for target1 tool
t1t_exe and another one for target2 tool t2t_exe.

 b) what you want is to build:
 ht_exe for the host
 possibly use ht_exe during the build to generate some [source] file
 t1t_exe for the [cross]target1
 t2t_exe for the [cross]target2

 c)  you seldomly compile the same source for the host AND the target, but
it may happen.

And you want to build all that stuff with a single configure+build command
AND take advantage
of fast and efficient parallel build for the **whole build**. I don't want
to

cd /build/for/host
ninja
cd /build/for/target1
ninja
etc...



>  Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>

I get your point but I think we may try a more declarative way.

add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)

set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1")
set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1")

after that we know that `magic` is to be built both for "host" and
"cross_target1" whereas
`foo` is only for "cross_target1".

before that we may have to "declaratively" define what is cross_target1
(and may be cross_target2) with something like:

enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target1-toolchain.cmake)
enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target2-toolchain.cmake)
and assume "host" builtin target is the one coming from the command line.

each define_cross_target(..) will create a separate subdir in the build
tree (much like CMAKE_CFG_INTDIR is working for multi-config 

Re: [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer  a écrit :

> Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
>
I do agree with that quote I was quite surprised (a long time ago) that
CMake did not support cross-compiling.
Back then I was using recursive hand-written makefiles for cross-compiling.
When I wanted to build
the whole thing I only had to hit "make" and wait.

Moreover I think CMake cross-compiling support was biased by the fact CMake
wasn't designed for that initially.
Please don't take my remark as bare criticism I am using CMake for a long
time now, I do like CMake very much
and I was pleased to see the cross-compiling support coming.

However from my point of view and my cross-compiling experience when you
cross-compile you have:

1) the host compiler which is used to compile "host tools"
2) the target compiler (may be several of them) to "cross-compile"

My assumption are:
 a) when you cross-compile your build is a "whole" and you shouldn't have
to setup some superbuild
   structure for building host tools ht_exe and another for target1 tool
t1t_exe and another one for target2 tool t2t_exe.

 b) what you want is to build:
 ht_exe for the host
 possibly use ht_exe during the build to generate some [source] file
 t1t_exe for the [cross]target1
 t2t_exe for the [cross]target2

 c)  you seldomly compile the same source for the host AND the target, but
it may happen.

And you want to build all that stuff with a single configure+build command
AND take advantage
of fast and efficient parallel build for the **whole build**. I don't want
to

cd /build/for/host
ninja
cd /build/for/target1
ninja
etc...



>  Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>

I get your point but I think we may try a more declarative way.

add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)

set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1")
set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1")

after that we know that `magic` is to be built both for "host" and
"cross_target1" whereas
`foo` is only for "cross_target1".

before that we may have to "declaratively" define what is cross_target1
(and may be cross_target2) with something like:

enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target1-toolchain.cmake)
enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target2-toolchain.cmake)
and assume "host" builtin target is the one coming from the command line.

each define_cross_target(..) will create a separate subdir in the build
tree (much like CMAKE_CFG_INTDIR is working for multi-config 

Re: [CMake] Can an option enforce a default, even if cache is present?

[Eric Noulard]

Le mar. 27 nov. 2018 à 14:50, Mario Emmenlauer  a
écrit :

>
> Dear all,
>
> I've just discovered that option() behaves differently than I anticipated.
> After reading the docs and searching with google I'm still confused how to
> achieve my desired behaviour.
>
> What I've just learned is that unspecified options take their cached value
> and do *not* go back to their default value, if a cache exists. I assumed
> that options take their default when not explicitly specified.
>

The behavior of option() gained new behavior in CMake 3.13.
May be it could help in your particular case:
https://cmake.org/cmake/help/v3.13/policy/CMP0077.html#policy:CMP0077

you'll depend on latest CMake though.


>
> Now my problem: I could not find a way to get the behaviour I'd like. Is it
> possible to enforce the default for an option when its not specified by the
> user, even if a cache exists?
>

You mean you did not manage to force the cache value?
You can:
set(VAR "default_value" CACHE FORCE)

or the problem is you cannot know whether if a value has been user-provided?


> I tried to unset() the option from the cache but that does not do what I'd
> like.
>
> All the best,
>
> Mario Emmenlauer
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

[Eric Noulard]

Le mar. 27 nov. 2018 à 14:56, Mario Emmenlauer  a
écrit :

>
> Dear Eric,
>
> just to let you know, your suggestion of using a post-install-script
> for all system-wide links and files was indeed the solution to a working
> RPM package. Now my files are completely encapsulated in /opt/PKGNAME/
> and install works fine.
>

Thank you very much for the *positive* feedback, we don't always get those
:-)

This is nice to me and probably useful to others knowing it finally works.

Cheers,
Eric

Cheers and Thanks,
>
>Mario
>
>
>
> On 23.11.18 15:37, Mario Emmenlauer wrote:
> >
> > Dear Eric,
> >
> > thanks a lot for this help! I think I have the pointers to move forward!
> > One more detail below:
> >
> > On 23.11.18 11:36, Eric Noulard wrote:
> >> Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer  <mailto:ma...@emmenlauer.de>> a écrit :
> >> Dear Eric, thanks for the help! Below more:
> >>
> >> On 22.11.18 18:20, Eric Noulard wrote:
> >> > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <
> ma...@emmenlauer.de <mailto:ma...@emmenlauer.de>  ma...@emmenlauer.de
> >> <mailto:ma...@emmenlauer.de>>> a écri
> >> > I'm trying to build an RPM with CPack, and everything seems
> to work,
> >> > but the resulting package can not be installed. I get
> Transaction check
> >> > error:
> >> >   file / from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >> >   file /opt from install of  conflicts with file
> from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr/bin from install of  conflicts with
> file from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr/share from install of  conflicts with
> file from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr from install of  conflicts with file
> from package filesystem-3.2-25.el7.x86_64
> >> >
> >> > I've read in the CPackRPM source code about how to add
> excludes and
> >> > CPackRPM says that my "Final list of path to OMIT in RPM"
> would be
> >> >
>  
> /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
> >> >
> >> >
> >> > You can read the doc too:
> >> >
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
> >>
> >> Haha, done that! I've read everything I could find, including the
> >> docs and the excellent but hard-to-find community wiki at
> >> https://gitlab.kitware.com/cmake/community/wikis/home
> >>
> >>
> >> OK then you are up-to-doc then.
> >>
> >> > Could someone shed some light? I believe that the problem may
> be
> >> > my install command: I call install only once for the full tree
> >> > of files that I'd like to package:
> >> >   install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/"
> USE_SOURCE_PERMISSIONS)
> >> >
> >> > Yep this is looking for trouble.
> >> > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
> >> >
> >> > Can't you use relative path install DESTINATION ? For all
> files/target you build?
> >>
> >> I'm not sure if I can use a relative path. I want to build a system
> package
> >> that installs to /opt// with symlinks in /usr/bin/ and
> desktop
> >> files in /usr/share/applications/. Since files go into different
> paths below
> >> system root (/opt, /usr, maybe /var) I assume I need to install
> into root?
> >> Maybe I misunderstand?
> >>
> >>
> >> Not really. Usually you install in relative bin/ share/ man/ whatever
> other subdir you need.
> >> Then you define CPACK_PACKAGING_INSTALL_PREFIX (see
> https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html
> )
> >> to set up your "main" install prefix for your package. Every CPack
> generator has a default **packaging install prefix** (not to be confused
> with
> >> CMAKE_INSTALL_PREFIX).
> >> In your case:
> >> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt")
> >> which should even be (AFAIR) the default value for RPM and DEB.
> >>
> >> Concerning the

Re: [CMake] CPU specific compiler flags

[Eric Noulard]

Le lun. 26 nov. 2018 à 09:36, Ciccio Pasticcio 
a écrit :

> Hi all,
>
> I'm refactoring some libraries cmake files to be compliant to the use of
> targets instead of tons of variables. Since these libraries are
> cross-compiled I'm facing some problem finding how to properly set some
> specific flags like: -march -marm -mfloat-abi etc. For now I set the
> CMAKE_CXX_FLAGS:
>
> set(CMAKE_CXX_FLAGS -march=armv7-a -marm -mthumb-interwork
> -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -Wno-psabi)
>
> Is this the only way to do this?
>

I'm not sure to understand, you can perfectly setup flags on a target
specific way using 'target_compile_option'
https://cmake.org/cmake/help/latest/command/target_compile_options.html

If all your libraries are in a common directory you can use,
COMPILE_OPTIONS property on the directory
https://cmake.org/cmake/help/latest/prop_tgt/COMPILE_OPTIONS.html#prop_tgt:COMPILE_OPTIONS
to avoid repetition for each lib.

All that said, if you are cross-compiling those I bet you are using a
toolchain file (
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling
)
so if those "target-specific" compile options are global to your target
then you may set
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html#variable:CMAKE_%3CLANG%3E_FLAGS
in the toolchain.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

[Eric Noulard]

Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer  a
écrit :

>
> Dear Eric, thanks for the help! Below more:
>
> On 22.11.18 18:20, Eric Noulard wrote:
> > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer  <mailto:ma...@emmenlauer.de>> a écri
> > I'm trying to build an RPM with CPack, and everything seems to work,
> > but the resulting package can not be installed. I get Transaction
> check
> > error:
> >   file / from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >   file /opt from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >   file /usr/bin from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >   file /usr/share from install of  conflicts with file
> from package filesystem-3.2-25.el7.x86_64
> >   file /usr from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >
> > I've read in the CPackRPM source code about how to add excludes and
> > CPackRPM says that my "Final list of path to OMIT in RPM" would be
> >
>  
> /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
> >
> >
> > You can read the doc too:
> >
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
>
> Haha, done that! I've read everything I could find, including the
> docs and the excellent but hard-to-find community wiki at
> https://gitlab.kitware.com/cmake/community/wikis/home


OK then you are up-to-doc then.

> Could someone shed some light? I believe that the problem may be
> > my install command: I call install only once for the full tree
> > of files that I'd like to package:
> >   install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/"
> USE_SOURCE_PERMISSIONS)
> >
> > Yep this is looking for trouble.
> > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
> >
> > Can't you use relative path install DESTINATION ? For all files/target
> you build?
>
> I'm not sure if I can use a relative path. I want to build a system package
> that installs to /opt// with symlinks in /usr/bin/ and desktop
> files in /usr/share/applications/. Since files go into different paths
> below
> system root (/opt, /usr, maybe /var) I assume I need to install into root?
> Maybe I misunderstand?
>

Not really. Usually you install in relative bin/ share/ man/ whatever other
subdir you need.
Then you define CPACK_PACKAGING_INSTALL_PREFIX (see
https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html
)
to set up your "main" install prefix for your package. Every CPack
generator has a default **packaging install prefix** (not to be confused
with CMAKE_INSTALL_PREFIX).
In your case:
set(CPACK_PACKAGING_INSTALL_PREFIX "/opt")
which should even be (AFAIR) the default value for RPM and DEB.

Concerning the symlink in /usr/bin (or other places /usr/share etc...) this
usually done using post-install script
https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE

the script itself may call standard symlink creation like
https://linux.die.net/man/8/update-alternatives

Sometimes you *really* need absolute prefix like when you install in
/etc/init...
then for those (generally system) specific file you install them with
absolute destination.
CPackRPM is able to handle those as "config" file automatically.

> I have a wild guess that this install somehow includes the
> > directories, and probably it would be better to just call install
> > on the individual files?
> >
> > CPack RPM tries its best to avoid shipping directories he does not need
> to ship, but
> > RPM requires that any new (non shared) directory should be specified in
> the spec file,
> > so CPackRPM tries to "discover that" automatically and make the package
> relocatable.
> >
> > Installing a whole directory to an absolute DESTINATION (even "/" in you
> case) is probably
> > giving tough time to CPackRPM.
>
> There is something I don't understand: I can see that CPackRPM removes
> several things from CPACK_RPM_INSTALL_FILES, but later rpm complains
> about several of the removed items nonetheless. For example /usr/bin.
> Does that mean the filtering failed, or does the filter work but (somehow)
> the directory still ends up being packaged?
>

Evil usually hides in details.

Difficult to say without having the actual code and package to look into it.
Is your project public? If so could you provide us

Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

[Eric Noulard]

Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer  a écri

>
> I'm trying to build an RPM with CPack, and everything seems to work,
> but the resulting package can not be installed. I get Transaction check
> error:
>   file / from install of  conflicts with file from package
> filesystem-3.2-25.el7.x86_64
>   file /opt from install of  conflicts with file from package
> filesystem-3.2-25.el7.x86_64
>   file /usr/bin from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
>   file /usr/share from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
>   file /usr from install of  conflicts with file from package
> filesystem-3.2-25.el7.x86_64
>
> I've read in the CPackRPM source code about how to add excludes and
> CPackRPM says that my "Final list of path to OMIT in RPM" would be
>
> /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
>

You can read the doc too:
https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST


I can see that the conflicting directories are removed from
> CPACK_RPM_INSTALL_FILES. But that does not satisfy rpm :-(
>
> Could someone shed some light? I believe that the problem may be
> my install command: I call install only once for the full tree
> of files that I'd like to package:
>   install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/"
> USE_SOURCE_PERMISSIONS)
>

Yep this is looking for trouble.
How did you build the "${INSTALL_TMP_ROOT}" in the first place?

Can't you use relative path install DESTINATION ? For all files/target you
build?


> I have a wild guess that this install somehow includes the
> directories, and probably it would be better to just call install
> on the individual files?


CPack RPM tries its best to avoid shipping directories he does not need to
ship, but
RPM requires that any new (non shared) directory should be specified in the
spec file,
so CPackRPM tries to "discover that" automatically and make the package
relocatable.

Installing a whole directory to an absolute DESTINATION (even "/" in you
case) is probably
giving tough time to CPackRPM.


> I would prefer not to call install on the
> individual files because that overrides file permissions for every
> file, and I carefully prepared my package upfront to have the
> exact permissions for installation.
>

How did you "carefully prepared my package upfront" ?
And what do you mean by
"because that overrides file permissions for every file"

one more question, could you tell us which version of CPack/CMake you are
using?


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to find GTK3 in CMake

[Eric Noulard]

Le mer. 21 nov. 2018 à 09:46, David Demelier  a
écrit :

> Le 20/11/2018 à 17:03, Harry Mallon a écrit :
> > Hi,
> >
> > FindGTK and FindGTK2 exist in the CMake tree. How come there isn't one
> for GTK3? Should the GTK2 one work, or is there another way?
>
> GNOME people don't like CMake (they use meson). The philosophy behind
> CMake is to let upstream projects provides their own CMake configuration
> packages rather than providing Find modules for every single library
> existing in the world.
>

Right and the fact is even traced here:
https://gitlab.kitware.com/cmake/cmake/issues/15888



>
> CMake should already not provide any of these, but this general
> recommendation came after.
>
> It's the same thing for pkg-config, pkg-config by itself does not
> provide any .pc file.
>
> Also, Gtk is much more tied to Linux than being portable. I think that's
> why portable software don't use Gtk that much and thus, not CMake either.
>

Some project nevertheless uses GTK3 and CMake so that you may borrow
hopefully working
FindGTK3.cmake module from them:
E.g.
Darktable:
https://redmine.darktable.org/projects/darktable/repository/changes/cmake/modules/FindGTK3.cmake
WebKit:
https://github.com/WebKit/webkit/blob/master/Source/cmake/FindGTK3.cmake

and probably many others.
-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] ENV{SOURCE_DATE_EPOCH}

[Eric Noulard]

Le mar. 20 nov. 2018 à 22:40, Oleh Kravchenko  a écrit :

> 20.11.18 23:29, Brad King wrote:
> > SOURCE_DATE_EPOCH was created for use by packagers where tools
> > already wrap the build.  By making it an environment variable
> > packagers could jump through any number of build system layers
> > with no patching.
>
> That's makes me confused, because CMake has CPack.
> And with CPack process looks like:
> - `cmake && make package`
> So there are no any packagers tools, all work done with CMake.
>

The package tool here is CPack.
You consider CMake and CPack as monolithic software they were not designed
this way (and I personally find it nice to be so).

CMake and CPack (or CTest) may work together but they may well be used
independently.
Moreover they do not run at the same time, have a look at the figure here:
https://github.com/dev-cafe/cmake-cookbook/blob/master/figures/cmake-times/cmake-times.jpg

And you may see that setting environment var at configure time is
relatively far away from packaging time.

All that saif you are right CPack may honor SOURCE_DATE_EPOCH, and CMake
"may" forward the usage
of SOURCE_DATE_EPOCH from configuration time down to CPack time.

At least one CPack generator (the DEB one) recently honor SOURCE_DATE_EPOCH
https://gitlab.kitware.com/cmake/cmake/commit/548ac51d8ea319c65abefa0a771636893c45014c


If you use a
https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE
for your project
you may easily set the SOURCE_DATE_EPOCH env var at CPack time, i.e. when
CPack runs.



> > Build systems configure compilers with command-line flags, not
> > environment variables.  If you want to do this from within the
> > build system then GCC could be taught a new option for that.
>

Apparently gcc team decided to use env var for that:
https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html
see associated discussion (I did not read it all):
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02210.html

llvm/clang discussion on this does not seem to be closed:
https://reviews.llvm.org/D23934


> >
> > You could try hacking it with `CMAKE__COMPILER_LAUNCHER`:
> >
> >
> https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html
> >
> > e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or
> >
> > ```cmake
> > set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1)
> > ```
>
> Thank you, I will try that.
>

AFAIU this should already work with gcc.

I discovered https://reproducible-builds.org/, while reading your question.
The goal is nice, and I think CMake/CPack should support that for
compiler/[package] build tools that support it.

I won't have time to work on patches for that but I'll certainly take time
to read/test one if someone is working on it.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake 3.12 - python libs / 32 / 64 bits

[Eric Noulard]

Le jeu. 15 nov. 2018 à 09:47, Stéphane Ancelot  a
écrit :

> I agree. That was a debug snippet...but is wrong ... I setted up again the
> toolchain, but does not help.
>

If you are using a proper toolchain for 32bit compilation.
It looks like a bug in the find_package for Python in the cross-compiling
case.
Do you have a stripped down example which exhibit the issue?
Which version of CMake are you using?


>  So, I know where are include_dirs and libs  for 32 bits cross compiling,
> I have to hardcode it like this ?
>
>  add_library(python SHARED IMPORTED)
>  set_target_properties( python PROPERTIES IMPORTED_LOCATION /usr/lib32/
> libpython2.6.so )
>  target_include_directories(python SYSTEM ...
>

I think you can do that but it replaces the use of find_package(Python2
COMPONENTS Development)
may be fixing this would be a better long-term solution ?



>
>
> Le 14/11/2018 à 17:53, Marc CHEVRIER a écrit :
>
> The way you proceed is wrong.
> The system configuration is determined during the 'project' function call.
> Setting information after this call is useless. So, in your example, on a
> 64bit system, the compilation configuration will be 64bit (variable
> CMAKE_SIZEOF_VOID_P has value 8).
> This explain why 'FIND_LIBRARY_USE_LIB32_PATHS' has no effect. This
> property is taken in consideration only on 32bit systems.
>
> Moreover, I am not sure that modifying variable 'CMAKE_SYSTEM_PROCESSOR'
> is a valid action.
>
> To configure a 32bit compilation environment, two possibilities:
> * using environment variables: env CFLAGS=-m32 CXXFLAGS=-m32 cmake ...
> * using a toolchain file: see
> https://cmake.org/cmake/help/v3.13/manual/cmake-toolchains.7.html
>
>
> Le mer. 14 nov. 2018 à 14:06, Stéphane Ancelot 
> a écrit :
>
>> Hi,
>>
>> My system is 64 bits but I can cross compile python c modules for 32 bits
>> .
>>
>> Unfortunately I don't manage to retrieve python 32 libs , always the 64
>> bits version is found.
>>
>>
>> here is what I tried :
>>
>> cmake_minimum_required(VERSION 3.10)
>> project(py_autom)
>>
>>
>> set(CMAKE_SYSTEM_PROCESSOR "i686")
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
>> set(CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")
>>
>> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB32_PATHS TRUE)
>> set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS FALSE)
>>
>> include_directories(python2.6)
>> find_package(Python2 COMPONENTS Development)
>>
>>
>>
>> message(STATUS "python ${PYTHON_INCLUDE_DIRS} ${Python2_LIBRARIES_DIR}
>> ${Python2_FOUND}")
>>
>> Regards
>>
>> Steph
>> --
>>
>> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Eric Noulard]

Le mer. 14 nov. 2018 à 13:25, Poughon Victor  a
écrit :

> Yes you are correct on all your observations. We already use ninja and
> ccache wherever we can. In fact we have an issue about the whole end-to-end
> build performance where we track all effort on this throughout the project
> (if you're interested:
> https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1649)
>

End-to-end build performance is a subject of interest to me, I'll have a
look.


> There are indeed quick and easy wins to be had with those tools (and we
> are working on it). But my original question is not about that. It's about
> speeding up the configure step with makefile generator. I still don't think
> it's normal that it does hundreds of thousands of I/O on files that are a
> few bytes or even empty. However it's possible that it's because we do
> something incorrect in our CMakeLists.txt and not CMake's fault.
>

I don't really know makefile-generator internals so I cannot tell.
For sur the current OTB build dir constructed with Makefile generator is
spitting out around 180 Makefile.
May be you can profile the cmake execution by building a debug version of
CMake and collect more precise insight on where the bottlenecks may reside.

You may track try_compile which could obviously be slow and may be
configure_file as well.
Otherwise I don't know, I guess you'll have to profile the cmake run.

It's true that a few minutes of configure is not much when doing a full
> build, but consider incremental builds where all you do is change one cxx
> file (and cmake is triggered because you changed git branch or something).
> Then the generate step is a significant part of the time you wait.
>

Yes that right.
Note however that changing git branch should nor per-se trigger a cmake run.
Only changing a CMakeLists.txt or configured file or explicitely specified
by
CMAKE_CONFIGURE_DEPENDS.

Otherwise changing branch with git that only modifies source shouldn't
trigger cmake rebuild.
I do that all the time in a classical git branch dev model.



-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Eric Noulard]

Le mer. 14 nov. 2018 à 12:06, Poughon Victor  a
écrit :

> Thanks for the replies
>
>
>
> You can see configure times on our dashboard (switch to advanced view):
> https://dash.orfeo-toolbox.org/index.php?project=OTB
>
> It ranges from 1-3min. There's even one windows machine that's at 4m30s.
>

Somes windows system are known to be slow on many files accesses.
However on this particular machine (
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=342008 I guess) you
already seem
to be using NInja + MSVC. so many small files access to ?makefiles? should
not be the culprit.

That said whatever the system your build and test time seems to dominate
the overall time (in the CI).

I have had great speed-up experience using CMake+ninja+ccache  for our
build in CI. We did go from 1 hour down to less than 10min.
We only have various linux build (no Windows) it is really a big time
savior combo.

We even share the compil' cache between the CI and the developers. So
everybody is feeding compile cache and takes benefits from others including
CI.

You seem to be using that as well here:
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=341993
and you get less than 5min build time which corroborate my suggestion.

The same machine build with clang:
https://dash.orfeo-toolbox.org/buildSummary.php?buildid=342033 is lasting
30min+
and is not using ccache.


> Thanks for the tip about Ninja generator, it's indeed much faster. But
> switching the entire dev team + CI servers from make to ninja is not really
> an option for us right now because of a bug in ninja that affects our
> SuperBuild configuration (see here if you're interested in the details:
> https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1625)
>

I see.
Not using ninja in the Superbuild case does not mean you cannot use it in
other cases, right?
May be the one-size fits all is a little too much to ask at this point? My
opinion though.
Did you report the issue upstream (ninja or cmake)?

I was impressed in the past by the amount of tests orfeo is doing, I'm
still are !!
Are you running those tests in parallel (with ctest --parallel) ? It can be
a time savior as well is the running machine has a fair amount of cores and
memory.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tips on reducing configure time

[Eric Noulard]

Hi Victor,

Le mer. 14 nov. 2018 à 10:20, Poughon Victor  a
écrit :

> Hi all
>
> I am working on a large C++ project using CMake (
> https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a
> lot of time. This can be annoying for developers working on features where
> the configure step needs to be re-run, or for CI in general.
>

Could you give us a clue on "takes quite a lot of time"?
Are we speaking of tens of seconds, minutes etc... ?


>
> We have looked into it a bit and it seems like one issue is that the
> configure/generate steps do a lot of small files I/O. Specifically, using:
>
> inotofy-wait -mr 
>
> shows that "cmake ." causes about 150K file access/modify, etc. There are
> some especially guilty looking files like 'Makefile2.tmp' or 'progress.tmp'
> that appear thousands of times in most of the log file.
>
> I have an SSD which somewhat helps, but for colleagues still on mechanical
> drives this is especially painful. Is there a way to disable writing all
> those files to the disk?
>
> Any other tips on optimizing the performance of 'cmake .'?
>

Did you try to test drive a switch to ninja generator ?
Ninja generator generates only two files (build.ninja and rules.ninja) you
won't have the "mny small files issue".
You can have long configuration times as well but not coming from file
access.




>
> Thanks,
>
> Victor Poughon
>
>
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Preferred case for macro names?

[Eric Noulard]

Le mar. 13 nov. 2018 à 10:41, Marc CHEVRIER  a
écrit :

> I agree as well that trying to distinguish macros from functions is not a
> good idea because functions can act in the same way as macros (i.e.
> changing calling environment) but with a better control over environment
> changes (changes are done explicitly by using 'set(... PARENT_SCOPE)').
>
> so also +1 for lower case for every function, macro or builtin. And good
> point to standardize  macro or function OPTION to UPPERCASE.
>
> Now, for variables, the problem is a bit different because they are case
> sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two
> different variables.
>

Yes damn right.


> My personal tendency is to use lower case for local variables and upper
> case for global variables. May be we can normalize variables to upper case
> regarding global variables used by CMake itself (which is globally the
> current rule).
>

Having a convention for local is nice and I tend to prefix with _ (single
or double) variables that should be local.
lowercasing locals is fine too, however I think that enforcing casing on
"user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and
CPACK_
I guess they already are all UPPERCASE so we may stick with this as a
convention?

A small quote to the cmake-format (
https://github.com/cheshirekow/cmake_format) tool which is trying to
beautify CMakeLists.txt, I'm not using it on complex projects
because it still has some issues but I find it otherwise useful.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Preferred case for macro names?

[Eric Noulard]

Le mar. 13 nov. 2018 à 00:21, Craig Scott  a
écrit :

>
>
> On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke 
> wrote:
>
>> My understanding was that prevalent usage in modern CMake
>> is all lowercase for function names, all uppercase for
>> macro names. In this sense, I submitted a number of merge
>> requests where function and macro names are normalized, and
>> in
>>https://gitlab.kitware.com/cmake/cmake/merge_requests/2607
>> I suggest an explicit recommendation in the macro and
>> function doc pages.
>>
>> Now I am learning from Craig Scott that the more recent
>> convention is actually all lowercase for macros as well
>> as for functions.
>>
>
> To be clear, my understanding is that in the past (many years ago),
> uppercase tended to be common, but I don't see that used much these days
> for functions, macros or built-in commands. The general sentiment seems to
> be that uppercase tends to be a bit "shouty" now. I'm suggesting that if
> we're going to bring some consistency to the docs, I propose that we just
> go with lowercase everywhere (functions, macros, built-in commands and
> examples).
>
> 
> Regarding the finer points of macros versus functions versus built-in
> commands and establishing a convention, it's actually a bit difficult to
> draw a hard line in behaviour across all three. Consider commands like
> find_package() and project(). These are built-in commands, but they behave
> like a macros in that they add variables to the calling scope (yes,
> functions can do that too, but the primary reason to use macros is to
> inject variables into the calling scope). Most built-in commands act more
> like functions and do not modify the calling scope. Trying to decide
> whether built-in commands act like macros and which do not and making them
> upper or lowercase based on that is unlikely to be a distinction that most
> users would make, so a mix of upper and lowercase for built-in commands
> would be unexpected. A consequence of this is that having macros and
> functions with differing case conventions would seem to create a potential
> inconsistency with whatever convention is used for built-in commands. The
> only way to really have consistency here would seem to be just use the one
> case convention, for which lowercase seems to be the logical and
> increasingly prevalent choice.
> 
>

I would add that sometimes useful macro/function may become builtin
See example for include_guard in
https://github.com/dev-cafe/cmake-cookbook/blob/master/chapter-07/recipe-06/example/CMakeLists.txt

So differentiating macro/function/builtin by their case does not seems a
good option to me.
My personal opinion though.

+1 for lower case for every function, macro or builtin.
macro or function OPTION are UPPERCASE
properties are UPPERCASE as well
and I personnally tend to define CMake VARIABLES as uppercase too.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CPack disable build all

[Eric Noulard]

Le ven. 9 nov. 2018 à 17:22, DKLind  a écrit :

> I have a very large project where each sub-project creates a debian
> package.
>
> When "make/ninja package" is specified, it performs a "make/ninja all"
> before packaging. I would prefer to perform a "make/ninja all" myself
> before
> I doing a "make/ninja package".
>
> I want to create a package for just one target. I can use "cpack -D
> CPACK_COMPONENTS_ALL=" to do this but, CPack takes a long time to
> create the package. I can only surmise that CPack is building everything in
> the background, as there is no output. If I have everything build BEFORE i
> run "cpack -D CPACK_COMPONENTS_ALL=", it completes in seconds.
>

I'm almost sure that when invoked on itself like:

cpack -G TGZ

cpack does not build at all.
cpack does install but AFAIK it does not trigger the build.

you can try:

ninja clean
cpack -V -G TGZ

and I'm pretty sure CPack will fail because it won't find the expected bits
to be installed precisely because they are not built.

Note that using "-V" verbose option of CPack you'll more traces of what
CPack does.


> Is it possible to disable CPack from building everything?
>

If you observe that could you send us a stripped down project that exhibit
this behavior?

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] option to prevent in-source builds

[Eric Noulard]

Just a small remark to say this request of "builtin" way to forbid
in-source is quite old:
https://gitlab.kitware.com/cmake/cmake/issues/6672
which find its origin in:
https://cmake.org/Bug/view.php?id=6672

I don't know if the note from that initial discussion are valid nowadays
but the fact that:
"Code in CMakeLists.txt is not even executed until after the cache is
initialized so there would have to be some other way to indicate in the
source tree that it should not be built in-source."
and the fact that
"The cache is initialized before the procedural steps start to run. With
cmake-gui or the cmake command-line "-D" option it is even possible to
store entries in the cache before CMake even parses CMakeLists.txt"
almost implies that this should be done outside CMakeLists.txt

That said, I think that
I would rather have some obviously visible and fixed place like
CMakeInit.json that should be located in the very same directory as the
concerned CMakeLists.txt rather than some list of possible places (cmake/,
cmake/init, .cmake, etc...). The exact path to CMakeInit.json could be
overwritten by some new command line option, like --init-file if for some
reason we want
a configurable place (may be used in various CI scripts occasion).
This file could hold more options than "just forbid in-source" it could
indicate a default generator (which may be different from the usual default
generator on the concerned platform),
some a toolchain. It's usage would be different than the initial cache
precisely because it could work before cache is created.


Le ven. 9 nov. 2018 à 17:03, Ben Boeckel  a écrit :

> On Fri, Nov 09, 2018 at 07:28:54 -0500, Taylor Holberton wrote:
> > A lot of projects that use CMake already have a `./cmake` directory, I
> > would think `./cmake/init.json` would fit nicer as opposed to the hidden
> > directory. I'm not a fan of hidden directories in software projects
> anyway.
>
> There are also `./CMake` directories. HDF5 uses `./config/cmake`. I
> think just claiming a "hidden" directory with exact casing is better.
>
> --Ben
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Signing individual binary and problem with PackageMaker CPack generator

[Eric Noulard]

Le mar. 23 oct. 2018 à 12:06, Craig Scott  a
écrit :

>
>
> On Tue, Oct 23, 2018 at 4:43 PM Eric Noulard 
> wrote:
>
>> Le lun. 22 oct. 2018 à 23:05, Craig Scott  a
>> écrit :
>>
>>>
>>>> Yes I agree that having build rpath is useful.
>>>> I am not aware of any mechanism that enable calling some tool during
>>>> CPack's install step.
>>>> Moreover I don't use MacOS at all so I don't have any experience with
>>>> PackageMaker.
>>>>
>>>> May be some Mac user may shed some more light on this.
>>>>
>>>
>>> You should be able to do this using install(SCRIPT) or install(CODE),
>>> invoking the code signing through execute_process() as part of that
>>> script/code.
>>>
>>
>> I wasn't sure of that.
>>
>> So just to be clear  do we know for sure that install(SCRIPT)
>> install(CODE) will run after the CMake builtin-generated install scripts?
>> The builtin generated install script for target includes stripping, so
>> for signing to work as expect we should be sure of the execution order?
>> Or may be you suggest not to install(TARGET) for the concerned target and
>> write install(SCRIPT) replacement for those?
>>
>
> My understanding is that install() commands are generally processed in the
> order in which they appear in the directory scope. It is unspecified how
> the order between directory scopes behaves, although this merge request
> <https://gitlab.kitware.com/cmake/cmake/merge_requests/2434> (now merged
> to master) makes things much more predictable.
>
> I missed the earlier detail about when stripping occurred in relation to
> installing. From what I can see, I think the stripping happens right after
> the executable is copied/installed. Have a look at the generated
> cmake_install.cmake file for one of your builds and search for
> CMAKE_INSTALL_DO_STRIP to see how things get processed. If you add your own
> install(CODE) or install(SCRIPT) calls after you've done the
> install(TARGETS) calls, I would expect them to come after the stripping,
> but I haven't tested this.
>

I'll have a look, not that I need it but I'd like to know.
Thank you Craig.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] how to debug CPack creation

[Eric Noulard]

Le mar. 23 oct. 2018 à 08:07, Илья Шипицин  a écrit :

> Eric, thank you for your review.
> I still wonder why is it so complicated (my expectation was "ok, since I
> use both cmake and cpack, they should work together")
>

The main reason is that CPack was first design as a standalone tool that
can be used without CMake.
I guess that some project may still be using that way.
CMake has a "simple" way to generate CPackConfig.cmake file that drives the
CPack run but you can generate those files
by other mean and still be using CPack, without CMake.



> can you please review
> https://github.com/SoftEtherVPN/SoftEtherVPN/commit/139fffe6e0c218f580cd8a397d94856be37fa947
> (it is based on your suggestions)
>

I made comment on this commit, basically don't generate *any* file in
source tree it's a [relatively] bad habit.
If a file is an artefact of the build then it belongs to build tree.

As a matter of fact you CI build tree seems to /tmp (from your
configure script) but if ever this is changing it'll break the build
use CMAKE_BINARY_DIR.

I think it should work now but your CI will show you if it's ok.

Now concerning your CMAKE_INSTALL_PREFIX if your CI is producing ready to
use .deb / .rpm etc... package then
you'd better use "/opt" as a prefix as suggested by Craig.




> сб, 20 окт. 2018 г. в 17:59, Eric Noulard :
>
>>
>>
>> Le sam. 20 oct. 2018 à 10:54, Илья Шипицин  a
>> écrit :
>>
>>>
>>>
>>> сб, 20 окт. 2018 г. в 13:30, Eric Noulard :
>>>
>>>>
>>>>
>>>> Le sam. 20 oct. 2018 à 10:15, Илья Шипицин  a
>>>> écrit :
>>>>
>>>>> hi,
>>>>>
>>>>> we use cmake/cpack for mangling systemd scripts
>>>>>
>>>>>
>>>>> https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/vpnserver/CMakeLists.txt#L26
>>>>>
>>>>> what happens:
>>>>>
>>>>> (*) deb installs files to /usr/libexec
>>>>> (*) cmake sets location as /usr/local/libexec
>>>>>
>>>>
>>>> It looks like your get default "/usr/local" prefix from somewhere.
>>>>
>>>
>>> exactly.
>>>
>>
>> So I I understand it well (correct me if I'm wrong) when you do:
>>
>> 1) make install
>> You get all installed files prefixed by /usr/local
>> which is the expected behaviour unless you configure
>> CMAKE_INSTALL_PREFIX
>> or you use
>> DESTDIR=/your/prefix make install
>>
>> 2) deb created by CPack get "/usr" prefix instead
>>which is the expected behaviour unless you specify an alternate value
>> using
>>CPACK_PACKAGING_INSTALL_PREFIX
>>
>> go to your build tree and try:
>> cpack -G DEB -D  CPACK_PACKAGING_INSTALL_PREFIX=/opt
>>
>> and you'll see that the .deb will have /opt prefix.
>>
>> The question is what do expect as a prefix?
>> /usr/local
>> /usr
>> something else ??
>>
>> The rules are the following when using install rule.
>> 1) if your DESTINATION is a relative path then it will be prefix with
>>CMAKE_INSTALL_PREFIX when doing make install
>>CPACK_PACKAGING_INSTALL_PREFIX when building package with CPack
>>
>> 2) if your DESTINATION is "absolute" like /etc/whatever/confdir
>> It'll get install there when doing make install (whatever the value
>> of  CMAKE_INSTALL_PREFIX)
>>
>> With CPack, it depends on the generator.
>>Some generators (like DEB a,nd RPM) try to catch "absolute" install
>> file and handle them
>>as config file. RPM generator is more verbose about it see below.
>>
>> Is the RPM containing what you expect?
>>>>
>>>
>>> I did not check it yet.
>>>
>>
>> I tried using:
>> $  cpack -G RPM
>>
>> and you get expected warning about the mix of absolute and relative
>> install path:
>> CPack: Create package using RPM
>> CPack: Install projects
>> CPack: - Install project: SoftEtherVPN
>> CPack: -   Install component: vpnserver
>> CPack: -   Install component: vpnclient
>> CPack: -   Install component: vpnbridge
>> CPack: -   Install component: vpncmd
>> CPack: Create package
>> CMake Warning (dev) at
>> /home/enoulard/local/share/cmake-3.12/Modules/Internal/CPack/CPackRPM.cmake:135
>> (message):
>>   CPackRPM:Warning: Path /lib/systemd/system/softether-vpnbridge.service
>> is
>>   not on one of the relocatable paths! Package will be partially

Re: [CMake] Signing individual binary and problem with PackageMaker CPack generator

[Eric Noulard]

Le lun. 22 oct. 2018 à 23:05, Craig Scott  a
écrit :

>
>> Yes I agree that having build rpath is useful.
>> I am not aware of any mechanism that enable calling some tool during
>> CPack's install step.
>> Moreover I don't use MacOS at all so I don't have any experience with
>> PackageMaker.
>>
>> May be some Mac user may shed some more light on this.
>>
>
> You should be able to do this using install(SCRIPT) or install(CODE),
> invoking the code signing through execute_process() as part of that
> script/code.
>

I wasn't sure of that.

So just to be clear  do we know for sure that install(SCRIPT) install(CODE)
will run after the CMake builtin-generated install scripts?
The builtin generated install script for target includes stripping, so for
signing to work as expect we should be sure of the execution order?
Or may be you suggest not to install(TARGET) for the concerned target and
write install(SCRIPT) replacement for those?


Taking a step back though, I don't know what your package contains, but if
> you're creating an app bundle, then you don't need CPack at all. An app
> bundle is already self contained and you should be able to get it to build
> with install RPATH, at which point it should find everything it needs. An
> advantage of building with install RPATH is that you can also make use of
> the XCODE_ATTRIBUTE target property support to set up the code signing and
> have Xcode/xcodebuild drive the whole code signing process for you. It's
> likely to be easier that way and is more compatible with tools like
> Fastlane , if you end up heading in that
> direction. But if you have embedded frameworks, then yeah, you probably end
> up having to do things manually yourself (CMake doesn't yet handle those
> well and has no direct support for it).
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> New book released: Professional CMake: A Practical Guide
> 
>

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Signing individual binary and problem with PackageMaker CPack generator

[Eric Noulard]

Le lun. 22 oct. 2018 à 11:56, Anatoly Belyaev  a écrit :

> We use "PackageMaker" generator on MacOS.  But i don't think it is CPack
> specific tool does call strip command.  The code for RPATH rewrite and
> strip cmd is located in cmake_install.cmake. As i understand CPack calls
> make install to tmp dir and then creates package.
>

Sorry I've just realized it was in the title of your message.
I wasn't aware that stripping was done during install.


> Having different RPATH for build tree is useful. May be there is a way to
> call sign tool in the install stage? But reading the doc to CMake install
> command, doesn't help me find solution for this.
>

Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during
CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with
PackageMaker.

May be some Mac user may shed some more light on this.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] how to debug CPack creation

[Eric Noulard]

>
>
> And the content is:
> $ rpm -qpl softether-vpnserver-5.1.9660-1.x86_64.rpm
> /lib
> /lib/systemd
> /lib/systemd/system
> /lib/systemd/system/softether-vpnserver.service
> /usr/libexec
> /usr/libexec/softether
> /usr/libexec/softether/vpnserver
> /usr/libexec/softether/vpnserver/hamcore.se2
> /usr/libexec/softether/vpnserver/vpnserver
> /usr/local
> /usr/local/bin
> /usr/local/bin/vpnserver
>
> the content of the .deb is similar:
> $ dpkg-deb -c softether-vpnserver_5.1.9660_amd64.deb
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/system/
> -rw-r--r-- root/root   700 2018-10-20 14:45
> ./lib/systemd/system/softether-vpnserver.service
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/softether/
> drwxr-xr-x root/root 0 2018-10-20 14:45
> ./usr/libexec/softether/vpnserver/
> -rw-r--r-- root/root   1770716 2018-10-20 14:45
> ./usr/libexec/softether/vpnserver/hamcore.se2
> -rwxr-xr-x root/root   2088960 2018-10-20 14:45
> ./usr/libexec/softether/vpnserver/vpnserver
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/
> drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/bin/
> -rwxr-xr-x root/root72 2018-10-20 14:45 ./usr/local/bin/vpnserver
>
> The main question is, what filesystem layout do you expect for those files?
>
>
Now I think I get it.
IN vpnserver CMakeLists.txt you do:

install_systemd_service("vpnserver"
"${CMAKE_SOURCE_DIR}/systemd/softether-vpnserver.service"
"${CMAKE_INSTALL_FULL_LIBEXECDIR}/softether/vpnserver/vpnserver")

So at this point (during CMake config step)
"${CMAKE_INSTALL_FULL_LIBEXECDIR}/softether/vpnserver/vpnserver"
is /usr/local/softether/vpnserver/vpnserver

In your install_systemd_service CMake macro wrapper you do:

macro(install_systemd_service component file_path binary_path)
get_filename_component(file_name ${file_path} NAME)
get_filename_component(binary_directory ${binary_path} DIRECTORY)

file(READ ${file_path} FILE_CONTENT)
string(REPLACE "[DIRECTORY]" ${binary_directory} FILE_CONTENT
${FILE_CONTENT})
string(REPLACE "[BINARY]" ${binary_path} FILE_CONTENT ${FILE_CONTENT})
file(WRITE ${CMAKE_SOURCE_DIR}/tmp/systemd/${file_name} ${FILE_CONTENT})
...

So you generate a systemd service file which contains /usr/local prefix
because this is the one which
is know during "CMake configuration step".

You cannot do that this way with .deb or .rpm because you don't know the
"actual" prefix that will be in the package
because it is controlby CPACK_PACKAGING_INSTALL_PREFIX  "at CPack time",
i.e. when CPack runs.

It's even worse because .deb or .rpm may be relocated see e.g.:
https://www.cyberciti.biz/faq/howto-install-rpm-package-into-another-directory/

When you want to install script that should know where things get installed
you have 3 options:

1) Assume the binary executable is installed in the path
thus call the executable as-is "vpnserver" without absolute path

2) Put a pre- or post- install script that will compute the appropriate
path
   **during package installation** when you are sure what the real path
will be.
   Have a look at CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA in
https://cmake.org/cmake/help/latest/cpack_gen/deb.html
or
https://cmake.org/cmake/help/latest/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE

3) Ensure that you generate package with
   CMAKE_INSTALL_PREFIX == CPACK_PACKAGING_INSTALL_PREFIX
   This is ok but will break if the installation of the package is
relocated.

1) may be ok.
2) need a little work but is the more robust
3) may be enough but prevent relocatable install

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] how to debug CPack creation

[Eric Noulard]

Le sam. 20 oct. 2018 à 10:54, Илья Шипицин  a écrit :

>
>
> сб, 20 окт. 2018 г. в 13:30, Eric Noulard :
>
>>
>>
>> Le sam. 20 oct. 2018 à 10:15, Илья Шипицин  a
>> écrit :
>>
>>> hi,
>>>
>>> we use cmake/cpack for mangling systemd scripts
>>>
>>>
>>> https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/vpnserver/CMakeLists.txt#L26
>>>
>>> what happens:
>>>
>>> (*) deb installs files to /usr/libexec
>>> (*) cmake sets location as /usr/local/libexec
>>>
>>
>> It looks like your get default "/usr/local" prefix from somewhere.
>>
>
> exactly.
>

So I I understand it well (correct me if I'm wrong) when you do:

1) make install
You get all installed files prefixed by /usr/local
which is the expected behaviour unless you configure
CMAKE_INSTALL_PREFIX
or you use
DESTDIR=/your/prefix make install

2) deb created by CPack get "/usr" prefix instead
   which is the expected behaviour unless you specify an alternate value
using
   CPACK_PACKAGING_INSTALL_PREFIX

go to your build tree and try:
cpack -G DEB -D  CPACK_PACKAGING_INSTALL_PREFIX=/opt

and you'll see that the .deb will have /opt prefix.

The question is what do expect as a prefix?
/usr/local
/usr
something else ??

The rules are the following when using install rule.
1) if your DESTINATION is a relative path then it will be prefix with
   CMAKE_INSTALL_PREFIX when doing make install
   CPACK_PACKAGING_INSTALL_PREFIX when building package with CPack

2) if your DESTINATION is "absolute" like /etc/whatever/confdir
It'll get install there when doing make install (whatever the value of
CMAKE_INSTALL_PREFIX)

With CPack, it depends on the generator.
   Some generators (like DEB a,nd RPM) try to catch "absolute" install file
and handle them
   as config file. RPM generator is more verbose about it see below.

Is the RPM containing what you expect?
>>
>
> I did not check it yet.
>

I tried using:
$  cpack -G RPM

and you get expected warning about the mix of absolute and relative install
path:
CPack: Create package using RPM
CPack: Install projects
CPack: - Install project: SoftEtherVPN
CPack: -   Install component: vpnserver
CPack: -   Install component: vpnclient
CPack: -   Install component: vpnbridge
CPack: -   Install component: vpncmd
CPack: Create package
CMake Warning (dev) at
/home/enoulard/local/share/cmake-3.12/Modules/Internal/CPack/CPackRPM.cmake:135
(message):
  CPackRPM:Warning: Path /lib/systemd/system/softether-vpnbridge.service is
  not on one of the relocatable paths! Package will be partially
relocatable.
Call Stack (most recent call first):

/home/enoulard/local/share/cmake-3.12/Modules/Internal/CPack/CPackRPM.cmake:1001
(cpack_rpm_prepare_relocation_paths)

/home/enoulard/local/share/cmake-3.12/Modules/Internal/CPack/CPackRPM.cmake:1870
(cpack_rpm_generate_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

[...]

CPack: - package: []/build/softether-vpnbridge-5.1.9660-1.x86_64.rpm
generated.
CPack: - package: []/build/softether-vpnclient-5.1.9660-1.x86_64.rpm
generated.
CPack: - package: []/build/softether-vpncmd-5.1.9660-1.x86_64.rpm generated.
CPack: - package: []/build/softether-vpnserver-5.1.9660-1.x86_64.rpm
generated.

And the content is:
$ rpm -qpl softether-vpnserver-5.1.9660-1.x86_64.rpm
/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/softether-vpnserver.service
/usr/libexec
/usr/libexec/softether
/usr/libexec/softether/vpnserver
/usr/libexec/softether/vpnserver/hamcore.se2
/usr/libexec/softether/vpnserver/vpnserver
/usr/local
/usr/local/bin
/usr/local/bin/vpnserver

the content of the .deb is similar:
$ dpkg-deb -c softether-vpnserver_5.1.9660_amd64.deb
drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./lib/systemd/system/
-rw-r--r-- root/root   700 2018-10-20 14:45
./lib/systemd/system/softether-vpnserver.service
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/libexec/softether/
drwxr-xr-x root/root 0 2018-10-20 14:45
./usr/libexec/softether/vpnserver/
-rw-r--r-- root/root   1770716 2018-10-20 14:45
./usr/libexec/softether/vpnserver/hamcore.se2
-rwxr-xr-x root/root   2088960 2018-10-20 14:45
./usr/libexec/softether/vpnserver/vpnserver
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/
drwxr-xr-x root/root 0 2018-10-20 14:45 ./usr/local/bin/
-rwxr-xr-x root/root72 2018-10-20 14:45 ./usr/local/bin/vpnserver

The main question is, what filesystem layout do you expect for those files?

-- 
Eric
-- 

Powered by www.kitware.com

Please keep messages on-t

Re: [CMake] how to debug CPack creation

[Eric Noulard]

Le sam. 20 oct. 2018 à 10:15, Илья Шипицин  a écrit :

> hi,
>
> we use cmake/cpack for mangling systemd scripts
>
>
> https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/vpnserver/CMakeLists.txt#L26
>
> what happens:
>
> (*) deb installs files to /usr/libexec
> (*) cmake sets location as /usr/local/libexec
>

It looks like your get default "/usr/local" prefix from somewhere.
The installation prefix of CPack is controlled by the
https://cmake.org/cmake/help/latest/variable/CPACK_PACKAGING_INSTALL_PREFIX.html
variable.
Each CPack generator has a default value for that (if you don't specify it).

How do run cpack?
Do you do "make package" or do you run
cpack -G DEB

Which version of cmake/cpack are you using?


> as a result: it does not work (systemd cannot find executable)
>
> https://gitlab.com/chipitsine/SoftEtherVPN/-/jobs/110262386
>
> I enabled "set(CPACK_DEBIAN_PACKAGE_DEBUG ON)", but it did not provide me
> a clue.
>

DEB generator is not as verbose as I thought.

Do you generate RPM as well? RPM is more verbose and leaves you log file in
_CPack_Packages//RPM/

Is the RPM containing what you expect?

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Detailed graphviz graph?

[Eric Noulard]

Le sam. 6 oct. 2018 à 18:15, Jan Wielemaker  a écrit :

> On 03/10/18 09:53, Eric Noulard wrote:
> >
> > Are those three add_custom_xxx in the same directory?
> > DEPENDS for custom_xxx do not cross directory.
>
> So this was not the problem. The problem was that on the Mac I had build
> the system before using the autoconf/make suite, which had created
> `swipl.prc` in the source tree. Now, this is the second time I've been
> fooled by this:
>

Good to know you've found the issue.


> If a custom command has a DEPENDS, this points at the
> CMAKE_CURRENT_SOURCE_DIR if the file exists there and at the
> CMAKE_CURRENT_BINARY_DIR otherwise.  This makes sense, but
> easily leads to things that are hard to figure out ...
>

I've already been bitten by that kind of issue.
Now when I want to be "extra-sure" of my source/build tree state I:

- remove the build tree completely
- use the VCS at hand to clean the source tree, e.g. with git
  git -fdx being in the root source dir should remove all non versioned
files (or directories) including ignore ones.
(there are more interesting feature to git-clean:
https://git-scm.com/docs/git-clean)

Then you can be sure to have a "clean" starting point.
Alternatively checking out the project in a separate place works as well.

Thanks. In particular for pointing at Ninja's tools for figuring out
> dependencies.
>

You are welcome.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

[Eric Noulard]

Le jeu. 4 oct. 2018 à 18:59, Marc CHEVRIER  a
écrit :

> I am afraid that you cannot mix "optimized" or "debug" keywords with
> "generator expressions" because keywords handling is done during evaluation
> of command "target_link_libraries" and "generator expressions" are
> evaluated during generation.
>
> And target_link_libraries expect following pattern: [] 
> [ ...], so specifying a generator expression wrapping this breaks
> the parsing of the arguments: keyword is no longer at the beginning of the
> sequence so it is no longer  recognized as is...
>
> So, The most efficient way to work-around this problem is to transform
> your list of libraries in valid generator expressions:
>
>- INITIAL: optimized foo debug food_d
>- RESULT: $<$:foo> $<$:foo_d>
>
> For that purpose, an helper function can do the trick...
>

I agree with you Marc but I nevertheless think the handling of list in
genex has something unexpected.

See my previous example with custom target.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

[Eric Noulard]

Le jeu. 4 oct. 2018 à 18:34, Björn Blissing  a
écrit :

> Hi Andrew,
>
>
>
> That works, but as previously said. The third party find module I am using
> do not differentiate between debug and release libraries. To make matters
> even worse the keywords “optimized” and “debug” is already in the variable
> list, trying to split them will be painful.
>
>
>
> The workaround I am using right now is to have an IF-statement for the
> list option:
>
> if(${USE_FOOLIB})
>
> target_link_libraries(my_exe
>
> PUBLIC
>
> ${FOO_LIBRARIES}
>
> )
>
> endif()
>
>
>
>
>
> target_link_libraries(my_exe
>
> PUBLIC
>
>  $<$:bar>
>
> )
>
>
>
> But that breaks the pattern with using generator expressions, as I do for
> the rest of my options.
>
>
>
> I don’t know if this should be considered a bug, but it seems really
> strange that generator expressions should break down for only this special
> case, i.e. the combination using lists with the conditional operator BOOL
> and using it inside target_link_libraries.
>

I think you are right there is a bug.
When you put a list on the right hand-side of $>>>> cut here <<<<
cmake_minimum_required(VERSION 3.12)

project(expansion_error LANGUAGES CXX)
add_executable(my_exe main.cpp)

option(USE_ANYLIB "Use foo.lib" ON)
option(USE_BARLIB "Use bar.lib" ON)

list(APPEND ANY_LIBRARIES any1 any2)

target_link_libraries(my_exe
PUBLIC
 $<$:"${ANY_LIBRARIES}">
 $<$:bar>
)

add_custom_target(ShowMe
COMMAND ${CMAKE_COMMAND} -E echo
$<$:${ANY_LIBRARIES}>
COMMAND ${CMAKE_COMMAND} -E echo $<$:bar>
VERBATIM
)
>>>>>>>>> cut here <<<<<<<<<<<<<

then:
$ make ShowMe

gives:
$<1:any1 any2>
bar
which seems wrong too.

In the TLL you get "$<1:any1 -lany2>" in either Makefile or ninja generator
whereas you get proper "-lbar"

I don't know why this happen but it really looks like a bug.


>
>
> I don’t know if other CMake functions will react similarly bad to the
> list/bool operator combo.
>
>
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Andrew Fuller 
> *Sent:* Thursday, October 4, 2018 6:16 PM
> *To:* Björn Blissing ; Eric Noulard <
> eric.noul...@gmail.com>
> *Cc:* CMake Mailinglist 
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> What about this:
>
>
>
>
> list(APPEND FOO_LIBRARIES_OPT foo)
> list(APPEND FOO_LIBRARIES_DBG foo_d)
>
> target_link_libraries(my_exe
>PUBLIC
> debug "$<$:${FOO_LIBRARIES_DBG}>"
> optimized "$<$:${FOO_LIBRARIES_OPT}>"
> "$<$:bar>"
> )
>
> A little more verbose.
> --
>
> *From:* Björn Blissing 
> *Sent:* October 4, 2018 9:00:28 AM
> *To:* Andrew Fuller; Eric Noulard
> *Cc:* CMake Mailinglist
> *Subject:* RE: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> Hi Andrew,
>
>
>
> When I put the genex inside double quotes I get:
>
> optimized.lib;foo.lib;debug.lib;foo_d.lib;bar.lib; --- for both debug and
> release builds
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Andrew Fuller 
> *Sent:* Thursday, October 4, 2018 5:54 PM
> *To:* Björn Blissing ; Eric Noulard <
> eric.noul...@gmail.com>
> *Cc:* CMake Mailinglist 
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> What happens if you put the genex inside double quotes?
>
>
>
> target_link_libraries(my_exe
>
> PUBLIC
>
>  "$<$:${FOO_LIBRARIES}>"
>
>  "$<$:bar>"
>
> )
>
>
> --
>
> *From:* CMake  on behalf of Björn Blissing <
> bjorn.bliss...@vti.se>
> *Sent:* October 4, 2018 8:49:19 AM
> *To:* Eric Noulard
> *Cc:* CMake Mailinglist
> *Subject:* Re: [CMake] Trouble with conditional generator expression
> inside target_link_libraries
>
>
>
> Hi Eric,
>
>
>
> I tried to do a self contained minimal example:
>
>
>
> cmake_minimum_required(VERSION 3.12)
>
> project(expension_error LANGUAGES CXX)
>
>
>
> add_executable(my_exe main.cpp)
>
>
>
> option(USE_FOOLIB "Use foo.lib" ON)
>
> option(USE_BARLIB "Use bar.lib" ON)
>
>
>
> list(APPEND FOO_LIBRARIES optimized foo)
>
> list(APPEND F

Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

[Eric Noulard]

Le jeu. 4 oct. 2018 à 16:53, Björn Blissing  a
écrit :

> Hello Eric,
>
>
>
> The minimal example was just to display the expansion error. In real life
> the code uses a Boolean variable (and the rest of the CMake code is much
> larger as well).
>
It was just to show the expansion error you get if you try to use a
> conditional generator expression inside a target_link_libraries function.
>

Sometimes the devil is hiding in the details.
Do ou manage to reproduce the genex expansion error on a toy example?


> I do agree that using it would be simpler if I could use:
>
>  $<$:${MYLIBS_DEBUG}>
>
>  $<$:${MYLIBS_OPTIMIZED}>
>
>
>
> But since I use a third party find module the MYLIB_LIBRARIES variable is
> not separated into these categories. I was hoping to avoid rewriting this
> external find module.
>

You can perfectly write a CMake helper function which takes MYLIB_LIBRARIES
as input and spit out MYLIBS_DEBUG, MYLIBS_OPTIMIZED as an output.
This way you don't have to rewrite 3rd party code and keep your code clean.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Trouble with conditional generator expression inside target_link_libraries

[Eric Noulard]

Le jeu. 4 oct. 2018 à 16:06, Björn Blissing  a
écrit :

> Hello,
>
>
>
> I am having trouble with a conditional generator expression inside target
> link libraries, which seems to expand incorrectly (or at least not the way
> I expect).
>
>
>
> In short, I have a list of libraries that is found by a CMake module. The
> list is composed of a number of elements each preceded by “optimized” or
> “debug”, depending on if there are built for release or debug. These
> libraries should only be included if a boolean is set to true. I have tried
> to write a generator expression which only includes the list of libraries
> if this variable is set. But it seems that this expression gets expanded
> wrong.
>
>
>
> If I try to condense the problem to a minimum example, it would be
> something like this:
>
>
>
> LIST(APPEND MYLIB_LIBRARIES optimized foo)
>
> LIST(APPEND MYLIB_LIBRARIES debug foo_d)
>
>
>
> TARGET_LINK_LIBRARIES(target_name
>
> PUBLIC
>
> $<$:${MYLIB_LIBRARIES}>
>
> )
>

I don't quite understand your usage here. The genex $ is always
true?
You must have something like:

$<$:${MYLIB_LIBRARIES}>

with CONDVAR computed before that to HOLD TRUE/1 or FALSE/0
or something similar?

I would try to build a proper MYLIBS_DEBUG and MYLIBS_OPTIMIZED list out of
your MYLIB_LIBRARIES var

and then:

target_link_libraries(target_name
   PUBLIC
 $<$:${MYLIBS_DEBUG}>
 $<$:${MYLIBS_OPTIMIZED}>

which may be easier to read.

Or may be I missed something in your explanation.


>
> This generator expression makes my target depend of the following
> libraries for the release build:
>
> foo.lib & optimized.lib
>
>
>
> And for the debug build:
>
> foo_d.lib, foo.lib & optimized.lib
>
>
>
> Which is obviously incorrect.
>
>
>
> Replacing the generator expression with an IF-statement instead works. But
> I would like to stick to generator expressions if possible to keep my CMake
> code consistent.
>
>
>
> How should I rewrite my generator expression to get the correct expansion?
>
>
>
> Regards,
>
> Björn
>
>
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Detailed graphviz graph?

[Eric Noulard]

Le mer. 3 oct. 2018 à 09:19, Jan Wielemaker  a écrit :

> Hi,
>
> Debugging dependencies is not always easy.  The -graphviz option is a
> nice try, but only seems to do the built-in target types.  Is there
> some way to get the whole dependency graph, including custom targets
> and possibly also the individual files?


Not yet I guess:

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


> Of course this can get huge.
> Possibly there is some way to concentrate on anything relevant to a
> particular target?
>

Besides the custom target issue. I did craft a python script which loads
the dependency graph spitted out by CMake
and do various thing on it:

- search if there exist a path between two targets
- find all path between two targets
- reduce the graph (transitive closure)
etc...

If you use ninja Generator you may try the browse or graph
extra tool:
https://ninja-build.org/manual.html

This is generator specific and it may be difficult to follow your
"original" CMake target in the generated ninja version.


The problem I'm faced with is this:
>
>- I have an ordinary executable target `swipl`
>- To run, this requires a boot file `swipl.prc` that is created
>  by calling `swipl -b ...`
>

Hum... I don't get it.
For running? creating? target "swipl" you need to run it?
There is a chicken & eggs problem or I misread what you said?


>- I'd like to run `swipl` for creating a library index file.
>
> So, these targets need to be built in the order above.  It turns
> out that sometimes step 3 runs before 2 completes.  At least, this
> happens on MacOS using cmake 3.11.2.  So far I haven't seen it on
> Linux (where I use 3.10).  The definition goes like this:
>
> add_custom_command(
>  OUTPUT  swipl.prc
>  COMMAND swipl -O -b ${SWIPL_BOOT_ROOT}/init.pl
>  DEPENDS swipl ${SWIPL_BOOT_FILES}
> )
>
> add_custom_command(
>  OUTPUT  ${PL_LIB_INDEX}
>  COMMAND swipl -f none -g
> "\"make_library_index('${SWIPL_LIBRARY_ROOT}')\"" -t halt
>  DEPENDS swipl.prc ${PL_LIB_FILES_ALL}
> )
>
> add_custom_target(prolog_products ALL
>  DEPENDS swipl.prc ${PL_LIB_INDEX}
> )
>
> The first specifies building swipl.prc, the second the index
> file and the custom target ensures the default build will
> create both files.  I don't see what is wrong and a visual
> dependency graph might reveal this ...
>

Are those three add_custom_xxx in the same directory?
DEPENDS for custom_xxx do not cross directory.

i.e:
``DEPENDS``
  Reference files and outputs of custom commands created with
  ``add_custom_command()`` command calls in the same directory
  (``CMakeLists.txt`` file).  They will be brought up to date when
  the target is built.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Making variables visible in ccmake

[Eric Noulard]

Le ven. 28 sept. 2018 à 13:03, Dorier, Matthieu  a écrit :

> Ah then maybe I don't understand correctly what is supposed to be
> displayed by ccmake.
>

My usage workflow, not sure it is the expected one but other CMake
users/developers may correct me if my usage is wrong.

1) Launch ccmake in an empty buiddir :
ccmake -G Ninja /path/to/source

2) Hit 'c' once to populate the cache

3) hand edit needed var

4) Hit 'c' again and check result

5) Hit 'g'.

Then I may have forgotten to toggle an option so I :

1) Launch ccmake in the populated build dir:
ccmake .

2) hand edit the forgotten vars

3) Hit 'c' then 'g'.



> In general, how can I have in the ccmake screen some variables displayed
> to configure some paths to some libraries?
>

You have to hit 'c' once to populate the cache and make ccmake/cmake-gui
aware of the defined (may be void) variables/

There was a "wizard" mode for cmake some time ago that was asking questions
for setting var values but it's gone:

$ cmake -i
The "cmake -i" wizard mode is no longer supported.
Use the -D option to set cache values on the command line.
Use cmake-gui or ccmake for an interactive dialog.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Making variables visible in ccmake

[Eric Noulard]

Le ven. 28 sept. 2018 à 11:59, Dorier, Matthieu  a écrit :

> Hi,
>
>
> How do I make a variable visible in the ccmake tool?
>
> For example I would like the user to be able to edit BOOST_ROOT when
> calling ccmake, how can I do that?
>
>
> Right now all I see when first running ccmake is "EMPTY_CACHE", and when
> typing "c" to configure (which fails because some variables aren't properly
> set) then "e" to exit, I see the variables I have defined with "option",
> and I can toggle those, but I don't see other variables. I have tried the
> following:
>
>
> if(NOT DEFINED BOOST_ROOT)
>   set(BOOST_ROOT "/usr" CACHE PATH "Root of the Boost installation")
> endif(NOT DEFINED BOOST_ROOT)
>
>
> But I still don't see it in the list of variables.
>

CACHE variables are "Advanced Variables" which are not displayed unless you
toggle display advanced var in either ccmake or cmake-gui.
In ccmake you have to hit 't' in order to see advanced variables.


>
> Additionally, is there a way to have set of variables (namely the options,
> as well as things like BOOST_ROOT, CMAKE_CXX_COMPILER, CMAKE_C_COMPILER)
> show up when first calling ccmake, instead of EMPTY_CACHE?
>

I don't know, CMAKE__COMPILER is not meant to be set with cmake UI,
they ought to be set in a toolchain or outside.
As noted in CMakeForceCompiler module you should not force them, use
toolchain or env var before calling cmake* tool.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake Cookbook is out!!

[Eric Noulard]

Le jeu. 27 sept. 2018 à 23:49, Alan W. Irwin  a
écrit :

> On 2018-09-27 20:26+0200 Eric Noulard wrote:
>
> > Hi CMakers,
> >
> > Hi try not do that too often but here comes a little promotion for a book
> > which (I think) deserve attention.
> > The CMake Cookbook by Radovan Bast, Roberto Di Remigio
> > https://www.packtpub.com/application-development/cmake-cookbook
>
> I don't buy e-books unless they are DRM-free. (See <
> https://en.wikipedia.org/wiki/Digital_rights_management#Opposition> for
> why DRM is such a concern to knowledgable readers of e-books.)
>

Hi Alan,

I'm am well aware of the DRM plague However I shall admit that for this
time I didn't checked before accepting the book review because I was
pleased to help people do what I didn't manage to do myself: write a CMake
book.

I know both authors now and I'm pretty sure they don't want to put any
knowledge in a cage.


> Thus, I was very happy to see the e-book form of the above book is
> DRM-free.
>

Yes precisely and the reason is a clear no go for DRM on the publisher side:
https://hub.packtpub.com/packt-and-day-against-drm/

Don't take my words as bare advertisement but as enthusiasm for freedom.
Next exchange on this off-topic will go off the CMake Mailing List.
-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake Cookbook is out!!

[Eric Noulard]

Hi CMakers,

Hi try not do that too often but here comes a little promotion for a book
which (I think) deserve attention.
The CMake Cookbook by Radovan Bast, Roberto Di Remigio
https://www.packtpub.com/application-development/cmake-cookbook

I'm not the author but I participate in the book review and I think the
authors did a great job and the book contains a lot of good stuff for CMake
users.

There is companion github project:
https://github.com/dev-cafe/cmake-cookbook/
which contains all the recipes of example of code  used in the book.
All the recipes are tested to various CI in order to ensure they work as
expected.

Happy building for everyone.
-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] --config Parameter position relevant?

[Eric Noulard]

Le mer. 19 sept. 2018 à 13:43, Dennis Luehring  a écrit :

> build environment:
>
> Win7 x64
> VStudio 2017 Community Edition 15.8.4 (latest)
> CMake 3.12.1 (x86)
> git 2.19.0 (latest, x64)
> Python 2.7.2 (x86)
>
> directory structure:
>
> D:/projects/fun/jit_tests/clang_from_src/
>llvm <-- git clone https://github.com/llvm-mirror/llvm
>  tools
>clang <-- git clone https://github.com/llvm-mirror/clang
>llvm_build
>
> build instructions:
>
> cd llvm-build
> cmake -Thost=x64 -G "Visual Studio 15 2017 Win64"
> -DLLVM_TARGETS_TO_BUILD=host ..\llvm_project\llvm
>
> cmake --config Release --build .
>
> ends after a few seconds without errors with this message last
>
> Build files have been written to:
> D:/projects/fun/jit_tests/clang_from_src/llvm-build
>
> cmake --build . --config Release
>
> do work and the build is running - is it intended that the position of
> the --config parameter is that relevant?


I guess it is because --config is a sub-option of the --build option whose
expected syntax is:
cmake --build  [options] [-- [native-options]]

In the other case the expected syntax is different:
cmake [options] 

See the different expected syntaxes of the cmake command line here:
https://cmake.org/cmake/help/latest/manual/cmake.1.html

That said the "non working" case should probably at least warn about
ignored/unused options on the command line.
However, I suspect that maintaining backward compatible command line
behavior while providing meaningful
error messages may not be easy.

CMake developers may give more precise answer on that "guess".

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Appending to CMAKE_CXX_FLAGS

[Eric Noulard]

Le mar. 11 sept. 2018 à 22:09, Michael Jackson 
a écrit :

> I add it manually each and every time. I have to tell all new developers
> to remember to add the flag otherwise they are still sitting after an hour
> waiting on our code to compile wondering why it takes so long. Then it hits
> us, "Oh, Yeah. Open CMake-Gui and set the /MP flag". I'm frustrated at the
> situation but not sure how to fix it. I tried the other suggestions and
> just nothing works. This is one of those things that I poke at once a year
> and figure out that nothing has changed. Been this way since VS 2013.
> Someday it will change.
>

I don't know your constraint on using msbuild but if the "main" issue is to
automatically exploit parallel build did you try to switch to ninja instead
of msbuild?

Visual C++ Tools for CMake seems to  [begin to] support that path as well:
https://blogs.msdn.microsoft.com/vcblog/2017/05/10/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Problems with static jpeg library

[Eric Noulard]

Le mar. 11 sept. 2018 à 16:10,  a écrit :

> Hi,
>
> thank you for your reply. I could solve the problem. The part I didn't
> knew was that static libraries also needed to be compiled with -fPIC.
> I've found a good summary of this topic at
> https://lists.debian.org/debian-devel/2016/05/msg00309.html
> I want to share it for those, who also stumble upon this problem.
>


And for project using CMake as build system one can use,
POSITION_INDEPENDENT_CODE
target property:
https://cmake.org/cmake/help/latest/prop_tgt/POSITION_INDEPENDENT_CODE.html#prop_tgt:POSITION_INDEPENDENT_CODE
or globally:
https://cmake.org/cmake/help/latest/variable/CMAKE_POSITION_INDEPENDENT_CODE.html#variable:CMAKE_POSITION_INDEPENDENT_CODE

in order to enable such flags.



>
> On 2018-09-11 13:47, Rolf Eike Beer wrote:
> > wo...@masterdevops.eu wrote:
> >> Hi,
> >>
> >> I am trying to compile the project libgd
> >> (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled.
> >>
> >> I.e. first I downloaded the source code of libjpeg-turbo from
> >> https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled
> >> it
> >
> > You need to make sure that this compile includes -fPIC in the
> > compileflags of
> > libjpeg.
> >
> >> But I get several errors like this one:
> >> > /usr/bin/ld: .../libjpeg-turbo-2.0.0/libjpeg.a(jcmainct.c.o):
> >> > relocation R_X86_64_32S against `.text' can not be used when making a
> >> > shared object; recompile with -fPIC
> >
> > As said here.
> >
> > Eike
> > --
>
> --
> German DevPos site: https://www.masterdevops.eu
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] overriding -03 -DNDEBUG Release flags

[Eric Noulard]

Le lun. 10 sept. 2018 à 14:34, Stéphane Ancelot 
a écrit :

> Hi,
>
> In one project I need to compile with -O2 option , how to set it and
> remove -O3 -DNDEBUG flags for this project ?
>

May be you can create a new Build Type with appropriate flags:
https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-extend-the-build-modes-with-a-custom-made-one-

and set it as the default build type for this particular project?
https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-change-the-default-build-mode-and-see-it-reflected-in-the-gui
https://blog.kitware.com/cmake-and-the-default-build-type/


> --
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] unknown cmake command

[Eric Noulard]

Le dim. 9 sept. 2018 à 06:52, Robert Finch  a écrit :

> Hi, cmake is new to me. I’m attempting to use cmake to build a backend for
> LLVM. CMake fails with an ‘unknown cmake command’ error. It doesn’t seem to
> be able to find or execute modules or macros. I tried setting the
> CMAKE_MODULE_PATH, LLVM_CMAKE_DIR, LLVM_DIR, and LLVM_TABLEGEN variables. I
> wonder if this would be a problem spawning executables ? Security ? Nothing
> is written to the log file. tablegen is in the path and can be run
> manually, but cmake fails to run it. Cmake successfully built and installed
> LLVM.  The file cmake fails with is Cmakelists.txt. The OS is Windows 10
> pro build 1803.
>

If the project is public is would be easier to help you if you point out
the repo of the project.
You should at least provide the full CMake error message your are getting
along with CMake version and CMake generator you use (VIsual Studio,
etc...)

I do build LLVM/clang and some tooling which are not bundled with it like
IWYU (https://include-what-you-use.org/) it appears that LLVM has specific
CMake macros that ought to be used in the right way. e.g. for IWYU
something different is done if it's built in-source (along with LLVM+clang
source tree) or out-of-source.You may have a look at:
https://github.com/include-what-you-use/include-what-you-use/blob/master/CMakeLists.txt
to see what they do for that.

However from (https://llvm.org/docs/WritingAnLLVMBackend.html#preliminaries)
I bet that building a backend is very different from building a clang-based
extra tool.
Did you get in touch on some LLVM mailing list about that?

I bet your issue may be more related on "how to use LLVM cmake build
system" than  a generic CMake issue.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Specify extra files for display in IDE

[Eric Noulard]

Le mer. 5 sept. 2018 à 11:00, Daniel Eiband  a
écrit :

> Hi,
>
>
>
> I managed to solve the presentation of object libraries by renaming the
> targets and hiding certain targets in folders. I think this solution is
> acceptable.
>
>
>
> The issue with the display of header only libraries in IDEs, which are
> implemented as interface libraries, is still unsolved. The add_library()
> command doesn’t accept any sources.
>

For an interface library you can add sources with

target_sources(yourlib INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/whatever.h)

You need the INTERFACE keyword though:
https://cmake.org/cmake/help/latest/command/add_library.html#interface-libraries

is this not working for you?

Could you provide a strip-down archive which exhibit this issue I may try
it on my side?


> Also setting the SOURCES property of an interface library target is
> rejected by CMake.
>

This is because you can only populate INTERFACE_SOURCES on an INTERFACE
target:
https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_SOURCES.html
https://cmake.org/cmake/help/latest/command/target_sources.html#command:target_sources



> I haven’t found any other way of adding the files to the interface library
> so that they are presented in the IDE.
>

Like I said in a previous email on my side, interface library (INTERFACE)
sources are displayed in vscode and qtcreator, may be the fact that they
are not displayed by Visual Studio
is a Visual Studio bug?

By the way there is an old issue on this subject:
https://gitlab.kitware.com/cmake/cmake/issues/15234



> I know the workaround of adding an empty custom target. This is however
> not really satisfying, because Visual Studio for example displays them with
> a completely different icon and the suffix “(utility target)”. Doesn’t look
> like a C++ library any longer. It also sort of highlights the library
> because of the non-C++ icon and I have to hide even more targets (the real
> interface libraries).
>
>
>
> From a CMake interface perspective this is also an asymmetry: Why can I
> add arbitrary files to executable and static/shared library targets being
> displayed in IDEs without contributing to the build artifact while this is
> not possible for interface libraries? I think, the restriction on interface
> libraries should not be that they don’t have any source files. Interface
> libraries must not have source files which produce build artifacts.
>

Agreed and I think it would more "natural" to be able to simply
target_sources / add_library "as usual" and promote SOURCES to
INTERFACE_SOURCES automatically since the target is an INTERFACE lib.


>
> Is this worth an enhancement bug or has this already been discussed?
>

The only one I am aware of is this one:
https://gitlab.kitware.com/cmake/cmake/issues/15234

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] creating a library from other one

[Eric Noulard]

Le ven. 31 août 2018 à 15:59, Stéphane Ancelot  a
écrit :

> I ended with :
>
> add_custom_target(combined ALL
>COMMAND ${CMAKE_AR} rc libcombined.a $ $ FILE:lib2>)
>

Quick & dirty :-)
There is the "thin" option of ar as well:
https://stackoverflow.com/questions/3821916/how-to-merge-two-ar-static-libraries-into-one
if you know the content of lib1 and lib2 don't have name clash.

However libcombined.a is not a proper library target for CMake now.

And by the way does this work on Window too ? Or may be you don't care ?



-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] creating a library from other one

[Eric Noulard]

First create OBJECT libraries instead of static
Then create as many STATIC libraries as you want that includes as many
OBJECT libraries content as you want.


Le ven. 31 août 2018 à 15:17, Stéphane Ancelot  a
écrit :

> Hi,
>
> I have got some static libraries generated, that  I would like to put in
> a common one.
>
> how can I proceed ?
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] find_package with COMPONENTS never honors REQUIRED

[Eric Noulard]

Le jeu. 30 août 2018 à 20:03, George PF  a écrit :

> > The documentation is intriguing about REQUIRED COMPONENTS interaction
>
> That's... one way to put it.
>

Yeah you know. Kind of ironic here :-)


> > So it is possible that the failure behavior when specifying COMPONENTS
> is up to the module...
>
> I admit I was not reading the docs in that depth, but REQUIRED can only
> mean one thing and should
> not need second guessing the documentation. Sadly, someone thought
> otherwise.
>

I guess there is no one to blame here.
The doc is too-realistic about the state of find modules.
At least Config mode should do it right I hope.
Module mode is historically for hand-written module maintained by
volunteers:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/dev/Module-Maintainers

> Do you see this only with Qt or do other packages with components (may be
> Boost) behave like this?
> > I guess that Qt5 should be running in config mode, whereas boost must be
> in module mode though.
>
> I was debugging an older cmake project and wondered why it was not finding
> the non-standard Qt location,
> that's when I stumbled upon this issue.
>

I see. I think something could/should be done for Config mode, for Module
mode It would certainly depends on the module maintainer.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] find_package with COMPONENTS never honors REQUIRED

[Eric Noulard]

Le jeu. 30 août 2018 à 18:01, George PF  a écrit :

> Hi,
>
> once COMPONENTS is added to a find_package statement, any REQUIRED
> statement ceases to have an effect:
>
> cmake_minimum_required(VERSION 3.12)
>
> # find_package(FailsCorrectly REQUIRED)
>
> find_package(Qt REQUIRED COMPONENTS REQUIRED Qt5XYZ REQUIRED)
> find_package(Qt REQUIRED COMPONENTS  Qt5XYZ )
> find_package(Qt  COMPONENTS REQUIRED Qt5XYZ )
> find_package(Qt  COMPONENTS  Qt5XYZ REQUIRED)
> find_package(Qt  COMPONENTS REQUIRED Qt5XYZ REQUIRED)
> find_package(Qt REQUIRED COMPONENTS  Qt5XYZ REQUIRED)
> find_package(Qt REQUIRED COMPONENTS REQUIRED Qt5XYZ )
>
>
> This CMakeLists.txt runs, despite Qt5XYZ not existing. How can this be
> made to fail as it should, why
> else would there be OPTIONAL_COMPONENTS as well?
>

The documentation is intriguing about REQUIRED COMPONENTS interaction

"A package-specific list of required components may be listed after the
``COMPONENTS`` option (or after the ``REQUIRED`` option if present).
Additional optional components may be listed after
``OPTIONAL_COMPONENTS``."

and

"Available components and their influence on
whether a package is considered to be found are defined by the target
package."

and later on:

"In Config mode ``find_package`` handles ``REQUIRED``, ``QUIET``, and
``[version]`` options automatically but leaves it to the package
configuration file to handle components in a way that makes sense
for the package.  The package configuration file may set
``_FOUND`` to false to tell ``find_package`` that component
requirements are not satisfied."

So it is possible that the failure behavior when specifying COMPONENTS is
up to the module...

Do you see this only with Qt or do other packages with components (may be
Boost) behave like this?
I guess that Qt5 should be running in config mode, whereas boost must be in
module mode though.

By the way for Qt5 the doc says you shouldn't be using find_package(Qt):
https://cmake.org/cmake/help/latest/module/FindQt.html

But probably directly:
find_package(Qt5)

see example here: https://blog.kitware.com/cmake-finding-qt5-the-right-way/
-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Specify extra files for display in IDE

[Eric Noulard]

Le jeu. 30 août 2018 à 12:32, Daniel Eiband  a
écrit :

> Hi,
>
>
>
> I’m currently migrating a code base from a proprietary MSBuild based
> generator to CMake 3.11 which is shipped with Visual Studio. There are two
> aspects to this task:
>
>
>
> 1) Integration of custom build steps
>
> 2) Presentation in the IDE
>
>
>
> The first aspect of integrating all of our custom build steps as custom
> commands works really well. At one point I use an object library to be able
> to use the object files as input to such a custom tool and to link a shared
> library. Both the object library and the shared library are from the
> programmers perspective one logical unit. The object library is just an
> implementation detail. However, as for the second point, the source files
> are displayed with the object library target in the IDE while the shared
> library has no sources. This makes sense from the build targets point of
> view, but surprises the developers.
>
> My approach is to hide all targets which are sort of implementation detail
> into a folder.  To make this work I would like to display the sources with
> the shared library which consumes the object files of the object library.
> Currently this seems to be impossible.
>
>
>
> Another inconsistency I noticed regarding the second point is the
> following: I implemented header only libraries as interface libraries in
> CMake. This works fine from the build perspective. Interface libraries
> however don’t allow me to list sources, not even headers. As a result, the
> headers of this header only library are not displayed anywhere in the IDE.
> This is odd, because in executable targets for example I can list all
> headers even if they don’t contribute to the build process directly and
> they are displayed in the IDE. Using empty custom targets to present the
> header files works, but they are not displayed as C++ libraries in Visual
> Studio any longer. This also litters the solution with lots of extra empty
> targets.
>
>
>
> I’m going to rephrase both described presentation problems into one more
> fundamental question, solutions or workarounds for either of both
> presentation problems are of course welcome: Can I specify sources used for
> builds and files used for display in IDEs separately? I think they are two
> different things. For my use case it would also be sufficient to be able to
> add extra files for display in IDEs to any target.
>

I'm afraid that your question may be generator-specific and I'm no sure
Visual Studio generator behaves in the same way as others I'm using.
I do very often add non source file (like README.md) to any targets
(add_executable, add_library, add_custom_target) in order to make them
editable in the IDE.
Since those file are guessed as not being compilable they inherit the
HEADER_FILE_ONLY  (
https://cmake.org/cmake/help/v3.11/prop_sf/HEADER_FILE_ONLY.html)
automatically
and they show up in IDE just fine.

My particular IDE being either qtcreator, vscode+cmaketools or eclipse and
this works well for those.

Moreover, in qtcreator (for example) header only libraries appear on their
own with editable header file AND as subdir of every other targets their
are used by. This subdir contains the headers.
This is not the case with object libraries though :-(

Concerning the visual grouping you must already being using source_group (
https://cmake.org/cmake/help/latest/command/source_group.html) source_group
does not seems
to have any effect in my favorite IDEs...

In the end I don't know if there is currently any ways to do what you want.

At least the "never displayed" header only library looks like a bug of the
Visual Studio generator to me.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Iterating over a generator expression list, specifically $ of an OBJECT library

[Eric Noulard]

Le mer. 29 août 2018 à 14:44, George PF  a écrit :

>
> >
> > My opinion (but I may be proven wrong by others) is that genex contains
> > generator specific bits that cannot be **evaluated**
> > until the build system is generated.  Properties (on target, or
> directory,
> > or files) contains informations that is available as soon
> > as the corresponding CMakeLists.txt part defining the object has been
> > processed.
>
> That seems more like an internal cmake limitation. Though maybe on purpose
> so
> the scripts can not be tailored for just one backend.
>

I think this was a design choice thus the name "Generator" expression they
are evaluated at generation time
not configuration time and I don't think it's an internal cmake limitation,
I think (but I may be wrong) that this
"generation step" would happen for any generative build system.

And there is more than that about "when" you'll know some var values.
Some generators are supporting "multiple build configuration" like MSVC and
Xcode so that
the build output dir is "mangled" with a prefix **at build time** (since
you can switch configuration after you have generated your project files).
see e.g.
https://cmake.org/cmake/help/latest/variable/CMAKE_CFG_INTDIR.html

And the documentation says quite optimistically: "Generator expressions are
> allowed
> in the context of many target properties", a more restrictive phrasing -
> "only works
> with X / Y for reasons Z" would help there.


I agree this could be clearer.
Having a possibly exhaustive description of where genex may be used would
be nice.
May be it's worth a bug report with a proposal doc update?

Genex support is added in places where it is useful (and possible I guess):
https://gitlab.kitware.com/cmake/cmake/issues/15374
https://gitlab.kitware.com/cmake/cmake/issues/15785

And concerning having them "at configure time", there is open issue
about "configuration expression":
https://gitlab.kitware.com/cmake/cmake/issues/17962


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] how do you allow CMAKE_CUDA_COMPILER to be optional via project LANGUAGE?

[Eric Noulard]

Le mar. 28 août 2018 à 19:07, Quang Ha  a écrit :

> Hi all,
>
> So this question is again about project(foo LANGUAGES CXX CUDA). Is it
> possible to switch off CUDA if Cmake couldn't find CUDA compiler? I.e.
> something along the line:
>

May be you can only:

  project(foo LANGUAGES CXX)

then

include(CheckLanguage)
check_language(CUDA)
if(CMAKE_CUDA_COMPILER)
  enable_language(CUDA)
else()
  message(STATUS "No CUDA compiler found")
endif()

see doc:
https://cmake.org/cmake/help/latest/module/CheckLanguage.html


Eric


> if (CUDA_FOUND)
>   set_language_to_CUDA_and_CXX
> else(CUDA_FOUND)
>   set_language_to_CXX_only
> endif(CUDA_FOUND)
>
> The main reason is I don't want CMake to fail when CUDA compiler isn't
> available. Rather, it should continue to compile the source files using CPP
> compilers instead.
>
> Thanks,
> Quang
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Iterating over a generator expression list, specifically $ of an OBJECT library

[Eric Noulard]

I cc the list because I think you drop it inadvertently.

Le mar. 28 août 2018 à 16:18, George PF  a écrit :

> > Because generator expressions are not handled in every cmake construct:
> >
> https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html
> >
> > genex is probably not handled in foreach.
>
> That is a harsh limitation, set() or list() also does not expand this
> expression.
>

genex are evaluated during "Generation time" i.e. when CMake
produces/generates the specific build system
files (makefile, [build|rules].ninja, MSVC solution etc...). This is
convenient because some (most of) genex informations
may be generator specific (library file name, build artefact location,
etc...)

https://stackoverflow.com/questions/46206495/cmake-generator-expressions

set() , list(), foreach() are "running" at "CMake time" i.e. when cmake
runs and processes CMakeLists.txt and other cmake scripts
that is before "Generation time".


And the variable XYZ, when set via this indirection to TARGET_OBJECTS,
>
> add_library(lib12 SHARED $)
> get_property(XYZ TARGET lib12 PROPERTY SOURCES)
>
> is also not expanded yet. Is there a workaround regarding the generator
> expressions, or
> another way to get the TARGET_OBJECTS of an object library (and why is
> this hidden
> behind a generator and not available as a property)?
>

My opinion (but I may be proven wrong by others) is that genex contains
generator specific bits that cannot be **evaluated**
until the build system is generated.  Properties (on target, or directory,
or files) contains informations that is available as soon
as the corresponding CMakeLists.txt part defining the object has been
processed.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Iterating over a generator expression list, specifically $ of an OBJECT library

[Eric Noulard]

Le mar. 28 août 2018 à 15:39, George PF  a écrit :

> Hello,
>
> how can e.g. $ be iterated over in cmake?
>
> This builds the lib, but the loop is never run:
>
> add_library(objlib12 OBJECT lib1.c lib2.c)
> foreach(o IN LISTS $)
> message("obj ${o}")
> endforeach()
>
> But the $ variable is set correctly, as this
> builds a shared library:
>
> add_library(lib12 SHARED $)
>
> And the ;-separated list is visible when running this custom command via
> the 'test12' target:
>
> add_custom_command(OUTPUT libtest.cc
> COMMAND bash -c "echo '$'; echo >
> libtest.cc"
> VERBATIM)
> add_library(test12 SHARED libtest.cc)
>
>
> Why does the for loop completely ignore this variable?
>

Because generator expressions are not handled in every cmake construct:

https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html

genex is probably not handled in foreach.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding an individual define to each source file of a library

[Eric Noulard]

Le jeu. 23 août 2018 à 19:18, George PF  a écrit :

> > > However, whatever I write into 'set_property()' - no APPEND, single
> entry,
> > > not quoted - does not end up
> > > on the compiler command line. Is there a type mismatch which is
> silently
> > > ignored?
> > >
> >
> > Or you are doing this in a directory which is not the one where the
> target
> > is defined and from the doc:
> > $ cmake --help-command set_property
> >
> > ...
> > ``SOURCE``
> >   Scope may name zero or more source files.  Note that source
> >   file properties are visible only to targets added in the same
> >   directory (CMakeLists.txt).
> >
> > ...
>
> This is all in the same directory, full setup and test:
>
> % cmake --version
> cmake version 3.12.0   [..]
> % mkdir mylib && cd mylib
> mylib% touch file1.c file2.c
> mylib% cat > CMakeLists.txt
>
> cmake_minimum_required(VERSION 3.12)
>
> add_library(mylib SHARED file1.c file2.c)
>
> get_property(mysrcs TARGET mylib PROPERTY SOURCES)
> foreach(x IN LISTS mysrcs)
> message("at ${x}")
> set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS
> "TEST1;TEST2;")
>

almost there but you forgot to take value of 'x'

set_property(SOURCE ${x} APPEND PROPERTY COMPILE_DEFINITIONS "TEST1;TEST2;")

works for me.





> endforeach(x)
> # ^D
>
> mylib% mkdir build && cd build && cmake ..
> [..]
> at file1.c
> at file2.c
> -- Configuring done
> [..]
> mylibs/build% grep -r TEST1 . || echo no TEST1
> no TEST1
>
> and 'make VERBOSE=1' also shows no extra -DTEST1 compiler arguments.
> --
>
> 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
>


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding an individual define to each source file of a library

[Eric Noulard]

Le jeu. 23 août 2018 à 18:31, George PF  a écrit :

> Thank you for the precise pointers, I added to the same CMakeLists.txt:
>
> get_property(mysrcs TARGET mylib PROPERTY SOURCES)
>
> foreach(x IN LISTS mysrcs)
> message("at ${x}")
> set_property(SOURCE x APPEND PROPERTY COMPILE_DEFINITIONS
> "TEST1;TEST2;")
> #set_source_files_properties(x PROPERTIES COMPILE_DEFINITIONS
> "TEST1;TEST2;") # also not working
> endforeach(x)
>
> However, whatever I write into 'set_property()' - no APPEND, single entry,
> not quoted - does not end up
> on the compiler command line. Is there a type mismatch which is silently
> ignored?
>

Or you are doing this in a directory which is not the one where the target
is defined and from the doc:
$ cmake --help-command set_property

...
``SOURCE``
  Scope may name zero or more source files.  Note that source
  file properties are visible only to targets added in the same
  directory (CMakeLists.txt).

...


> As to __FILE__ or similar, the define is used as a variable, i.e. the .c
> suffix would have to be removed
> via the c processor. The current directory is also used. I think replacing
> .c and appending the name of
> the current directory will be easier in cmake.
>
>
> > Le jeu. 23 août 2018 à 13:02, George PF  a
> écrit :
> >
> > > Hello,
> > >
> > > following "modern cmake" conventions I want to create a library where
> > > every single file is compiled with an individual define (-D_fileX_,
> > > required for a macro which integrates code into every translation
> unit).
> > >
> > > So following this
> > >
> > > add_library(mylib SHARED file1.c file2.c)
> > > target_link_libraries(mylib PUBLIC otherlib)
> > >
> > > I'd like to iterate over all "mylib" source file targets and modify
> them
> > > so that the compiler is called like this:
> > >
> > > cc -c -o file1.o file1.cc -D_file1_define_
> > > cc -c -o file1.o file2.cc -D_file2_define_
> > > etc.
> > >
> > > Is this possible?
> > >
> >
> > You can retrieve the sources associated with a target using SOURCES
> > properties.
> > https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html
> >
> > then
> > https://cmake.org/cmake/help/latest/command/foreach.html
> > with
> > https://cmake.org/cmake/help/latest/command/set_property.html
> > or
> >
> https://cmake.org/cmake/help/latest/command/set_source_files_properties.html
> >
> > for setting property:
> > https://cmake.org/cmake/help/latest/prop_sf/COMPILE_DEFINITIONS.html
> >
> > on each source file.
> >
> > not sure why you want to do that you know that compiler already defined
> > many "standard" macro for you, like __FILE__
> >
> https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html#Standard-Predefined-Macros
> > ?
> >
> > --
> > Eric
> --
>
> 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
>


-- 
Eric
-- 

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