Create nearest possible tree at build and packaging time (excepted thirdparty dependencies)
Closed this issue · 3 comments
Author Name: Souedet, Nicolas (@nsouedet)
Original Redmine Issue: 14378, https://bioproj.extra.cea.fr/redmine/issues/14378
Original Date: 2016-02-16
The idea is to have the less organization differences between build and packaging tree (excepted thirparty dependencies).
This could address following issues:
- As real-bin directory will be created in build tree and bv_env will be called each time a command is used,
It won't be necessary anymore to have a particular call to bv_env in .bashrc file and it will be easier to switch between build trees. - Moreover some commands (bv_packaging_i2bm for instance), needs to be explicitely called through the correct bv_env and this will be always done with this change
- It won't be necessary to create real-bin at packaging time
Original Redmine Comment
Author Name: Cointepas, Yann (@sapetnioc)
Original Date: 2016-02-16T10:02:43Z
It seem that is it not a small change because I guess that it will be necessary to change each installation in @bin@ directory done in CMake files to replace it by an installation in @real-bin@ and a script creation in @bin@.
Otherwise, if we want to use a script to move all executables to @real-bin@ as it is done in packaging, I do not know how to handle the two following issues :
- This would break the Makefiles dependencies.
- How to properly call this script at the end of @make@ ?
And if we modify CMake files, there is another issue :
How to deal with executables that are not built with CMake but installed with pip ?
Therefore, I wonder if it is worth the effort. What is the reason for this change ?
Original Redmine Comment
Author Name: Souedet, Nicolas (@nsouedet)
Original Date: 2016-02-16T10:19:35Z
It was just an idea to deal with the 3 minor issues described above. And it was also to simplify packaging process and also to be in a nearest pack configuration. But, ok, it adds complexity to build steps.
However, I think that binaries could be directly generated in the real-bin directory through cmake variable CMAKE_BINARY_DIR (without breaking make dependencies). And through BRAINVISA_ADD_EXECUTABLE, we could add a custom target to generate bin script that uses bv_env. So I do not think it is a so important change.
You are right that I missed that it is necessary to also generate the scripts for thirdparty executables... But I am not sure that this is well managed today. Because I think that we have a particular case for python interpreter executables... I have to check.