- A complete sweep of cleanup to suppress allmost all compiler warnings.
* ./hurricane/doc/hurricane:
- New: Documentation cleanup and update, particularly on the new Layer
derived classes.
* ./hurricane/src/hurricane,
./hurricane/src/isobar,
./hurricane/src/viewer:
- New: Creation of new methods, more explicit on DbU. Based on a to/from
naming scheme.
- New: Python support extented to include all objects needed to configure
through python scripts.
- Change: Finally understood what's causing the _XOPEN_SOURCE redefinition.
Basically the Python.h must be included first before any other
include. The type-puned problem will remains still (that is a Python
problem, not our own).
- Change: In DisplayStyle, uses shared_ptr for DrawingStyle instead of
custom made reference count.
- Change: New problem identified with the Python modules: each module seems
to be built as a complete binary, so all the static C++ initializers are
allocated in each module. In particular the C++ tree inheritance is built
for *each* module so we cannot longer uses the typeid() comparisons
across modules... It was used by boost::program_options to perform is
casts with boost::any and was starting throwing exceptions because of
bad casts. program_option was first initialized in "configuration"
first included by PyViewer then in PyCRL (see Utilities.cpp).
A first solution is to re-order the import of Python modules in
stratus1/st_model so that CRL is imported first.
The second is to not not link "configuration" with boost::program_option
as only the binary vlsisapd-conf-editor needs it.
That is a serious problem of which we must be aware and can cause further
strange behaviors.
Debug code used to diagnostic has been kept commented in the sources a
it may be needed again :-(
This behavior do not affect our singletons because they are part of
dynamic libraries that seems to be correctly shared between the various
Python modules.
Jean-Paul Chaput