Project

General

Profile

Logged in as brainvisa
Watch Actions

Task #14378

open

Create nearest possible tree at build and packaging time (excepted thirdparty dependencies)

Added by Souedet, Nicolas over 8 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
brainvisa-cmake
Start date:
16/02/2016
Due date:
% Done:

0%

Estimated time:

Description

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

Actions #1

Updated by Souedet, Nicolas over 8 years ago

  • Subject changed from Create nearest possible build tree at compile time and packaging time (excluding thirdparty dependencies) to Create nearest possible tree at build and packaging time (excepted thirdparty dependencies)
Actions #2

Updated by Cointepas, Yann over 8 years ago

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 :

  1. This would break the Makefiles dependencies.
  2. 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 ?

Actions #3

Updated by Souedet, Nicolas over 8 years ago

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.

Actions #4

Updated by Souedet, Nicolas over 8 years ago

Ok, I checked and today it is done for all thirparty executables installed in the bin directory

Actions #5

Updated by Riviere, Denis over 6 years ago

  • Target version set to brainvisa-4.7
Actions #6

Updated by Riviere, Denis over 5 years ago

  • Category set to brainvisa-cmake
Watch Actions

Also available in: Atom PDF