On Tue, Jun 02, 2015 at 02:19:59PM +0200, Ian Hinder wrote:
But not disallowed, right?
Not disallowed right now. They would generate warnings. At some point we
will disallow it.
I don't want old Kranc-generated thorns to fail to compile and need to
be regenerated.
Isn't one of the main points of Kranc-generated thorns that you can
easily regenerate them? I would worry more if we would have tens of
hand-written thorns with these.
Indeed. If you (still) have access to Mathematica. I just don't see the point of deliberately breaking backward compatibility, even in the case where the old behaviour was not in agreement with the documentation. What is the benefit of doing this?
Frank is working on providing shell-script support functions for
There is a ticket (https://trac.einsteintoolkit.org/ticket/1175) and a
wiki page
(https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_external_libraries)
related to this from a while ago.
Good point. However, I don't plan to overhaul the current system right
now. I only want to homogenize it a bit - which in turn should make it
easier later to implement all the changes proposed there.
OK, that is good in any case. I guess you can one-by-one pull out common functions into a library of bash functions or something.
Specifically: I am only looking into the "factoring out common code"
section, and also not all of that (e.g., I leave building to the
scripts, as this usually needs special treatment for each library).
Yes, I had the same thought when reading the wiki page; building is really something that should be customised by the thorn. On the other hand, I think some of the thorns have their own "build.sh" script, and it might make sense for the Cactus library shell function to handle the standard options etc, and call the thorn's build script, rather than having the configure script call the build script (or contain the build commands) in the top-level. But you'll probably get a good feel for the right thing to do as you're doing it.