[Users] release status

Frank Loeffler knarf at cct.lsu.edu
Mon Jun 19 17:24:42 CDT 2017

On Mon, Jun 19, 2017 at 02:19:24PM -0500, Roland Haas wrote:
>I wouldn't say that. I would hope that the majority of users does not
>have to build OpenMPI from scratch. Mostly because that only barely
>works (eg does not put mpirun into PATH so that simfactory's run
>scripts do not work).

True enough.

>>  I don't want to go that way. If we do, I would vote to
>> add those to LIBS already in simfactory, and add to the release notes
>> that if you happen to use the debian (or also redhat I believe)
>> optionlists on something else than Linux, you better remove those.
>I thought this must work without simfactory? Adding them to the SF
>files is of course an option (obviously only the ones for Linux).

Yes, it should work without simfactory, but I would vote to do this, for 
those that are most likely going to be use for Linux. So, we must 
mention this in any case, but can say that if you happen to use one of 
those (pretty likely, even if not using simfactory itself), then this 
already has been done for you.

>> If we don't include the linux-query (perl) code in the release, I
>> also think we shouldn't include at all, but instead properly fix the
>> library list. We can query the library after it has been built. All
>> we need to do is to make it possible to tell Cactus about those.
>I would include it. I don't expect the Cactus build system to be
>re-written anytime soon (because there are pressing issues that eg
>prevent us from running on Stampede so no one can use their allocation
>on one of the few remaining US resources).

True. On this topic: who of those that actually want to use their 
allocation on stampede is actively working on this problem?

>Also we already have may open
>issues with the ExternalLibraries and their build scripts. It would be
>good to close some of those first before we open up new issues.

Some of those could be solved by this. Wasn't there at least one other 
library that potentially, but not always, pulled in other dependencies?

I don't disagree about the amount of work and also not about the not 
very high priority though.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20170619/cb0066bc/attachment.bin 

More information about the Users mailing list