ASDF status for 3.1.7 release

[Robert P. Goldman]

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