missing cmake package config call added #19
Conversation
Correction for QHULL and Python
Gathers both examples and tests
pkg-config.cmake: use CACHE INTERNAL for _PKG_CONFIG_* variables.
…tall Fix CMP0007 policy problem + .catkin removal in case of catkin package.
This macros provides a way to build some source file and store them in the build directory. Then, the install macro can copy those files to the adequate destination. Thus, the compilation can be done without calling the "install" target, which makes it easier to test local modules. We rely on ADD_CUSTOM_TARGET for the compilation of each file.
python.cmake: add a PYTHON_BUILD macro.
The following commit should be especially useful: Kitware/CMake@620939e From 620939e4e6f5a61cd5c0fac2704de4bfda0eb7ef Mon Sep 17 00:00:00 2001 From: "Daniele E. Domenichelli" <daniele.domenichelli@iit.it> Date: Mon, 13 Jan 2014 09:31:34 +0100 Subject: [PATCH] GNUInstallDirs: Fix CMAKE_INSTALL_LIBDIR on Debian When not installing in /usr (i.e. /usr/local) on Debian/Ubuntu, the multiarch path is not in ldconfig path, and therefore libraries cannot be found, unless the user manually modifies the files in /etc/ld.so.conf.d, in order to include /usr/local/lib/<arch>. This patch fixes this issue by using "lib/<arch>" only if the user is installing the software in /usr, and uses "lib" in all the other cases.
Add support for paths in GENERATE_IDL_FILE.
This macro may help CUDA users forward flags to CUDA_ADD_* macros.
Indeed, SET_TARGET_PROPERTIES does not work on CUDA libraries or
executables, so PKG_CONFIG_USE_COMPILE_DEPENDENCY cannot be used,
and the compiler options need to be given directly to the CUDA_ADD_*
macro (the other option is to modify CUDA_{C/CXX}_FLAGS...).
SET(${LIB_NAME}_OPTIONS "")
PKG_CONFIG_ADD_COMPILE_OPTIONS(${LIB_NAME}_OPTIONS my-dependency)
CUDA_ADD_LIBRARY(${LIB_NAME} ${LIB_SRC}
SHARED OPTIONS ${${LIB_NAME}_OPTIONS})
Add a PKG_CONFIG_ADD_COMPILE_OPTIONS macro.
This reported the previous tag on commits with a new tag.
It adds the files, generates a custom target and compiles it It needs more work to support more languages and less configuration.
Doxygen improvements
Also no longer use CACHE.
Setting this variable has the following effects:
- Set CMAKE_DEBUG_POSTFIX to PROJECT_DEBUG_POSTFIX
- Generate a different .pc file named
${PROJECT_NAME}${PROJECT_DEBUG_POSTFIX}.pc when building in Debug mode
- Generate two .pc files for multiple build types generators (e.g. Visual
Studio)
The following macros are added:
- PKG_CONFIG_APPEND_CFLAGS_DEBUG
- PKG_CONFIG_APPEND_CFLAGS_OPTIMIZED
They allow to add specific flags for the debug and optimized version of the
project.
Finally, PKG_CONFIG_APPEND_LIBS was modified to apply the postfix on libraries
built by the project.
* header: correct doc
* version: correct indents
* version: fill PROJECT_VERSION_{MAJOR,MINOR,PATCH}
* version: add PROJECT_{MAJOR,MINOR,PATCH}_VERSION in config.hh
* header: add the possibility to change the header file extension
* version: add AUTHOR_WARNING for specific messages
Related to discussions in #162.
* version: check if the {MAJOR,MINOR,PATCH} project version has already been set
* version: remove string version
* correct copyright
* project: add global variable PROJECT_CUSTOM_HEADER_EXTENSION and its doc
* version: handle version of the form 1.0
test: force linkage with LD_LIBRARY_PATH
Version: Also computes {MAJOR,MINOR,PATCH} when reading .version file
* [Boost-python] fix version detection on debian systems * [Boost-python] fix version detection on non-debian non-apple systems * Adding CHECK_DEBIAN * CHECK_DEBIAN: globally sets DEBIAN_FOUND
* [Python] errors if python bin and libs versions differ * [Doc] Update doc of macro FINDPYTHON
* master: (54 commits)
[Python] errors if python bin and libs versions differ (#165)
Adding CHECK_DEBIAN (#168)
version: also computes {MAJOR,MINOR,PATCH} when reading .version file
test: force linkage with LD_LIBRARY_PATH
[Doxygen] Avoid inclusion of non-existant directory. (#161)
Handle {MAJOR,MINOR,PATCH} version (#162)
Add PROJECT_USE_KEYWORD_LINK_LIBRARIES (#160)
Correctly add required libraries to .pc in a debug-only build
[doxygen.cmake] Fix message printed by CMake. (#159)
Support version scripts (#113)
doc: correct inclusion of gtest
gtest: make silent the inclusion of gtest headers
doc: add gtest in the documentation tree
Add support of google-test (#157)
[dist] Update to take into account PROJECT_SUFFIX
[distcheck] Add suffix
[python] Fix if block.
[python] Add the possibility to compile another source file than the template.
On WIN32 filter the flags passed to target_link_libraries (#153)
[python] Fix #144. Modifies DYNAMIC_GRAPH_PYTHON_MODULE to handle __init__.py Pb: If __init__.py is handled by the user, there is a conflict when DYNAMIC_GRAPH_PYTHON_MODULE is used too. This raised a problem in sot-core. This commit fixes the issue.
...
* commit 'ec26d006bd02d9b5804e17835076fb60171ac269': improve .gitignore missing cmake package config call added (jrl-umi3218#11)
* master: Add gitignore (jrl-umi3218#17) Forgotten call to deprecated function Rename get/setCordinates -> get/setCoordinates Improve polyhedron parsing (jrl-umi3218#13) # Conflicts: # .gitignore
* [Doc] Add ability to configure Doxygen layout. * [HPP] Add files related to Humanoid Path Planner project + doc.
* c++11: add support for c++11 * c++11: check support of c++11 by the compiler * cxx11: add standard requirement * cxx11: remove suppression of policy warning
* commit '320c636960b03b3bad7c7a08bd2e104951f42bc3': Add support for c++11 (#170) [HPP] Add CMake variables HPP_DEBUG and HPP_BENCHMARK Add files related to Humanoid Path Planner project (#173)
|
See also: jrl-umi3218/jrl-cmakemodules#124 |
|
I've updated this pull request to use the other submodules as subtrees, which makes life easier, particularly when dealing with multiple forks of the repository. |
|
I'd rather not switch to a sub-tree (this is also relevant to jrl-umi3218/Tasks#50) In our experience (we used to have such a meta-repository + build script to get the full stack at once), the main benefit of working with sub-trees is in fact the initial clone/build which is simpler. However, it is also very easy to break the repository/history because it requires much more discipline (in particular when working across multiple repositories) to work with sub-trees. |
|
Some of the repositories are already sub-trees though and others aren't. I understand that problem, but modules don't work with forks by default, it will only go the original source, not the location actually inuse. Some of the bugs I need to be able to install on my system, particularly the python fixes, haven't been merged in the last couple years so I've needed to maintain things separately, and your submodules don't contain my commits which fix the build. Perhaps you have an alternative idea? Maybe it used to be subtrees and the update instructions haven't been corrected? Isn't a mix of both subtrees and submodules worse? |
|
I think this is a more minimal fix #20 independent of subtrees/submodules. |
This is surprising. I'd think you change the
Sorry about that. I think you are referring to jrl-umi3218/jrl-cmakemodules#124 I think we could merge that if that solves your issue.
It's subtrees in Tasks because submodules don't work in subtrees and this was a problem for the (deprecated) meta-repository. This hasn't been changed since as ultimately it doesn't have much impact (we don't update the cmake subfolder in this repository these days). In summary, we still have some subtrees where we usually have submodules (typically cmake subfolder) for historical reasons and because there's very low activity related to these folders on these repositories. (imho, the main concern with subtrees is about "active" code) |
|
Closing following #22 FYI, all repositories in the "Tasks" stack will be using submodules with similar PR |
This fixes the problems described in:
jrl-umi3218/jrl-cmakemodules#124