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

[John H. Hall]

Richard, et al.:
Shared libraries are big deal for the old major customer of POOMA, the 
Blanca Project. Link times with shared libraries were minutes compared 
to hours for static libraries. While a final optimized release might 
not want to rely on shared libraries fro some performance aspect, the 
debug cycle will probably need them. On the SGI's and Q machines almost 
all the system libraries are shared libraries, so I am not really sure 
what impact shared libraries have on the final code performance.
John Hall

On Thursday, June 26, 2003, at 12:23  PM, Richard Guenther wrote:

> 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.