Faré wrote:
On Mon, Mar 24, 2014 at 6:30 PM, Faré fahree@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 other implementations. I'd say it is ready to merge.
Your strategy seems reasonable. How about we put into the manual a chapter, towards the end (an appendix, perhaps?) describing the EXPERIMENTAL build-op support, thus putting our users on alert that we reserve the right to change BUILD-OP in ways that break their code.
I don't want there to be a premature lock-in here.
thanks, r