- Bug: In buildCoriolis.py, when multiple projects where given on the command
line, only the latest was processed. Now all projects are processeds.
(in the order given on the command line so watch out!)
- Bug: In buildCoriolis.py, io tool was both declared as belonging to io
and hurricane project. Removed from Hurricane.
- Bug: In buildCoriolis.py, exctract correctly the return status of a
command to return it to the parent process. See Python documentation
about os.wait() & os.waitpid().
- Change: In builCoriolis.py, expand the '~' in the root path if needed.
- Bug: Do not stop if the "--no-cache" option is given but the
CMakeCache doesn't exists.
- Change: <PROJECT>_SEARCH_PATH are put back into the *first* tool of
a project.
- Bug: In HURRICANE_CHECK_MACRO(), the quiet flag was not correctly
implemented. User ARGV instead of argv (case sensitivity!).
- Change: New structure for the installation & CMake system.
* Tools are now grouped in "projects". There are three projects:
1. - IO: Standalones parsers/drivers (IO_USER_TOP, IO_TOP).
2. - Coriolis: Base & digital tools (CORIOLIS_USER_TOP, CORIOLIS_TOP).
3. - Chams: Analogic tools (CHAMS_USER_TOP, CHAMS_TOP).
Each *project* has a two "TOP" environement variables, for
example: IO_TOP and IO_USER_TOP. Thoses variables are the only
ones useds to locate the tool (CMake modules, headers & libraries).
The local path always takes precedence over the global one.
The localisation process occurs in each tool top CMakeLists.txt
where the macro SETUP_PROJECT_PATH is to be defined. There is no
way to put it in a shared includes file as it's the macro precisely
used to locates the includes... You have to call the macro once for
each project you wants to uses:
SETUP_PROJECT_PATHS(IO)
SETUP_PROJECT_PATHS(CORIOLIS)
* In FindTOOL.cmake, supress the <TOOL>_DIR_SEARCH and uses the
<PROJECT>_DIR_SEARCH instead (example: CORIOLIS_DIR_SEARCH).
* buildCoriolis.py modificated according to the new "TOP" scheme.
Jean-Paul Chaput
Damien Dupuis