[Users] release status
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).
>> 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
Size: 819 bytes
Desc: Digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20170619/cb0066bc/attachment.bin
More information about the Users