Hi,
First, I'ld like to point out that yesterday we have unleashed CLN-1.1.1
onto the world. No big changes, but a couple of important bugs were fixed
that do affect GiNaC on non-Intel hardware and on the upcoming GCC-3.0.
Oh, thank you very much for the applause! ;-)
Second, I would like to move the ./cint subdirectory out of GiNaC. The
reason is that Cint is too disappointing right now for GiNaC-cint to be
really useful. I have here a nice list of open bugs that won't go away in
the near future and that make using it a pain in the neck. The main
problem is, however, Cint's portability: it wants to eat your harddisk on
Linux/m68k, it has weird linking bugs on Linux/arm and despite my efforts
to point out to the ROOT folks at Cern that they will be in a hell of a
trouble soon if they don't work on the GCC-3.0 port nothing really happens
on this front. (Try compiling Cint on GCC-3.0: it fails in a very
spectacular way but doesn't even seem to notice so!) The real problem is
of course less the new compiler bug the up-to-date STL. Cint's approach
to STL based on ancient sources by HP definitely won't work much longer.
Bottom line: the intersection of the set of platforms supported by CLN and
GiNaC on the one side and of Cint on the other seems to be quite small.
This makes the current situation a headache for distribution packagers: if
you configure --with-cint you must exactly know your platform, specifying
"Architecture: any" would otherwise work fine for both GiNaC and CLN.
Instead, starting with GiNaC-0.9.0 we'll have a separate package
GiNaC-cint that will be kicked along and updated when need should arise.
Packagers can then throw this at their build-daemons and whatever comes
out will probably `work', but that won't have any side-effects on the
building of the GiNaC library.
Sex, drugs and Unix
-richy.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>