<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 12, 2016 at 9:26 AM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Apr 11, 2016 at 7:15 PM, Mark Cox <<a href="mailto:markcox80@gmail.com">markcox80@gmail.com</a>> wrote:<br>
> On Sun, Apr 10, 2016 at 12:32 AM, Faré <<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>> wrote:<br>
</span><div><div class="h5">>> The intended way to use ASDF in your case would be to use two or more<br>
>> systems, that may be defined in the same .asd file (using the / syntax<br>
>> to name a secondary system: roan, roan/core, roan/sqlite, etc.) or<br>
>> separate .asd files (using - or . as a separator).<br>
><br>
><br>
> I like this suggestion because it lets the user decide what is to be built.<br>
><br>
> It won't scale though.<br>
><br>
> This is an excerpt from the help message of ImageMagick's configure script:<br>
>   --disable-openmp        do not use OpenMP<br>
>   --enable-opencl         enable OpenCL support<br>
>   --without-threads       disable threads support<br>
>   --without-bzlib         disable BZLIB support<br>
>   --with-x                use the X Window System<br>
>   --without-zlib          disable ZLIB support<br>
>   --without-dps           disable Display Postscript support<br>
>   --without-fftw          disable FFTW support<br>
>   --without-fpx           disable FlashPIX support<br>
>   --without-djvu          disable DjVu support<br>
>   --without-fontconfig    disable fontconfig support<br>
>   --without-freetype      disable Freetype support<br>
>   --without-raqm          disable Raqm support<br>
>   --with-gslib            enable Ghostscript library support<br>
>   --with-gvc              enable GVC support<br>
>   --without-jbig          disable JBIG support<br>
>   --without-jpeg          disable JPEG support<br>
>   --without-lcms          disable lcms (v1.1X) support<br>
>   --without-openjp2       disable OpenJP2 support<br>
>   --without-lqr           disable Liquid Rescale support<br>
>   --without-lzma          disable LZMA support<br>
>   --without-openexr       disable OpenEXR support<br>
>   --without-pango         disable PANGO support<br>
>   --without-png           disable PNG support<br>
>   --with-rsvg             enable RSVG support<br>
>   --without-tiff          disable TIFF support<br>
>   --without-webp          disable WEBP support<br>
<br>
</div></div>Quite on the contrary, it's the C configure and make system that<br>
clearly doesn't scale.<br>
<br>
If you're writing Lisp code to be used from the Lisp REPL, just define<br>
something a system that autoloads functionality on demand.<br>
<br>
If you're sadly creating an application, just dump everything — why<br>
would you leave anything out? Actually, use a protocol that helps you<br>
dump a single multicall binary for all the applications of your user.<br>
<br>
And if you're building a small image for an embedded target, well,<br>
then have you build script include exactly the systems you want.<br>
<br>
In any case, this kind of "configuration" can and should be part of<br>
your "application build script", that calls ASDF, but that ASDF<br>
doesn't have to care about.</blockquote><div><br></div><div>Right. I see the flaw in my argument. Decisions are being made at the wrong time.</div><div><br></div><div>My example actually highlights your point.</div><div><br></div><div>Thanks for taking the time to correct me.</div><div><br></div><div>Mark</div></div></div></div>