system component does not exist in boost 1.33
!!!!! Merci de ne commiter AUCUN changement dans vlsisapd tant que Jean-Paul et moi n'avons pas résolu les problèmes de bibliothèques statiques !!!!!!
undefined reference to `boost::system::get_system_category()'
symptoms that boost_system was not used at the linking phase
at least on my system (mac OSX leopard with apple gcc and boost 1.43.0)
solution: add the dependency
- Library linking: there must not be "target_link_library()" for libraries,
only when building binaries. Avoid clashes between static module
or class variables, and strange reinitialisation of those variables.
- Change: Boost is now always linked staticly.
* agds :
- all agds object now belong to AGDS namespace
- 'Gds' has been removed from all filenames
* cif
- all cif objects now belong to CIF namespace
- 'Cif' has been removed from all filenames
* dtr
- minor modifications in CMakeLists.txt since Boost Python is now used by other driver & parser
ADDS
* agds :
- new python module
* cif
- new python module
* doc
- brand new doxygen documentation with
global presentation
cif format (driver)
agds format (driver)
links & contacts
* examples
- examples files in C++ and Python for cif & agds drivers (others will follow)
- Change: adopt a tree layout compliant with the UNIX FHS.
* includes under TOP/include/coriolis2.
* shared datas under TOP/shared/coriolis2.
* docs under TOP/share/doc/coriolis2.
* configuration under TOP/etc/coriolis2
* ./crlcore:
- Change: In Environment, comply to the new tree layout, search configuration
files under TOP/etc/coriolis2/.
* ./knik:
- Change: In flute, comply to the new tree layout, get the "POW*.dat" files
from TOP/share/coriolis2/flute-2.4.
Since there is a new project that need to parse DTR xml file we've decided to set a standalone parser.
This parser will be extended with a python API (I'm gonna have a look at boost ^^)
- 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.
Damien Dupuis
Jean-Paul Chaput