RE: [Quantlib-dev] Full first Linux Port

[Bernd Johannes Wuebben-2]

Hi Enrico,

I hope you used the last Linux port tarball I posted here.
As to  autoconfing the whole thing, feel free to contact
Stephan Kulow <[hidden email]> he may be able to set
the whole thing up in only a couple of minutes. Tell
him I sent you and ask im politely whether he would
mind to invest a few minutes. Stephan is our autmake/autoconf
guru at KDE and I know of to person who is more
knowledgable regarding these tools than him including
the maintainers of automake/ autoconf. This may get
you over some of the hurdles quicker and in a more
rewarding fashion.

Also, there are a number of macros posted regularly that
do the standart C++ library checks that you are looking
for on the respective mailing lists. Not that
it is hard to write those tests, but basicially pretty
much everything should be there already -- it's just a
matter of putting it together.

Bernd



------Original Message------
From: "Enrico Sirola" <[hidden email]>
To: [hidden email]
Sent: December 29, 2000 1:56:59 PM GMT
Subject: RE: [Quantlib-dev] Full first Linux Port


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

- -----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Bernd
Johannes Wuebben
Sent: Monday, December 18, 2000 7:51 PM
To: [hidden email]
Subject: [Quantlib-dev] Full first Linux Port



Attached please find a first full linux port. The tar.gz is really
small so I
don't think I will blow anyone's mailbox by attaching it.  it works
including pythong stuff.

- -- Bernd


- ----------  Forwarded Message  ----------
Subject: Linux Port
Date: Mon, 18 Dec 2000 05:00:15 -0500
From: Bernd Johannes Wuebben <[hidden email]>
To: [hidden email]


Hi,

        I sent nando an initial embryonicGNU/Linux port. Generates makefiles
dynamically, almost everything compiles. More when I have another
five
minutes.

Initial impressions:

        I am unhappy about the heavy use of templates and the stl. Its going
to
bite you on many platforms (guys there is a whole world out there
apart from
Macs and Windows machines...) and the bloat is going to be
considerable.

        Is the license compatible with the GPL? Has someone verified with
Richard?

            We need to talk seriously about the architecture sometime
soon.

        Other than that I think you guys have contributed a very nice start
code
base. Thank you!

Got to run ...
- -- Bernd

- -------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBOkyJG5jf7IY3f+B/EQJEJwCfTzjl4Wkg7CBMfK2dLT/p7kc6dzcAnR0j
gpXUw0AnobCsru0ACudlEEAQ
=ecSZ
-----END PGP SIGNATURE-----