[asdf-devel] prepare-op
Faré
fahree at gmail.com
Mon Dec 17 22:42:20 UTC 2012
On Mon, Dec 17, 2012 at 2:19 PM, Christophe Rhodes <csr21 at cantab.net> wrote:
> Zach Beane <xach at xach.com> writes:
>
>> Faré <fahree at gmail.com> writes:
>>
>>> OK, this is now committed as of ASDF 2.26.21 and POIU 1.29.3.
>>> It's slightly smaller, it's much cleaner, and it all works.
>>> I hope I have not broken users — please test.
>>>
>>> Casualties of the cleanup were :feature and :if-component-dep-fails.
>>> They were just horrible things.
>>
>> FYI, the sb-rotate-byte contrib in SBCL uses :if-component-dep-fails.
>
> What is the correct way now to indicate that a file is part of a system,
> but should only be compiled if a given feature is present?
>
It appears that the SBCL contrib SB-ROTATE-BYTE uses :IF-COMPONENT-DEP-FAILS.
In the spirit of not breaking everyone's existing SBCL installation,
I have implemented *limited* compatibility with :IF-COMPONENT-DEP-FAILS
in ASDF 2.26.27, sufficient to cover the usage observed in the wild.
The restrictions are as follows:
(a) Only the :ignore behavior is implemented.
:try-next (which is a misnomer since it tries all) is seen as :ignore.
It is not possible to directly reproduce :try-next behavior in ASDF 2.27.
If you want to fail when none of some features is present,
you should explicitly use somewhere in your system:
#-(or foo bar baz) (error "unsupported implementation")
(b) I only support :IF-COMPONENT-DEP-FAILS for dependencies on COMPILE-OP,
which is what the only known (to me) users use.
Please report any occurrence of a different usage pattern in the wild,
if possible before release 2.27 (which I target around Christmas).
:IF-COMPONENT-DEP-FAILS is still strongly deprecated,
though its current pattern of use will still work:
(:module "foo" :if-component-dep-fails :ignore
:components ((:file "x86-64-vm" :in-order-to
(compile-op (feature :x86-64)))))
For legacy compatibility, I recommend either using the like of
#+(and sbcl x86-64) (:file "x86-64-vm")
unless you insist on making the file part of the system object,
as per Christophe's legitimate requirement.
Going forward, when ASDF 2.27 becomes widespread,
I recommend the future use of
(:file "x86-64-vm" :if-feature (:and :sbcl :x86-64))
Note only that
(a) :if-feature allows for boolean combinations of features
with :and :or :not, unlike :if-component-dep-fails;
(b) dependencies on a :if-feature component are automatically removed
if removes when the component has been disabled by lack of feature;
(c) the component still part of the component tree,
which will make Christophe happy;
(d) :if-feature does not involve multi-level special-case complexity
in the traverse algorithm to invalidate the patent meaning of the graph,
which makes *me* happy.
There will be a feature #+asdf2.27 in case it is useful to detect
the availability of the massively refactored ASDF internals.
I apologize for the temporary breakage,
but I suppose that's what testing before release is all for.
Thanks a lot for bearing with me, thanks a lot to Xach for your prompt feedback,
and thanks to stassats for quickly fixing SB-ROTATE-BYTE in SBCL HEAD
(which retrospectively is not needed anymore - my apologies for the make work).
PS: Only semi-relatedly, there is now a new generic function:
RESOLVE-DEPENDENCY-COMBINATION (COMPONENT COMBINATION ARGUMENTS)
called when (COMBINATION . ARGUMENTS) appears as the specification
of a dependency to COMPONENT, so you can extend the dependency language.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Common Lisp makes it easy for you to grow your own language; however, it
makes it difficult for that language to be the same as anyone else's.
More information about the asdf-devel
mailing list