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
when defining rule<minSpacing, nWell, active>
and then rule<minSpacing, nWell>
in technology file
the first rule was ever return even if techno.getRule(minSpacing, nWell) was called.
JP need to check if it the 'static variable bug' still occurs
Note that in openChams I added SimulModel support, it has not yet been tested, and driver does not support it.
- 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.
- New: More thorough type checking of parameter's type while setting/
getting.
- New: In Parameter, callback mechanism (trimmed down Observer pattern)
to uses whenever Qt signal/slots are not used. This is needed to
maintain data coherency througout the software.
* 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)
- access to Sizing object in Circuit object (method getSizing())
- now driver is deterministic since it sorts names in alphabetical order (cannot use name's id since names are destroyed when converted to hurricane and then recreated before drive but with totaly unknow/uncontroled ids)
- 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.
libraries gets installed in "lib64" instead of "lib".
buildCoriolis.py sets automatically LIB_SUFFIX for cmake.
coriolis2.spec modificated to uses lib64 on 64 bits.
- Change: In the CMakeLists.txt, in all the install commands remove all
the leading "/" as they prevents the CMAKE_INSTALL_PREFIX to be took
into account. It was nevertheless working because buildCoriolis.py was
using DESTDIR which is prepended anyway.
* ./goodies:
- Change: In buildCoriolis.py, no longer uses the DESTDIR but instead
CMAKE_INSTALL_PREFIX.
Name, Rule, Arule and Techno objects has been ported, so it is possible to read a dtr xml file from disk to get a techno and then rules' values.
DTRException object still need to be ported.
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: <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.
- OpenChamsException to cleanly throw errors (and not cerr -_-)
- New Schematic object to parse&drive schematic section in xml file
- Lots of checks on node properties
CHANGES:
- directly returns reference on objects' maps/vectors to skim through them (instead of begin/end iterators)
Damien Dupuis
Jean-Paul Chaput