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é <fah...@gmail.com> wrote: > > On Wed, Mar 30, 2016 at 3:39 PM, Attila Lendvai <att...@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. >
