On Tue, Jun 02, 2015 at 04:44:46PM +0200, Ian Hinder wrote:
Indeed. If you (still) have access to Mathematica.
How many thorns are we talking about? If you don't intent to regenerate them, maybe this could be done once, by a script?
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?
It prevents new code from using this. Old thorns cannot be expected to work forever with a changing framework. Leaving old stuff in for ever usually makes code unmaintainable, although I don't know how severe it would be in this case. We didn't intent to make this go away immediately, more like marking it deprecated and generating a warning now, and removing it from a release in a year at the earliest.
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.
That's the hope, right.
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.
Ideally, the build script should only build (since that presumably can be done in parallel with other things). But before that, a library would need to be unpacked and configured, and that's also something that requires some individual treatment.
Frank