[Cmake-commits] CMake branch, master, updated. v3.15.4-1332-gab54653

[Kitware Robot via Cmake-commits]

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

The branch, master has been updated
   via  ab54653afd8f6671c462742dee089a2e12b2d7dc (commit)
  from  4c29297495b53e07f61a6de1f5f689ddd6bab7bd (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab54653afd8f6671c462742dee089a2e12b2d7dc
commit ab54653afd8f6671c462742dee089a2e12b2d7dc
Author: Kitware Robot 
AuthorDate: Tue Oct 8 00:01:06 2019 -0400
Commit: Kitware Robot 
CommitDate: Tue Oct 8 00:01:06 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index c068594..2580bd2 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191007)
+set(CMake_VERSION_PATCH 20191008)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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

[CMake] How to use custom linker, e.g. lld on windows

[Ryan Edward McClue via CMake]

To avoid repetition, please view: 
https://stackoverflow.com/questions/58253100/how-to-use-lld-with-cmake-on-windows

Sent with [ProtonMail](https://protonmail.com) Secure Email.-- 

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] FindThreads module documentation needs some work

[Alan W. Irwin]

In my opinion [the latest documentation of the FindThreads
module](https://cmake.org/cmake/help/latest/module/FindThreads.html)
needs some work.  Specifically please deal with the following documentation 
issues.

* Threads_FOUND needs documentation.  And that needs to be done at the
  top of the documentation as typically happens with other modules
  where a _FOUND variable is being set on a successful
  find.

* CMAKE_HAVE_THREADS_LIBRARY needs documentation.  I suspect the value
  of this variable (set in the module but otherwise not used there) has
  been historically useful for those module users who have figured out
  its purpose, but it would be good to have that purpose documented.

* The CMAKE_THREAD_LIBS_INIT variable and corresponding
  Threads::Threads INTERFACE_LINK_LIBRARIES target property is the
  empty string for the case when the (Posix) threads functions are
  provided by the C library.  According to a second-hand report I
  received this case happens on Mac OS X (at least for MacPorts).
  Therefore, please document this expected result for that important
  use case.

* Finally, for that same important use case
  THREADS_PREFER_PTHREAD_FLAG is completely ignored, and that should
  be documented as well.

Because of these documentation issues, learning to use this module
properly on both Linux and Mac OS X for PLplot and another project I
have been working on has been much more work than I expected (i.e.,
instead of relying on documentation I had to analyze the CMake code in
this module to figure out what was going on).

I would be willing to repeat all the above in a bug report, but
instead of doing that I hope someone here is willing to step forward
with fixups for the above simple documentation issues in a timely
manner so there is no bug triage burden for these fixups.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

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

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

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

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

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

[CMake] LastTest log file name?

[Donald MacQueen [|] via CMake]

Ctest creates a log file in ../build/Testing/Temporary with a name like 
LastTest_MMDD_HHMM.


Is there a way I an add some descriptions to this name?

For example, LastTest_MMDD_HHMM_MyTestDescription.

Thanks in advance.

--
Donald [|]
A bad day in [] is better than a good day in {}.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--

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] HOWTO declare component inter-dependencies in multi-component packages

[stefan]

Hi,

can you reproduce my observations ? I'm I doing something wrong or is 
there indeed an issue with CMake ? Should I follow up with a bug report ?


Thanks,

On 2019-10-04 2:20 p.m., stefan wrote:



On 2019-10-03 5:24 p.m., Kyle Edwards wrote:

On Thu, 2019-10-03 at 17:08 -0400, stefan wrote:

Yes, that is exactly what I'm trying to do, but it doesn't seem to
have any effect. That is, `dpkg --info ...` doesn't list the
additional dependency, and correspondingly, running `apt-get install
...` on the component package file will install the package without
first installing the prerequisite component.
Consider this declaration:
   set(CPACK_COMPONENTS_ALL runtime development mstool)
If I now write
   set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime)
I will see no effect. That is, the "development" package still does
not depend on the "runtime" package.
So I try this:
   set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME)
in case capitalization is required. Now the "runtime" component seems
to get packaged twice (as per the cmake logs), but still no correct
dependencies.
Is it time for a bug report ?

Please send us a minimal CMakeLists.txt that reproduces the issue.


Sure. Here it is. The relevant line part is line 5. Please let me know 
what I'm doing wrong.


Thanks,

Stefan
--

   ...ich hab' noch einen Koffer in Berlin...
 


Stefan

--

  ...ich hab' noch einen Koffer in Berlin...


-- 

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] ?==?utf-8?q? Looking for an explanation: What exactly means "install" in cmake language?

[Cornelis Bockemühl]

> I think that the word install is used consistently between GNU autotools and 
> CMake:

Right, looks like it comes from the "good old times" when on Linux computers 
software was "installed" by downloading, then doing a "make" and a "make 
install" in order to get it running, while nowadays "installation" is normally 
done by a package manager that tries to resolve dependencies and works with 
binaries only. And CMake does some tricky things to do an "install" in order to 
later on "export" and "import" the code, or prepare it for "pack" etc.

> It's that "prepare it for..." clause that makes it different from a straight 
> up copy.

In my case it looks like it "somehow works" for now without other preparations 
- but I hate this "solution" because it is against all "good cmake use" that 
would rather deal with targets and properties only, not with variables and 
directly copying files around, fiddling with shared library extensions (like so 
or dll) - but if working "the right way" takes so much time to figure out, it's 
finally a question of time economy that you finally end up with doing it "the 
hard way".

(...which is of course the opposite of what a build tool should do for you: It 
should not make project setup more complicated, but more simple! But well - 
that's the real world ;-) )
-- 

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?

[Fred Baksik]

On Mon, Oct 7, 2019, at 11:25 AM, Eric Noulard wrote:
> 
> 
> 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.
> 

File permissions are also set according to what was specified in install() via 
`PERMISSIONS which can be different from the file permissions of the file in 
the build directory.`
`I think I saw that there was even a "make install/strip" feature that also 
stripped targets during installation.`

`I think that the word install is used consistently between GNU autotools and 
CMake:`
*2. * (Computer Science) to transfer (computer software) from a distribution 
file to a permanent location on disk, and prepare it for its particular 
environment and application.

It's that "prepare it for..." clause that makes it different from a straight up 
copy.

I don't know what may be causing your issues. I do know that at least one 
person felt that CMake installation is too aggressive in that it is always 
installing files that it doesn't need to during the installation step.

https://stackoverflow.com/questions/58069372/does-cmake-always-evaluate-install-rules-even-for-up-to-date-targets#comment102540437_58069372

--
Fred-- 

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] ?==?utf-8?q? Looking for an explanation: What exactly means "install" in cmake language?

[Cornelis Bockemühl]

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

Well yes, I understood that there are "some" other things happening - and I
did not think about RPATH or RUNPATH - because so far I never cared for them...
At this moment I finally have a setup running where shared libraries are
simply copied over with configure_file - without care for RPATH etc. -,
and it's working finally!

But definitely now like the inventors of cmake have thought it should, with
a lot reinventing wheels etc...

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

Yes, it's out of tree. And also I did this removal and rebuild!

This is exactly how I realized my problem: I had done once an "install build"
that copied library files to the target - and everything looked find from then
on. Until I did that exercise - and realized that nothing is copied any more!

And because I could not find any plausible reason why this library copying did
not happen any more, I gave this "install" business up for the moment...

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

The problem is that I did not even change anything in that part of the project
from the moment when it "accidentally" happened once...

But sure, it is never pure magic: I MUST have done something "wrong"!

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

That's exactly my problem: I am working on a ParaView custom project, and
then trying to "derive" another one from the first! So there is nothing
to be easily "stripped down" - it is simply a monster project - and I am
almost sure if I am going to write a simple dummy project, everything will
just work fine...

And this is why I was asking for a more thorough documentation that what
you can find at Kitware where not the processes are explained, but just
"what to do".

So from what I see, if you start a cmake project from scratch, you can start
with simple concepts and add towards more complex ones, with growing
understanding. However, if you start to build on ParaView, you start in
the middle of an already highly complex project setup, with little documentation
than just examples - and the entire process feels a bit like learning
C++ with only the source code of a C++ compiler at hand: certainly possible,
but takes a horrible amount of time... ;-)

Side remark: Regarding cmake, this is also the reason why some days ago
I was asking for certain improved functionalities for debug support, like
a way to simply dump a list of "current targets" (including imported!),
plus a way to dump also all valid "properties" of targets!

Bottom line: Since such a documentation like I would like to find may not
even exist, I think I should be happy that I have a 

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] ?==?utf-8?q? Looking for an explanation: What exactly means "install" in cmake language?

[J Decker]

A note - INSTALL( FILES ) is only good for data files, if you have scripts
that have executable permissions using INSTALL( PROGRAMS ) will get execute
flag set too.

On Mon, Oct 7, 2019 at 7:49 AM Cornelis Bockemühl 
wrote:

> 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?
>
> 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?
>
> Targets use  ,... depending on add_executable, or add_library was used(
and/or if STATIC/SHARED is specified in add library )


> 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)
>
I usally put it immediately after the thing that added the target...

>
> 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.
>
right, it's an 'install' target.. make install ; ninja install, ... etc ya

>
> 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...
>
When I have issues like that, `cmake --trace ...`  option gives a good idea
of what cmake thinks it's doing...  or maybe ninja V=1 install ?
It is copy-if-different, so if the build re-builds and generates the same
output library it won't re-install...

You can set set( CMAKE_INSTALL_MESSAGE "LAZY" )  which only emits messages
for things it actually installs (just a side note)

But I don't know why it's not going where you think it is ( somewhere in
CMAKE_BINARY_DIR IIRC?  or did you use CMAKE_CURRENT_BINARY_DIR which can
be deeply in install)  I do often set my install to 'output' which by
default is put into the build directory...


> 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! --
>
> 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] Adding CRC32 to ELF

[Vincent van Beveren]

Hi Eric,

Thanks for your prompt reply.

I have been able to follow your steps up until the item, so thanks!

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


I ran into two challenges:
- The argument '$.crc32' should be the 
actual content of the file, and not the file itself, i.e. the calculated 
CRC value.  How to do this?
- As far as I can see, non of the previously defined linker flags are 
added to this command. Of course I can do this, but it would mean I need 
to define things twice.


Cheers,
Vincent

On 7-10-2019 at 15:55 wrote Eric Noulard:



Le lun. 7 oct. 2019 à 14:41, Vincent van Beveren 
mailto:v.van.beve...@nikhef.nl>> 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


--
National Institute 

[Cmake-commits] CMake branch, master, updated. v3.15.4-1331-g4c29297

[Kitware Robot via Cmake-commits]

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

The branch, master has been updated
   via  4c29297495b53e07f61a6de1f5f689ddd6bab7bd (commit)
   via  e7ef66abd02dbd9b05358ffb09c11263f5c0fcc7 (commit)
   via  16613bc05074e6c895f6b86567f5c92111346d62 (commit)
   via  0b2431896fe5d6178c0a3442c20d3f032a6a1536 (commit)
  from  ead89868ba09bb331ae31c116f1cec4a44713b3b (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c29297495b53e07f61a6de1f5f689ddd6bab7bd
commit 4c29297495b53e07f61a6de1f5f689ddd6bab7bd
Author: Brad King 
AuthorDate: Mon Oct 7 10:57:39 2019 -0400
Commit: Brad King 
CommitDate: Mon Oct 7 10:57:39 2019 -0400

Begin post-3.16 development

diff --git a/Help/release/dev/0-sample-topic.rst 
b/Help/release/dev/0-sample-topic.rst
new file mode 100644
index 000..e4cc01e
--- /dev/null
+++ b/Help/release/dev/0-sample-topic.rst
@@ -0,0 +1,7 @@
+0-sample-topic
+--
+
+* This is a sample release note for the change in a topic.
+  Developers should add similar notes for each topic branch
+  making a noteworthy change.  Each document should be named
+  and titled to match the topic name to avoid merge conflicts.
diff --git a/Help/release/index.rst b/Help/release/index.rst
index 0cc3f97..a4585a5 100644
--- a/Help/release/index.rst
+++ b/Help/release/index.rst
@@ -7,6 +7,8 @@ CMake Release Notes
   This file should include the adjacent "dev.txt" file
   in development versions but not in release versions.
 
+.. include:: dev.txt
+
 Releases
 
 
diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 51a9217..c068594 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,8 +1,8 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 0)
-set(CMake_VERSION_RC 0)
+set(CMake_VERSION_PATCH 20191007)
+#set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 
 # Start with the full version number used in tags.  It has no dev info.

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7ef66abd02dbd9b05358ffb09c11263f5c0fcc7
commit e7ef66abd02dbd9b05358ffb09c11263f5c0fcc7
Merge: ead8986 16613bc
Author: Brad King 
AuthorDate: Mon Oct 7 10:56:41 2019 -0400
Commit: Brad King 
CommitDate: Mon Oct 7 10:56:41 2019 -0400

Merge branch 'release-3.16'


---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, master, updated. v3.15.4-1327-gead8986

[Kitware Robot via Cmake-commits]

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

The branch, master has been updated
   via  ead89868ba09bb331ae31c116f1cec4a44713b3b (commit)
   via  ffa1c76ba364f4400973e184b30b9ca387e0b484 (commit)
   via  a933d8d84e527b04920773d296b09bdcc0872ecf (commit)
   via  9c9a6e6023013ababfcc59ca9931c78c0512df1c (commit)
  from  b734a04164dcd4eb37246b4b0d52e22996d8ef43 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ead89868ba09bb331ae31c116f1cec4a44713b3b
commit ead89868ba09bb331ae31c116f1cec4a44713b3b
Merge: b734a04 ffa1c76
Author: Brad King 
AuthorDate: Mon Oct 7 14:49:27 2019 +
Commit: Kitware Robot 
CommitDate: Mon Oct 7 10:49:35 2019 -0400

Merge topic 'doc-3.16-relnotes'

ffa1c76ba3 Help: Add missing 3.16 release notes for CPack/DEB descriptions
a933d8d84e Help: Organize and revise 3.16 release notes
9c9a6e6023 Help: Consolidate 3.16 release notes

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ffa1c76ba364f4400973e184b30b9ca387e0b484
commit ffa1c76ba364f4400973e184b30b9ca387e0b484
Author: Brad King 
AuthorDate: Mon Oct 7 10:21:40 2019 -0400
Commit: Brad King 
CommitDate: Mon Oct 7 10:45:23 2019 -0400

Help: Add missing 3.16 release notes for CPack/DEB descriptions

Add notes for the changes from commit 33c7ea513d (CPackDeb: Use
`CPACK_PACKAGE_DESCRIPTION_FILE`, 2019-07-11).

Suggested-by: Alex Turbov 

diff --git a/Help/release/3.16.rst b/Help/release/3.16.rst
index 8d8490e..2b1ecf5 100644
--- a/Help/release/3.16.rst
+++ b/Help/release/3.16.rst
@@ -201,9 +201,17 @@ CPack
   control what configurations are to be packaged for multi-configuration
   CMake generators.
 
+* The :cpack_gen:`CPack DEB Generator` is now able to format generic text
+  (usually used as the description for multiple CPack generators) according
+  to the `Debian Policy Manual`_.  See the
+  :variable:`CPACK_PACKAGE_DESCRIPTION_FILE` and
+  :variable:`CPACK_DEBIAN__DESCRIPTION` variables.
+
 * The :cpack_gen:`CPack Archive Generator` learned to generate ``.tar.zst``
   packages with Zstandard compression.
 
+.. _`Debian Policy Manual`: 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#description
+
 Deprecated and Removed Features
 ===
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a933d8d84e527b04920773d296b09bdcc0872ecf
commit a933d8d84e527b04920773d296b09bdcc0872ecf
Author: Brad King 
AuthorDate: Fri Oct 4 11:41:08 2019 -0400
Commit: Brad King 
CommitDate: Mon Oct 7 10:45:05 2019 -0400

Help: Organize and revise 3.16 release notes

Add section headers similar to the 3.15 release notes and move each
individual bullet into an appropriate section.  Revise a few bullets.
Drop bullets covering internal interfaces.

diff --git a/Help/release/3.16.rst b/Help/release/3.16.rst
index 760335d..8d8490e 100644
--- a/Help/release/3.16.rst
+++ b/Help/release/3.16.rst
@@ -7,30 +7,26 @@ CMake 3.16 Release Notes
 
 Changes made since CMake 3.15 include the following.
 
-* The :command:`find_package` command has learned to check the following
-  variables to control searching
+New Features
+
 
-  * :variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY` - Controls the searching the
-cmake user registry.
+Languages
+-
 
-* The :variable:`CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` has been deprecated.
-  Instead use :variable:`CMAKE_FIND_USE_PACKAGE_REGISTRY`
+* CMake learned to support the Objective C (``OBJC``) and Objective C++
+  (``OBJCXX``) languages.  They may be enabled via the :command:`project`
+  and :command:`enable_language` commands.  When ``OBJC`` or ``OBJCXX``
+  is enabled, source files with the ``.m`` or ``.mm``, respectively,
+  will be compiled as Objective C or C++.  Otherwise they will be treated
+  as plain C++ sources as they were before.
 
-* A new target property, :prop_tgt:`INSTALL_REMOVE_ENVIRONMENT_RPATH`, was
-  added which removes compiler-defined rpaths from a target. This property is
-  initialized by :variable:`CMAKE_INSTALL_REMOVE_ENVIRONMENT_RPATH`.
+Compilers
+-
 
-* A new test property, :prop_test:`SKIP_REGULAR_EXPRESSION`, has been added.
-  This property is similar to :prop_test:`FAIL_REGULAR_EXPRESSION` and
-  :prop_test:`PASS_REGULAR_EXPRESSION`, but with the same meaning as
-  :prop_test:`SKIP_RETURN_CODE`. This is useful, for example, in cases where
-  the user has no control over the return code of the test. For example, in
-  Catch2, the return value is the number of assertion failed, therefore it is
-  impossible 

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

[Cornelis Bockemühl]

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?

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?

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

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

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.15.4-1323-gb734a04

[Kitware Robot via Cmake-commits]

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

The branch, master has been updated
   via  b734a04164dcd4eb37246b4b0d52e22996d8ef43 (commit)
   via  c6f08a2125d98a22ae08f6ac8f39095bda09b490 (commit)
  from  947b02e2e0d0a7d9c8155b50ac79b56818f4b6f6 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b734a04164dcd4eb37246b4b0d52e22996d8ef43
commit b734a04164dcd4eb37246b4b0d52e22996d8ef43
Merge: 947b02e c6f08a2
Author: Brad King 
AuthorDate: Mon Oct 7 14:47:46 2019 +
Commit: Kitware Robot 
CommitDate: Mon Oct 7 10:47:54 2019 -0400

Merge topic 'doc_custom_commands_crosscompile'

c6f08a2125 Help: Clarify how target names are handled in custom 
commands/targets

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c6f08a2125d98a22ae08f6ac8f39095bda09b490
commit c6f08a2125d98a22ae08f6ac8f39095bda09b490
Author: Craig Scott 
AuthorDate: Sat Oct 5 23:11:14 2019 +1000
Commit: Craig Scott 
CommitDate: Sat Oct 5 23:11:14 2019 +1000

Help: Clarify how target names are handled in custom commands/targets

Fixes: #19771

diff --git a/Help/command/add_custom_command.rst 
b/Help/command/add_custom_command.rst
index ab2a023..df7cc4e 100644
--- a/Help/command/add_custom_command.rst
+++ b/Help/command/add_custom_command.rst
@@ -79,25 +79,33 @@ The options are:
   will be ignored.
 
   If ``COMMAND`` specifies an executable target name (created by the
-  :command:`add_executable` command) it will automatically be replaced
-  by the location of the executable created at build time. If set, the
-  :prop_tgt:`CROSSCOMPILING_EMULATOR` executable target property will
-  also be prepended to the command to allow the executable to run on
-  the host.
-  (Use the ``TARGET_FILE``
-  :manual:`generator expression ` to
-  reference an executable later in the command line.)
-  Additionally a target-level dependency will be added so that the
-  executable target will be built before any target using this custom
-  command.  However this does NOT add a file-level dependency that
-  would cause the custom command to re-run whenever the executable is
-  recompiled.
+  :command:`add_executable` command), it will automatically be replaced
+  by the location of the executable created at build time if either of
+  the following is true:
+
+  * The target is not being cross-compiled (i.e. the
+:variable:`CMAKE_CROSSCOMPILING` variable is not set to true).
+  * The target is being cross-compiled and an emulator is provided (i.e.
+its :prop_tgt:`CROSSCOMPILING_EMULATOR` target property is set).
+In this case, the contents of :prop_tgt:`CROSSCOMPILING_EMULATOR` will be
+prepended to the command before the location of the target executable.
+
+  If neither of the above conditions are met, it is assumed that the
+  command name is a program to be found on the ``PATH`` at build time.
 
   Arguments to ``COMMAND`` may use
   :manual:`generator expressions `.
-  References to target names in generator expressions imply target-level
-  dependencies, but NOT file-level dependencies.  List target names with
-  the ``DEPENDS`` option to add file-level dependencies.
+  Use the ``TARGET_FILE`` generator expression to refer to the location of
+  a target later in the command line (i.e. as a command argument rather
+  than as the command to execute).
+
+  Whenever a target is used as a command to execute or is mentioned in a
+  generator expression as a command argument, a target-level dependency
+  will be added automatically so that the mentioned target will be built
+  before any target using this custom command.  However this does NOT add
+  a file-level dependency that would cause the custom command to re-run
+  whenever the executable is recompiled.  List target names with
+  the ``DEPENDS`` option to add such file-level dependencies.
 
 ``COMMENT``
   Display the given message before the commands are executed at
diff --git a/Help/command/add_custom_target.rst 
b/Help/command/add_custom_target.rst
index e74960c..2d5f5f0 100644
--- a/Help/command/add_custom_target.rst
+++ b/Help/command/add_custom_target.rst
@@ -58,18 +58,30 @@ The options are:
   a ``COMMAND`` to launch it.)
 
   If ``COMMAND`` specifies an executable target name (created by the
-  :command:`add_executable` command) it will automatically be replaced
-  by the location of the executable created at build time. If set, the
-  :prop_tgt:`CROSSCOMPILING_EMULATOR` executable target property will
-  also be prepended to the command to allow the executable to run on
-  the host.
-  Additionally a target-level 

[Cmake-commits] CMake branch, master, updated. v3.15.4-1321-g947b02e

[Kitware Robot via Cmake-commits]

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

The branch, master has been updated
   via  947b02e2e0d0a7d9c8155b50ac79b56818f4b6f6 (commit)
   via  a023a2e4fe289dedd42a883464c9f7514ac0d0e9 (commit)
   via  27928290acc81971fbaf5cac04f9667ba39d72d8 (commit)
   via  12368e6d15c4fd7a682aad8127fb4168971d0013 (commit)
   via  9c9e66289acc7f54dfdb518a92b625f5a34c7c2d (commit)
   via  3ded5b6da8cb10d855e36d4ea534222ba870d165 (commit)
  from  52891c816d167a417961f5a7dbb1c2f0636969ab (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=947b02e2e0d0a7d9c8155b50ac79b56818f4b6f6
commit 947b02e2e0d0a7d9c8155b50ac79b56818f4b6f6
Merge: a023a2e 3ded5b6
Author: Brad King 
AuthorDate: Mon Oct 7 14:34:41 2019 +
Commit: Kitware Robot 
CommitDate: Mon Oct 7 10:34:50 2019 -0400

Merge topic 'export-genex-under-prefix'

3ded5b6da8 install,export: Fix export of a genex following $

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a023a2e4fe289dedd42a883464c9f7514ac0d0e9
commit a023a2e4fe289dedd42a883464c9f7514ac0d0e9
Merge: 2792829 9c9e662
Author: Brad King 
AuthorDate: Mon Oct 7 14:33:41 2019 +
Commit: Kitware Robot 
CommitDate: Mon Oct 7 10:33:50 2019 -0400

Merge topic 'test-per-config-sources'

9c9e66289a Tests: Enable ConfigSources test on every configuration

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27928290acc81971fbaf5cac04f9667ba39d72d8
commit 27928290acc81971fbaf5cac04f9667ba39d72d8
Merge: 52891c8 12368e6
Author: Brad King 
AuthorDate: Mon Oct 7 14:31:52 2019 +
Commit: Kitware Robot 
CommitDate: Mon Oct 7 10:32:03 2019 -0400

Merge topic 'doc-install-strip'

12368e6d15 Help: Document install/strip targets for Ninja/UNIX Makefiles 
generators

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12368e6d15c4fd7a682aad8127fb4168971d0013
commit 12368e6d15c4fd7a682aad8127fb4168971d0013
Author: Cristian Adam 
AuthorDate: Fri Oct 4 16:40:54 2019 +0200
Commit: Cristian Adam 
CommitDate: Fri Oct 4 17:00:18 2019 +0200

Help: Document install/strip targets for Ninja/UNIX Makefiles generators

diff --git a/Help/generator/Ninja.rst b/Help/generator/Ninja.rst
index 51ef49b..c75d2c4 100644
--- a/Help/generator/Ninja.rst
+++ b/Help/generator/Ninja.rst
@@ -3,9 +3,9 @@ Ninja
 
 Generates build.ninja files.
 
-A build.ninja file is generated into the build tree.  Recent versions
-of the ninja program can build the project through the ``all`` target.
-An ``install`` target is also provided.
+A ``build.ninja`` file is generated into the build tree.  Use the ninja
+program to build the project through the ``all`` target and install the
+project through the ``install`` (or ``install/strip``) target.
 
 For each subdirectory ``sub/dir`` of the project, additional targets
 are generated:
@@ -16,6 +16,13 @@ are generated:
 ``sub/dir/install``
   Runs the install step in the subdirectory, if any.
 
+``sub/dir/install/strip``
+  Runs the install step in the subdirectory followed by a ``CMAKE_STRIP`` 
command,
+  if any.
+
+  The ``CMAKE_STRIP`` variable will contain the platform's ``strip`` utility, 
which
+  removes symbols information from generated binaries.
+
 ``sub/dir/test``
   Runs the test step in the subdirectory, if any.
 
diff --git a/Help/generator/Unix Makefiles.rst b/Help/generator/Unix 
Makefiles.rst
index 1e65ee1..dfe4ecb 100644
--- a/Help/generator/Unix Makefiles.rst 
+++ b/Help/generator/Unix Makefiles.rst 
@@ -3,6 +3,29 @@ Unix Makefiles
 
 Generates standard UNIX makefiles.
 
-A hierarchy of UNIX makefiles is generated into the build tree.  Any
-standard UNIX-style make program can build the project through the
-default ``all`` target.  An ``install`` target is also provided.
+A hierarchy of UNIX makefiles is generated into the build tree.  Use
+any standard UNIX-style make program to build the project through
+the ``all`` target and install the project through the ``install``
+(or ``install/strip``) target.
+
+For each subdirectory ``sub/dir`` of the project a UNIX makefile will
+be created, containing the following targets:
+
+``all``
+  Depends on all targets required by the subdirectory.
+
+``install``
+  Runs the install step in the subdirectory, if any.
+
+``install/strip``
+  Runs the install step in the subdirectory followed by a ``CMAKE_STRIP`` 
command,
+  if any.
+
+  The ``CMAKE_STRIP`` variable will contain the platform's ``strip`` utility, 
which
+  removes 

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] Looking for an explanation: What exactly means "install" in cmake language?

[J Decker]

Install steps are done with `cmake --build . --target install`  (or
--target INSTALL on some generators)
It's done after the build is complete, if the build step fails, it will not
install.  (Install depends on build automatically)

The install steps can also be used by --target package - which you can use
a packager to .tar.gz or NSIS(?) Executable or.  It needs some CPACK
instructions set.


On Mon, Oct 7, 2019 at 6:44 AM Cornelis Bockemühl 
wrote:

> 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.
>
> 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?
>
> 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?
>
> 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 difficult if you never know what is supposed to happen
> how and at what stage of the process and under which conditions!
>
> But then I see that others are still using the install() steps, so there
> is probably still some meaning in it...
>
> So IF such a thing exists, like a comprehensive explanation about what
> "install" actually means and what it is supposed to do at what stage of the
> process, I would be very happy and thankful!
>
> Best regards,
> Cornelis
>   --
>
> 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 

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

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

[Cornelis Bockemühl]

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.

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?

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?

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 difficult if you never know what is supposed to happen how and at 
what stage of the process and under which conditions!

But then I see that others are still using the install() steps, so there is 
probably still some meaning in it...

So IF such a thing exists, like a comprehensive explanation about what 
"install" actually means and what it is supposed to do at what stage of the 
process, I would be very happy and thankful!

Best regards,
Cornelis
 
-- 

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] Adding CRC32 to ELF

[Vincent van Beveren]

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!


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

Re: [CMake] DEPENDS parameter of add_custom_target

[Craig Scott]

On Mon, Oct 7, 2019 at 11:21 PM Setzer Sebastian (CM-CI2/ECS2) <
sebastian.set...@de.bosch.com> wrote:

> Hi Craig,
>
> On Mon, 7. Oct 2019 12:56 Craig Scott wrote:
> > As it happens, I just updated the docs for these in the last day or so.
>
> You mean you updated the docs of the two commands, but you did not update
> the docs of the DEPENDS parameter, right?
>

Yes, sorry if that was only partially related to your original query.
Fred's follow-up makes it clearer that the wording of a few sections for
these two commands probably need some improvement (that will be separate to
the merge request I linked to).



> > There is a difference between the two, but it's subtle and specific to
> the sort of scenario I mentioned in that issue comment.
>
> So the manual for the DEPENDS parameter of add_custom_target is outdated,
> but fixing it is not as easy as copying it from add_custom_command.
>

I'll defer a response on whether it is outdated or not, but I would expect
different text to be required for the two commands because they do have
different behaviours.



From: Craig Scott 
> Sent: Montag, 7. Oktober 2019 12:56
> To: Setzer Sebastian (CM-CI2/ECS2) 
> Cc: cmake@cmake.org
> Subject: Re: [CMake] DEPENDS parameter of add_custom_target
>
>
>
> On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake
>  wrote:
> Dear list,
> The manual says:
> https://cmake.org/cmake/help/latest/command/add_custom_target.html
> 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.
> Use the add_dependencies() command to add dependencies on other targets.
>
> This is different from what the manual of add_custom_command says, and
> would be surprising for all users who only read the manual of
> add_custom_command and then think they know what the parameter means for
> add_custom_target.
>
> But on the other hand, when I test with this:
> --
> cmake_minimum_required (VERSION 3.14)
> project(dependency_test LANGUAGES)
>
> add_custom_target(T1
>   COMMAND echo T1
>   )
> add_custom_target(T2
>   COMMAND echo T2
>   DEPENDS T1
>   )
>
> # cmake -GNinja -B build .
> # ninja T2
> --
> Then T1 and T2 are built, so contrary to what the manual says, it seems to
> work.
>
> Is the manual just outdated (Maybe behavior has changed and only manual
> for add_custom_command has been updated)?
> Should it be the same as for add_custom_command, or are there really some
> differences?
>
> As it happens, I just updated the docs for these in the last day or so.
> You can find it in the not-yet-merged merge request here:
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/3891
>
> I wrote an explanation of the specific behavior of the dependencies in the
> associated issue here:
>
> https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547
>
> There is a difference between the two, but it's subtle and specific to the
> sort of scenario I mentioned in that issue comment.
>

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-- 

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] DEPENDS parameter of add_custom_target

[Setzer Sebastian (CM-CI2/ECS2) via CMake]

Hi Craig,

On Mon, 7. Oct 2019 12:56 Craig Scott wrote:
> As it happens, I just updated the docs for these in the last day or so.

You mean you updated the docs of the two commands, but you did not update the 
docs of the DEPENDS parameter, right?

> There is a difference between the two, but it's subtle and specific to the 
> sort of scenario I mentioned in that issue comment.

So the manual for the DEPENDS parameter of add_custom_target is outdated, but 
fixing it is not as easy as copying it from add_custom_command.

Regards,
Sebastian
 

From: Craig Scott  
Sent: Montag, 7. Oktober 2019 12:56
To: Setzer Sebastian (CM-CI2/ECS2) 
Cc: cmake@cmake.org
Subject: Re: [CMake] DEPENDS parameter of add_custom_target



On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake 
 wrote:
Dear list,
The manual says:
https://cmake.org/cmake/help/latest/command/add_custom_target.html
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.
Use the add_dependencies() command to add dependencies on other targets.

This is different from what the manual of add_custom_command says, and would be 
surprising for all users who only read the manual of add_custom_command and 
then think they know what the parameter means for add_custom_target.

But on the other hand, when I test with this:
--
cmake_minimum_required (VERSION 3.14)
project(dependency_test LANGUAGES)

add_custom_target(T1
                  COMMAND echo T1
                  )
add_custom_target(T2
                  COMMAND echo T2
                  DEPENDS T1
                  )

# cmake -GNinja -B build .
# ninja T2
--
Then T1 and T2 are built, so contrary to what the manual says, it seems to work.

Is the manual just outdated (Maybe behavior has changed and only manual for 
add_custom_command has been updated)?
Should it be the same as for add_custom_command, or are there really some 
differences?

As it happens, I just updated the docs for these in the last day or so. You can 
find it in the not-yet-merged merge request here:

https://gitlab.kitware.com/cmake/cmake/merge_requests/3891

I wrote an explanation of the specific behavior of the dependencies in the 
associated issue here:

https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547

There is a difference between the two, but it's subtle and specific to the sort 
of scenario I mentioned in that issue comment.

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

Get the hand-book for every CMake user: https://crascit.com/professional-cmake/
Consulting services (CMake, C++, build/release processes): 
https://crascit.com/services
-- 

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] DEPENDS parameter of add_custom_target

[Fred Baksik]

On Mon, Oct 7, 2019, at 6:55 AM, Craig Scott wrote:
> 
> 
> On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake 
>  wrote:
>> Dear list,
>>  The manual says:
>> https://cmake.org/cmake/help/latest/command/add_custom_target.html
>>  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.
>>  Use the add_dependencies() command to add dependencies on other targets.
>> 
>>  This is different from what the manual of add_custom_command says, and 
>> would be surprising for all users who only read the manual of 
>> add_custom_command and then think they know what the parameter means for 
>> add_custom_target.
>> 
>>  But on the other hand, when I test with this:
>>  --
>>  cmake_minimum_required (VERSION 3.14)
>>  project(dependency_test LANGUAGES)
>> 
>>  add_custom_target(T1
>>  COMMAND echo T1
>>  )
>>  add_custom_target(T2
>>  COMMAND echo T2
>>  DEPENDS T1
>>  )
>> 
>>  # cmake -GNinja -B build .
>>  # ninja T2
>>  --
>>  Then T1 and T2 are built, so contrary to what the manual says, it seems to 
>> work.
>> 
>>  Is the manual just outdated (Maybe behavior has changed and only manual for 
>> add_custom_command has been updated)?
>>  Should it be the same as for add_custom_command, or are there really some 
>> differences?
> 
> As it happens, I just updated the docs for these in the last day or so. You 
> can find it in the not-yet-merged merge request here:
> 
> https://gitlab.kitware.com/cmake/cmake/merge_requests/3891
> 
> I wrote an explanation of the specific behavior of the dependencies in the 
> associated issue here:
> 
> https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547
> 
> There is a difference between the two, but it's subtle and specific to the 
> sort of scenario I mentioned in that issue comment.
> 
> -- 
> Craig Scott
> Melbourne, Australia
> https://crascit.com
> 
> Get the hand-book for every CMake user: Professional CMake: A Practical Guide 
> 
> Consulting services (CMake, C++, build/release processes): 
> https://crascit.com/services
> -- 
> 
> 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

I found the wording for add_custom_command and add_custom_target to be 
confusing and had to look at examples (and books) to understand it better.

The DEPENDS field is kind of different for the two commands. 

It may be that add_custom_target "DEPENDS" can accept other custom targets; it 
seems from your example it does (which wouldn't surprise me from what I 
remember from the CMake source code).

For add_custom_target:
The phrase "They will be brought up to date when the target is built." had me 
thinking that this was going to force the custom command to always run.

Its more of a "The commands of add_custom_target() outputs will be run as 
needed before any add_custom_target() commands are run."

If a file listed in DEPENDS does not exist on disk then behavior is defined by 
the build tool and may or may not throw an error. I recall that Make and Ninja 
throws errors and MSBuild will have a warning.

Then there is the SOURCES field which acts like:
Similar to ``DEPENDS`` with the addition that the specified files are checked 
to exist on disk and will be added to IDE project files for convenience in 
editing.

"add_custom_target() sometimes builds SOURCES for Visual Studio generators but 
never for Makefiles"
https://gitlab.kitware.com/cmake/cmake/issues/10360

For add_custom_command it acts like (and this includes the trick that is used 
to make it always run):
If ``DEPENDS`` is not specified the command will run whenever the ``OUTPUT`` is 
missing or it will run whenever a file-level dependency is updated. If the 
command does not create one of the listed ``OUTPUT`` then the rule will always 
run. For example defining an output file called ALL or FORCE that is never 
created.

Then for the add_custom_command signature that is used for build events. You 
don't need to put the event. It defaults to POST_BUILD. This is different from 
the documentation that shows it is a required field.

--
Fred-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 

Re: [CMake] DEPENDS parameter of add_custom_target

[Craig Scott]

On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake <
cmake@cmake.org> wrote:

> Dear list,
> The manual says:
> https://cmake.org/cmake/help/latest/command/add_custom_target.html
> 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.
> Use the add_dependencies() command to add dependencies on other targets.
>
> This is different from what the manual of add_custom_command says, and
> would be surprising for all users who only read the manual of
> add_custom_command and then think they know what the parameter means for
> add_custom_target.
>
> But on the other hand, when I test with this:
> --
> cmake_minimum_required (VERSION 3.14)
> project(dependency_test LANGUAGES)
>
> add_custom_target(T1
>   COMMAND echo T1
>   )
> add_custom_target(T2
>   COMMAND echo T2
>   DEPENDS T1
>   )
>
> # cmake -GNinja -B build .
> # ninja T2
> --
> Then T1 and T2 are built, so contrary to what the manual says, it seems to
> work.
>
> Is the manual just outdated (Maybe behavior has changed and only manual
> for add_custom_command has been updated)?
> Should it be the same as for add_custom_command, or are there really some
> differences?
>

As it happens, I just updated the docs for these in the last day or so. You
can find it in the not-yet-merged merge request here:

https://gitlab.kitware.com/cmake/cmake/merge_requests/3891

I wrote an explanation of the specific behavior of the dependencies in the
associated issue here:

https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547

There is a difference between the two, but it's subtle and specific to the
sort of scenario I mentioned in that issue comment.

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-- 

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] DEPENDS parameter of add_custom_target

[Setzer Sebastian (CM-CI2/ECS2) via CMake]

Dear list,
The manual says:
https://cmake.org/cmake/help/latest/command/add_custom_target.html
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.
Use the add_dependencies() command to add dependencies on other targets.

This is different from what the manual of add_custom_command says, and would be 
surprising for all users who only read the manual of add_custom_command and 
then think they know what the parameter means for add_custom_target.

But on the other hand, when I test with this:
--
cmake_minimum_required (VERSION 3.14)
project(dependency_test LANGUAGES)

add_custom_target(T1
  COMMAND echo T1
  )
add_custom_target(T2
  COMMAND echo T2
  DEPENDS T1
  )

# cmake -GNinja -B build .
# ninja T2
--
Then T1 and T2 are built, so contrary to what the manual says, it seems to work.

Is the manual just outdated (Maybe behavior has changed and only manual for 
add_custom_command has been updated)?
Should it be the same as for add_custom_command, or are there really some 
differences?

Regards,
Sebastian
-- 

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

[James Turner via CMake]

Hello,

I’m experiencing an odd problem where no matter how I set CMP0093, it seems to 
use the ‘NEW’ behaviour, breaking some other code relying on the OLD behaviour.

This is Cmake 3.15.4 from Homebrew, other people do report on other platforms 
do report the policy working for them. Here’s my code to set the policy, in the 
same place we set other policy options:

if(POLICY CMP0093)
 message(STATUS "Using old Boost version policy")
 cmake_policy(SET CMP0093 OLD)
endif()

The message is printed correctly, but after running find_package(Boost…), the 
value of Boost_VERSION is the new dotted syntax (eg 1.71.0) rather than the 
old, compatible syntax I need.

Is there anything special about this policy where I might have screwed this up? 
I can’t really imagine it’s a Homebrew packaging issue, but also don’t 
understand what else I could have gotten wrong syntactically.

Kind regards,
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