Unfortunately, the build went south for me at the first introduction of the precompilation into the build, so stable never happened for me. TBH, I would suggest the building happen outside the ASDF repository entirely. Scripting isn't part of the ASDF objective, so I think having a scripting engine that one installs separately would make a lot of sense. The ASDF build tools are like bundling building of bash together with the"make" tool's build and maintenance. That said, even if the build tools were restructured, I wouldn't use them. They have been too rickety for me. They have failed one too many times, and I'm not going back. I am also unwilling to learn a new scripting framework, especially one under active development. Sorry, but she'll scripting for me isn't broken enough for me to enter into the project of developing a new alternative to perl and python. My active research is in other fields. I'd be interested to see what you all come up with, but right now I have other priorities. Best, R
On Mar 30, 2016, at 16:30, Faré <fahree@gmail.com> wrote:
On Wed, Mar 30, 2016 at 3:39 PM, Attila Lendvai <attila@lendvai.name> wrote:
The warts are mostly related to bootstrap issues when you're modifying asdf itself.
i don't see the whole problem, but maybe the bootstrap script could check out the latest stable tag/branch into the build/ tmp directory, and compile asdf-tools while inside that asdf repo state? That's a possibility. I kind of wanted basic functionality to work even when git is not present though, for cases where e.g. a tarball is used, or a rsync/scp of the checkout onto a test machine.
My compromise of "build asdf-tools while you know you have a stable asdf" seemed good to me, but admittedly it's a cognitive burden on other maintainers, too.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Luck occurs when preparedness meets opportunity.