>> So BUNDLE-SYSTEM has been restored, but the comment about its
>> deprecation suggests that we should revisit its arglist to make it
>> useful, if we are not going to remove it.
My "no-operation-initargs" branch, that you (Robert) agreed to merge
after the next release, does away with bundle-system.

>> The function is not documented, and reading the code doesn't help me (as
>> someone who doesn't routinely use bundle ops): it defers to
>> DELIVER-ASD-OP, but that operation is documented as:
>> "produce an asd file for delivering the system as a single fasl"
>> which suggests that it makes a .asd file, and doesn't bundle anything at
>> all.
It uses compile-bundle-op (née fasl-op) to create a single .fasl for
the entire system,
then also creates a .asd file that will load that .fasl file. But
there is no good place to store that .asd file least it overwrites the
source .asd file, and no good place to store the .fasl file besides
the per-implementation fasl cache. The whole interface is lacking, and
is not directly usable as is, though it isn't too hard for users to
write a wrapper that copy or redirect the output where they want it to
be, using deliver-asd-op directly and querying asdf:output-files.
Thus, the function has no purpose and should be removed.

> Afaik bundle-system creates one fasl for a whole system (if monolithic -
> for a system and its dependencies). It may be loaded afterwards with
> simple load. What it lacks is a `:move-here' key parameter or a similar
> mechanism.
The bundle-system function does not accept a monolithic keyword.

> I wouldn't advise to use it, because of an arbitrary decision by Fare to
> break the API contract (by pushing for removal of `make-build' and
> `bundle-system' and promoting `program-op' and `deliver-asd-op') -
> you'll have your api broken with the next or one after next ASDF
> release.
My decision is not arbitrary. Make-build violates ASDF invariants. I
was a clever hack on top of ASDF1, but not a viable design. I will die
soon. I've warned Juan Jo, I've warned you. ECL hackers have had years
to move off it.

An operation class MUST NOT have any instance slots. Please put
component-specific flags in component slots, and global flags in
global variables. Even if far future extensions ever have instance
slots in operation, they shall not be for component-specific flags.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Stop cultural appropriation! Using arabic numbers? Unless an Arab, 3 years
in jail. Using roman letters? Unless a Roman, III years in jail.

Reply via email to