[asdf-devel] Enforcing pure *.asd files

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Thu Mar 18 22:11:03 UTC 2010


On Thu, Mar 18, 2010 at 10:47 PM, Faré <fahree at gmail.com> wrote:

> What about instead investing in XCVB?
>

As much as I would like to have something simplify my life, it is not my
choice to use one system or another. I was suggesting something that might
help rationalize the current library situation.


> Such enforcement will necessarily introduce backward incompatibility and
> pain,
> which I think goes contrary to the goals of ASDF.
>

I am not talking about something that HAS to be enforced, but that it can be
optional. It is by no means a good coding practice to put things in the
*.asd file that do not belong in it. Promoting this message from the ASDF
development forum is not wrong by itself and need not cause any pain at all
-- a warning message somewhere in the build, explaining the situation of the
libraries in the system does not cause such a panic or disrupture, does it?

I think it should be spoken clearly here about what is expected also from
the ASDF maintainers. Either you envision it as a hack until something
better comes along, or you consider the possibility of gradually evolving
towards something better.


> As to systems that currently use weird ASDF extensions,
> you could either make XCVB's ASDF converter better,
> or just convert these systems by hand.
>

Conversion by hand is not an option. No time and no will on my side to track
all libraries written out there. I also do not believe that it would help
without support on the other side of the line: this should be done by the
developers themselves once they discover that a build system provides some
advantage.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100318/ad1ad278/attachment.html>


More information about the asdf-devel mailing list