freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pooma-dev] Re: pooma-dev Digest 23 Jun 2003 12:57:44 -0000 Issue 24


From: Richard Guenther
Subject: Re: [pooma-dev] Re: pooma-dev Digest 23 Jun 2003 12:57:44 -0000 Issue 243
Date: Thu, 26 Jun 2003 20:23:43 +0200 (CEST)

On 23 Jun 2003, Mark Mitchell wrote:

> > Ok, the things I am able to spent time on are:
> > - use autoconf/automake/libtool to get rid of current build system
>
> I'd rather see us avoid automake and libtool, if we can.  I don't think
> we should need automake if we use GNU make, probably.  I'm not sure
> about libtool, but adding libtool to a build process seems to make it
> complex, fragile, and slow almost all of the time...
>
> After all, POOMA is only going to be used on a few real systems these
> days -- not a whole lot of 68K HP-UX boxes running POOMA...

Ok, I can see this makes sense somehow. The only problem I see is building
shared libraries - though I think usage of shared libaries in high
performance computation is very rare. Though, of course, using automake
will help doing dependencies and installation rules. So while I'm in
favour of dropping shared library support (and such libtool), I'd be
rather not willing to miss automake.

> > In this process we're going to loose a lot of the current configure
> > options, also (initially) support for tau, paws, etc. (but cheetah).
>
> Yes, I'm not sure how much people need those things these days, but we
> can add them back with --enable-tau, etc.

Yes. Last time I checked, most of those packages are neither maintained
anymore, nor do they compile on recent compilers/distros.

> > If more people like to work on this, this can be done on a branch, if not,
> > I can try to do this locally in a bk repository.
>
> A branch is probably a good idea.

Yes, I think so, too. Jeffrey?

Richard.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]