Full first Linux Port

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Full first Linux Port

Ferdinando M. Ametrano-2
Bernd replied to a message nobody received since the author (Enrico) posted
it to the defunct quantlib-dev list.

I attach the original message here.

I'm back at work, I will take a look at the SourceForge status, I hope they
fixed at least some problem.

ciao -- Nando

==========

From: "Enrico Sirola" <[hidden email]>
Subject: RE: [Quantlib-dev] Full first Linux Port

Hi,
thanks a lot for your work. I'm working to "autoconfiscate" the whole
beast in these days, and the job is nearly finished. Actually, i have
a bunch of working Makefile.am and a configure.in who generates
(using libtool) the static and shared libraries and the python stuff.

There are some things to do/decide:
1) do the quantlib users prefer to have a single configure.in who
    generates all the stuff, python included?
2) The configure.in works and generates the right makefiles for
    a gnu/linux with gcc 2.95.2 and a recent libstdc++, but we need
    more serious checks nonstandard for c++ stuff (missing headers,
    things not in namespace std etc etc)
3) In my opinion, we should consider to use autotools to generate the
    *source* of the python<->c++ wrapper only, and to use distutils
    to create the python binary package (i've tried it on QL and it
seems
    to work quite well). This seems to have the drawback
    that we should come out with two packages: a
    pyQuantLib<foo>.[src|bin].tgz
    and a QuantLib<foo>.[src|bin].tgz. The "src" of pyQuantLib should
    contain the source of the wrapper and should require that you have
    QuantLib headers and shared library installed, while the bin
package
    is a final user ready-to-install package who requires the shared
library
    of quantlib only.
    In the meantime, i think we should provide a QuantLib-dev package
    (for those who would like to use the library for their
applications
    in c++) containing a compiled shared and static quantlib and the
    quantlib headers.
4) does any1 have some experience about libtool's version numbering?
We
    should agree on am policy for that too.
5) any volunteer to build .rpm? and .deb? In my opinion these could
be
    important for the linux world.

I didn't commit the autoconfiscated stuff yet becouse there aren't
checks in the configure.in, but let me know if you would like to try
it
(anyway, i think i should finish it for next week)

Ah, by the way, happy new year! :-)
enri