- New: Support for tarball directly from the user checkout (--user-tarball).
- New: Full parametrization through a "build.conf" file.
- Change: Uses user-defined exceptions to terminate.
- New: guessOs() now detect FreeBSD 8.
* ./bootstrap/coriolisEnv.py,
./bootstrap/coriolis2.sh:
- Bug: 'lib64' instead of '64' under Linux.
- New: guessOs() now detect FreeBSD 8.
- Change: Remove support for Coriolis 1. No more --v2 option either, Coriolis2
selected by default. Python paths also set by default.
- Bug: In ./cmake_modules/FindBootstrap.cmake, fix small message display
typos. No 'IN LISTS' in forach call. Force variable lookup in
SEARCH_SETUP_DIR in foreach summarizing the search path.
- Change: For the setup_sysconfdir() boostrap/cmake macro uses the
CMAKE_INSTALL_PREFIX to guess where we are being installed.
Should be more reliable than any *_TOP environment variable.
* ./bootstrap:
- Change: In builCoriolis.py, detect not only when the X_TOP is not
sets but also when it's sets to an empty value. In either case
gives priority of the X_USER_TOP over the X_TOP.
- New: "debian" directory holding the paraphernalia needed to create a
Debian/Ubuntu package.
- New: In buildCoriolis, add a Debian packaging method.
- Change: In coriolis2.spec, the build/install procedure now makes uses of
the top-level Makefile.
- Change: In FindBoostrap, detection of the distribution type. Finally not
needed but kept here, just in case. Based on "lsb_release".
- Change: In FindPythonSitePackages, simplificate the detection of the Python
site-package directory. No longer on-the-fly generate a python script.
- New: coriolisEnv.py, little helper script to setup the environment.
- New: Icon & desktop entry for Linux (doesn't work yet).
- Bug: In FindLEFDEF, uses LIB_SUFFIX to find libraries on 64 bits systems.
- Change: FindLEFDEF moved here from crlcore.
- Change: In FindLEFDEF, when LEF/DEF is not found sets the include and
library pathes to the empty chain "" instead of NOTFOUND which prevents
usage in derived CMakeLists.
- New: In buildCoriolis.py, support for the distribution patch.
The distribution patch do some customizations needed for the distribution.
- Change: In coriolis2.spec.in, support for patch, include starter
documentation. Do not prepend %{buildroot} to CORIOLIS_TOP environment
variables.
- Change: In coriolis2.spec.in, now do a install "in system", that is
under /usr witch configuration in /etc. Create a patch file to
sets up accordingly the pathes in configurations files.
- Change: More accurate detection of the qt version based on distribution
recognition (%{rhel} & %{fedora}).
- 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.
- New: In buildCoriolis.py, support to build rpm packages (in user's "rpm"
directory).
- Added: coriolis2.spec.in for rpm building. Install under /opt/coriolis2.
This spec files has the particularity to also buildup a binary tarball
of the compiled & installed files, this avoid a second complete build
stage. The tarball is put into "rpm/SOURCES".
- 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.
- New: In buildCoriolis.py, adds a "--rm-build" option which removes the
tool's build directory before building it. A very crude way to ensure
that nothing obsolete form a previous build will gets in the way...
- 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.
- an easy way to run pharos
- supports several technologies
- show/hide a console that catch all pharos' outputs
- supports settings to save technologies / directories
PLEASE update your script.
You only have to update the script (no compilation needed) and verify that your easyChams program points to this updated script.
Jean-Paul Chaput
Damien Dupuis