")
> endif ()
>
> sprokit_configure_file_always(version.h
> "${CMAKE_CURRENT_SOURCE_DIR}/version.h.in"
> "${CMAKE_CURRENT_BINARY_DIR}/version.h"
> sprokit_version_major
> sprokit_version_minor
> sprokit_version_patch
> sprokit_version
> SPROKIT_BUILT_FROM_GIT
> sprokit_git_hash
> sprokit_git_hash_short
> sprokit_git_dirty)
> # ...
>
> ```
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 15, 2020, 1:30pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/9 "2020-04-15T13:30:26Z")
> [@Artemis](#):
>
> that script fetches the extra info from git (the git hash).
You could just as easily fetch the date in your code. It’s more about the pattern of fetching data at build time and only updating things if they need to.
---
### Author:  [@Artemis](https://discourse.cmake.org/u/Artemis)
#### Post date: [April 16, 2020, 11:02am UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/10 "2020-04-16T11:02:02Z")
The date should itself be generated:
> [@ben.boeckel](#):
>
> You could just as easily fetch the date in your code. It’s more about the pattern of fetching data at build time and only updating things if they need to.
If I’d decided to hard-code the date, and triggered an out of source update, eventually that updated date would have had to be hard-coded back in the source again, to be fetched by subsequent builds.
To be clear, this is the reasoning behind:
- the library is being built as the main project? that probably means someone is working on it and making main modifications: update the build date
- the library is not being built as the main project? that probably means it’s just being compiled to be used in another project, **leave the build date as it is**.
I’m beginning to suspect this is not how I should approach the problem, as I’m not seeing anyone doing or mentioning something like this. How is that done?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 16, 2020, 1:57pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/11 "2020-04-16T13:57:52Z")
Trigger the difference based on `CMAKE_PROJECT_NAME` rather than a `$Format:$` replacement.
---
### Author:  [@Artemis](https://discourse.cmake.org/u/Artemis)
#### Post date: [April 16, 2020, 2:25pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/12 "2020-04-16T14:25:29Z")
I’m sorry I don’t understand
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 16, 2020, 6:05pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/13 "2020-04-16T18:05:11Z")
Something like:
```cmake
if (CMAKE_PROJECT_NAME STREQUAL "thislib")
# get the date at build time
else ()
set(staticdate "20200416")
endif ()
```
---
### Author:  [@Artemis](https://discourse.cmake.org/u/Artemis)
#### Post date: [April 17, 2020, 1:25pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/14 "2020-04-17T13:25:43Z")
> [@Artemis](#):
>
> If I’d decided to hard-code the date, and triggered an out of source update, eventually that updated date would have had to be hard-coded back in the source again, to be fetched by subsequent builds.
The options I know are:
1. update the `set(staticdate "20200416")` line manually every time (I don’t want to do that)
2. make an exception of the out of source rule for `version.h`
> [@Artemis](#):
>
> I’m beginning to suspect this is not how I should approach the problem, as I’m not seeing anyone doing or mentioning something like this.
**edit** : I think the point that didn’t get through is that I’d like to do that repeatedly, not just once. The updates have to be every time permanent to make sense.
**edit 2** : Your hints brought me to the conclusion that there’s no right way to do that, it’s an inherently “not out of source” thing to do. Like you were implying, I should focus on having the updated date available only in the built executable. After all, I’ve read somewhere that the date-in-the-source thing isn’t recommended anymore.
I’ll continue with the cmaking
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 17, 2020, 2:34pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/15 "2020-04-17T14:34:14Z")
Yes, that’s what the infrastructure for `sprokit_configure_file` does in the project I linked before does. It does `configure_file` at build time. The difference is that you need to tell it what variables to send from the configure step across. There’s also support for running code in that script to make variables through logic.
---
### Author:  [@Artemis](https://discourse.cmake.org/u/Artemis)
#### Post date: [May 22, 2020, 7:21pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/16 "2020-05-22T19:21:30Z")
I’m back from the dead!
i hope
I finally got the project back in hand, and I started scraping from where I left off last time: the file dependency system doesn’t work across folders. I’ve taken another look at sprokit, but I couldn’t quite track what exactly does the trick.
Could it be that it does the `configure_file` _both_ at configure time and build time? That would avoid CMake’s complains about missing sources at configure time, and that’s what I’m currently doing. But that’s very ugly to see.
(Still better than `set_property(SOURCE "..." PROPERTY GENERATED 1)`, that’s a big no no for me)
Maybe there’s some optimization I could do to reduce code redundancy?
```cmake
macro(generate_configure_script)
file(WRITE "${configure_script_path}" "
configure_file(
\"${version_in_path}\"
\"${version_configured_path}\"
@ONLY
)
configure_file(
\"${doxyfile_in_path}\"
\"${doxyfile_configured_path}\"
@ONLY
)
")
endmacro()
configure_file( # there's no add_subdirectory() equivalent for single files :/
"${version_in_path}"
"${version_configured_path}"
@ONLY
)
configure_file(
"${doxyfile_in_path}"
"${doxyfile_configured_path}"
@ONLY
)
if("${CMAKE_PROJECT_NAME}" STREQUAL "VisualT")
generate_configure_script()
add_custom_target(configured_files ALL
COMMAND "${CMAKE_COMMAND}" -P "${configure_script_path}"
BYPRODUCTS "${version_configured_path}" "${doxyfile_configured_path}"
DEPENDS "${configure_script_path}" "${version_in_path}" "${doxyfile_in_path}"
COMMENT "configuring files")
else()
add_custom_target(configured_files ALL) # empty :|
endif()
```
As you can see I’m using a custom target, not a custom command, as the custom command doesn’t work across folders and [doesn’t work for multiple target dependencies](https://cmake.org/cmake/help/v3.16/command/add_custom_command.html#generating-files). I find that the custom command has a pretty narrow use cases after all considered. (basically same-folder, one-target, automated file dependency resolution)
---
### Author:  [@Artemis](https://discourse.cmake.org/u/Artemis)
#### Post date: [May 23, 2020, 5:14pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/17 "2020-05-23T17:14:32Z")
I improved the last solution to this:
```cmake
# macros
macro(add_configurable_file in_path configured_path)
file(APPEND "${configure_script_path}" "
configure_file(
\"${in_path}\"
\"${configured_path}\"
@ONLY
)
")
endmacro()
# variables
set(configure_script_path "${VisualT_BINARY_DIR}/conf/configureScript.cmake")
string(TIMESTAMP VisualT_BUILD_DATE "%d %B %Y" UTC)
# register configurable files
file(REMOVE "${configure_script_path}")
add_configurable_file("${VisualT_SOURCE_DIR}/src/version.h.in" "${VisualT_BINARY_DIR}/src/version.h")
add_configurable_file("${VisualT_SOURCE_DIR}/doxyfile.in" "${VisualT_BINARY_DIR}/doxyfile")
# build-time configuration if main project
if("${CMAKE_PROJECT_NAME}" STREQUAL "VisualT")
add_custom_target(configured_files ALL
COMMAND "${CMAKE_COMMAND}" -P "${configure_script_path}"
COMMENT "running configure script")
else()
add_custom_target(configured_files ALL)
endif()
# configure-time configuration to avoid missing file warnings
execute_process(
COMMAND "${CMAKE_COMMAND}" -P "${configure_script_path}")
```
It still has some ugly “code generation” but I currently don’t know a proper way to avoid that:
For example, I could create a `configurator.cmake.in` with only
```cmake
configure_file(
@configurable@
@configured@)
```
And create a new `configurator-xxx.cmake` for every configurable file. Then run all of them as separate scripts. That would get rid of the “code-in-a-string”, but it would cost too much in performance
# Edit 1
> [@Artemis](#):
>
> # there’s no add\_subdirectory() equivalent for single files 😕
goddammit I didn’t know `include()` could include standard scripts too. Now I can replace
> [@Artemis](#):
>
> ```cmake
> execute_process( COMMAND "${CMAKE_COMMAND}" -P "${configure_script_path}")
>
> ```
simply with
```cmake
include("${configure_script_path}")
```
much better.
---
### Author:  [@Artemis](https://discourse.cmake.org/u/Artemis)
#### Post date: [May 26, 2020, 5:11pm UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/18 "2020-05-26T17:11:40Z")
I had just finished basting the documentation generation (doxygen+sphinx+breathe), and I had begun removing all the unnecessary double quotes around variables I kept putting everywhere. (there’s a lot of confusion online on the matter, perhaps the documentation can be a bit misinterpreted, I had to test it by first hand). I wanted to proceed figuring out the installation and config-file packages, but I ran into this weird behaviour:
```cmake
message("PRIVATE_HEADER=" ${private_headers} "\n" "PUBLIC_HEADER=" ${public_headers})
set_target_properties(visualt PROPERTIES
PRIVATE_HEADER ${private_headers}
PUBLIC_HEADER ${public_headers})
get_target_property(private_headers visualt PRIVATE_HEADER)
get_target_property(public_headers visualt PUBLIC_HEADER)
```
gives (long paths shortened with `...`):
```nohighlight
PRIVATE_HEADER=/mnt/d/.../VisualT/cmake-build-debug-wsl/src/version.h
PUBLIC_HEADER=/mnt/d/.../VisualT/include/visualt/visualt.h/mnt/d/.../VisualT/include/visualt/visualtUnprefixed.h
CMake Error at src/CMakeLists.txt:18 (set_target_properties):
set_target_properties called with incorrect number of arguments.
```
But if I write instead
```cmake
set_target_properties(visualt PROPERTIES
PRIVATE_HEADER ${private_headers}
PUBLIC_HEADER "${public_headers}") # this probably won't work
```
Alternatively, two `set_property()` work alright.
How is that?
From `PUBLIC_HEADER`'s [documentation](https://cmake.org/cmake/help/v3.16/prop_tgt/PUBLIC_HEADER.html): `This property may be set to a list of header files`, is `set_target_properties()` unable to handle lists? why?
---
### Author:  [@McMartin](https://discourse.cmake.org/u/McMartin)
#### Post date: [May 27, 2020, 5:20am UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/19 "2020-05-27T05:20:39Z")
The signature of `set_target_properties` is
```auto
set_target_properties(target1 target2 ...
PROPERTIES prop1 value1
prop2 value2 ...)
```
When I write
```cmake
set(list_of_values "a" "b" "c" "d" "e")
set_target_properties(myTarget PROPERTIES CUSTOM_PROP ${list_of_values})
```
it gets interpreted as:
```auto
prop1 = CUSTOM_PROP
value1 = a
prop2 = b
value2 = c
prop3 = d
value3 = e
```
If I change that code to `set(list_of_values "a" "b" "c" "d")` (even number of elements), there is an argument passed for `prop3`, but not for `value3` anymore, so CMake reports an error.
Now, if I write:
```cmake
set(list_of_values "a" "b" "c" "d")
set_target_properties(myTarget PROPERTIES CUSTOM_PROP "${list_of_values}")
```
it gets interpreted as:
```auto
prop1 = CUSTOM_PROP
value1 = a;b;c;d
```
So you should quote both `${private_headers}` and `${public_headers}` when passing them to `set_target_properties`.
---
### Author:  [@Artemis](https://discourse.cmake.org/u/Artemis)
#### Post date: [May 27, 2020, 8:06am UTC](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768/20 "2020-05-27T08:06:56Z")
> [@Artemis](#):
>
> I had begun removing all the unnecessary double quotes around variables I kept putting everywhere. (there’s a lot of confusion online on the matter, perhaps the documentation can be a bit misinterpreted, I had to test it by first hand)
* * *
So that’s because of how functions are designed, right? Not because lists get expanded (like a macro), _and then_ they are interpreted as multiple arguments.
How am I supposed to write CMake code that doesn’t break if some paths have semicolons in them?
I mean, that’s a quite common character, I can’t just leave it out.
Is there a systematic way to escape them?
Else I’ll just write a `escape semicolons()` function, but I would have to use it for **every** variable reference that might contain paths. Aaah!
[Next page](https://discourse.cmake.org/t/cmake-project-review-and-suggestions-closed/768.md?page=2)