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.