[Developers] GetComponents URL include
knarf at cct.lsu.edu
Fri Apr 9 16:30:31 CDT 2010
On Fri, Apr 09, 2010 at 02:33:54PM -0500, Erik Schnetter wrote:
> This concerns one of the missing features I mentioned earlier. Some
> thorns don't build of some machines, e.g. if PAPI is not installed or
> the OpenSSL library does not build.
Do you really want to put that logic into GetComponents? Simfactory
already contains a lot of machine-specific information and sounds to me
like the right place to put this into. GetComponents on the other hand
should not depend on simfactory.
> Here are the features I would like:
> 1. When checking out Cactus for the first time (as e.g. per the
> Einstein Toolkit instructions), there should be as few steps as
> possible. If GetComponents can handle urls on the command line, then
> one does not need to check out a thorn list by hand.
That is right - and that command line should not be too long, e.g. it
should not contain too many thorn lists and aim for just one.
> 2. Have a way to check whether a thorn list in a local file is
> outdated, either automatically, or via a special command.
Do you think that this would be important? If an URL was used for a
checkout on the command line a second similar call will retrieve the new
file with any possible changes anyway. If an URL was used in an INCLUDE,
it will also get the new version and use it. Because of the small size
of thorn lists there is essentially no time/space/bandwidth difference
between downloading a new file and checking for a new version.
> 3. Assemble thorn lists from pieces, and select or remove thorns from
> thorn lists. This may be combined with user preferences, for example
> "I want these additional, private thorns as well", or "these thorns
> don't work on this platform", or "leave out all Carpet thorns".
Assembling thorn lists from pieces is what INCLUDE does. Removing thorns
would be another issue, especially if you want to do that dependent on
the machine. I would suggest to do that not in GetComponents since it
does not hurt to fetch thorns which do not work on a particular machine,
but to put this into something like simfactory which already knows about
machine configurations. Simfactory could contain lists of thorns which
do not work on a particular machine and disable them at build-time by
changing the thorn list that is used to build the configuration, not the
original thorn list used to obtain the thorns.
This has also the advantage that a checkout of a thorn list done on a
machine where thorn A does not work would still contain thorn A so that
the checkout can be rsynced to another machine where thorn A does work.
One example would be a workstation where PAPI is not installed. If I use
a thornlist with a PAPI thorn it would be checked out, regardless if it
works there or not. Otherwise an rsync (like simfactory does) to another
PAPI-enabled machine would suddenly miss the PAPI thorn.
> 4. I'm also looking for "complete this thorn list by adding all
> missing thorns, or telling me which implementations are missing. This
> probably requires a master thorn list for reference.
Not only this. As soon as you talk about 'implementations' this is
Cactus-specific and also requires parsing of the relevant .ccl files. I
agree that this would be nice to have, but this is not within the scope
> The master thorn
> list could be constructed automatically by GetComponents, or would be
> collected from all existing thorns.
It should be constructed from existing thorns, or an existing thorn
list. I don't see how GetComponents would help here other than being
called with the resulting, complete thorn list to actually get those
> 5. Everything (except checking out / updating) must work even if I
> don't have a network connection.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20100409/251a8b13/attachment.bin
More information about the Developers