[asdf-devel] Branches to merge (I hope)
fahree at gmail.com
Tue Mar 25 09:08:52 UTC 2014
On Mon, Mar 24, 2014 at 6:30 PM, Faré <fahree at gmail.com> wrote:
>>> * build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
>> This one I would rather postpone until after the next release. Getting
>> it into use would require even MORE modifications to the manual, and
>> manual updates are already delaying everything.
>> The need for a short name isn't enough of a requirement to cause us to
>> eagerly change the main entry point into ASDF loading.
> I'd like to convince you to let me merge in the branch anyway,
> for the following reasons:
> * The ability to designate operations with strings is good,
> and makes defsystem-depends-on more useful, even without make
> * This is new functionality that doesn't interfere with anything,
> and therefore isn't a backward compatibility issue;
> then we can use #+asdf3.1 to depend on it.
> On the other hand, if we merge it after, we'll have to wait for
> #+asdf3.2 or so.
> * You don't actually have to modify the manual now
> (and/or I can do the update),
> much less make it the "main entry point" into ASDF loading
> (I'm backing away from that claim).
> But I would like the functionality in to be able to rely on it
> being present.
branch build-op looks like it passes all tests, and in addition to the above,
includes a refactoring of bundle.lisp to merge ecl and mkcl support
and have mkcl follow the same image-op and program-op semantics as
I'd say it is ready to merge.
On the other hand, branch fare-3.1 (which also merges branch
standard-syntax, and is experimental)
has a weird weird failure on allegro that I cannot explain at all, in
something is forcing a rebuild of the required-system.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Does artillery violate the natural rights of the target? I would say: the
entire *purpose* of artillery is to violate the natural rights of the target.
— Mencius Moldbug
More information about the asdf-devel