I am configuring CMake/CPack to install an application which ships with a few read-only shared data files. My understanding is that according to the FHS, such files should be stored under /usr/share, ideally within an application-specific directory (e.g. /usr/share/my_project) rather than directly under /usr/share. I am using GNUInstallDirs as an attempt to stay within (my understanding of) the expectations of the FHS using the following:
#...
include(GNUInstallDirs)
# BAD: Installs files from ${CMAKE_CURRENT_SOURCE_DIR}/data
# into /usr/share
install(DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/data/"
TYPE DATA
)
# GOOD: Installs files from ${CMAKE_CURRENT_SOURCE_DIR}/data
# into /usr/share/${PROJECT_NAME}
install(DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/data/"
DESTINATION "${CMAKE_INSTALL_DATAROOTDIR}/${PROJECT_NAME}"
)
#...
Everything works as it's documented; my questions are:
Am I understanding the FHS correctly that (ideally) I should put my applications' shared read-only data under /usr/share/my_project?
If that's the case, am I using TYPE DATA wrong in INSTALL(DIRECTORY ...)? That is, should I copy all my data to ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME} then use INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME} TYPE DATA). That seems like a waste.
Otherwise, if I'm misunderstanding where this type of data should be installed, where should it go, and is TYPE DATA the right way to use install(DIRECTORY ...)? Or do I still need to use an explicitly-specified DESTINATION?
I guess this is a nice way of asking if GNUInstallDirs and TYPE DATA are fit-for-purpose and compatible with the FHS or not. My main goal is to have CMake/CPack Just Put Things Where They Are Supposed To Live without needing to explicitly specify the proper location for each platform's installer.
Related
I want to set up my HelloWorld intellij-erlang project with all files in the same directory so I can easily switch between IDEA and emacs/vim.
<my-project>/hello.erl
<my-project>/hello.beam
Now, if I configure the output directory to be the same as the source, hello.erl gets emptied as part of the build and the compilation fails.
I assumed it's something to do with copying resources to the output directory, so I've configured intellij-erlang to exclude *.erl from the resources with a !?*.erl pattern, but this does not have any effect, hello.erl still gets emptied before the compilation takes place.
As an experiment, I've also tried using separate src and out directories, and intellij-erlang always copies the *.erl to out irrespective of the resource patterns.
Based on all this, I would conclude that intellij-erlang cannot work with all files in the same directory. Have I missed anything?
Erlang programs should be build on standard OTP directory structure. Build tools like rebar (used by intellij) or erlang.mk build on this conventions. And so should all IDE's.
Intellij does it, just like you notice. And so does Emacs's plugin (that I use and can confirm). I would guess so does Vim's one.
So if you would like to be able to switch easily between your IDE's you should try to keep to this convetion of keeping you source files in src and compiled files in bin (and headers in include).
I have a project under CMake with some files generated with python generator from XML files. I cannot specify all files generated by this generator in CMakeLists.txt so I use file globbing for this.
The problem is that when I update my XML files or generator sources (which are in the same repository) I would like to have my build system reconfigured so changed files are taken into account when rebuilding the code (via make for example).
Is it possible to make CMake treat some files like it treats CMakeLists.txt files and to make it regenerate build system when those file are changed?
It doesn't require any kind of workarounds. The standard way is to use CMAKE_CONFIGURE_DEPENDS property:
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS <filename>)
Yes, you should be able to do that by (ab)using configure_file(). Configuring a file makes the source a dependency of the CMake run, so that any changes in it cause a reconfiguration. Simply like this:
configure_file(MyInputFile.xml DummyOutput.xml)
Since it has been a while I will add to #roolebo's answer.
There's actually a better command to add a dependency on a file:
set_directory_properties(PROPERTIES CMAKE_CONFIGURE_DEPENDS <relative_or_full_path_to_file>)
What might be confusing is that this command adds a property to the current directory. Well, it does not matter since you can set a full path to a file that resides outside of the current directory's scope, for instance: ../../config.json
I try to write a file store based on libgit2.
Software snapshots should be saved as branches mysoftware and specific versions committed and tagged. Then later I want to checkout the tags to different directories.
When looking at git_checkout_tree, it seems like there is only one working tree for a repository and thus it does not even seem possible to checkout multiple working trees concurrently.
Is this correct!?
EDIT:
Additionally, I would like for this thing to work on Windows without the need for cygwin!
The git_checkout_opts structure in libgit2 contains a target_directory option that will allow git_checkout_tree() to write to a different directory instead of using the default working tree for the repository. This would allow you to custom build a solution with libgit2 that maintained multiple checked out copies.
Without using that option, a libgit2 git_repository object expects there will be just one working directory and looks to the core.worktree config option if it isn't the "natural" working directory for the repository.
The git-new-workdir tricks with symlinks in the .git directory don't work great with libgit2 right now, I'm afraid, and particularly doesn't work well on Windows. I'd love to see this addressed, but it isn't too high on my priority list.
Git doesn't support this natively, but you can use git-new-workdir to do it.
I have written a CMake module that contains a couple of useful macros that I would like to use across a number of other CMake projects. However, I'm not sure where to put the module.
I would like to be able to do this inside each project that uses the macro:
include(MyModule)
However, I'm not sure if there is an easy and cross-platform way of achieving this. In fact, I can't even get it to work on Unix. I put the module (MyModule.cmake) in the following locations:
/usr/lib/cmake/
/usr/lib/cmake/Modules
/usr/local/lib/cmake
/usr/local/lib/cmake/Modules
...and the project with the include() was unable to load the module.
What is the correct location for this module? Is there a better approach?
I should also point out that the macros are not related to "finding" a third-party library and therefore have nothing to do with find_package().
Put the module in a directory of your choice, and then add that directory to CMAKE_MODULE_PATH using list(APPEND).
You can even host that module somewhere and then download it via file(DOWNLOAD). If you download it to the same directory as the current CMake script being processed, you just include(MyModule.cmake) and don't need to modify CMAKE_MODULE_PATH.
You could download the file to a common location on disk and then add a check using if(EXISTS "${module_location_on_disk}") to skip the download if it's already downloaded. Of course, more logic will be required if your module changes, or you want to have a common location and multiple versions of the module, but that's out of those scope of your question.
Intermediate object files always get built in the same directory (which for me defaults to CMakeFiles/<target>.dir/). Is it possible to make this directory configuration-dependent? That would save me from recompiling all the object files every time I switch configuration.
You should use separate build tree for each build configuration instead.