[asdf-devel] Workaround (was: adsf/bundle:monolithic-fasl sometimes puts dependent system first in list)

[Dave Cooper]

[I don't know what happened with the formatting in my last note, here
 is the same note word-wrapped with emacs M-q:]


Dear Faré,

 Looks like there is a strange regression, at least on
 acl-9.0-linux-x86 and acl-9.0m-linux-x86:

 The --all-systems file is not being written at all! I get this:

     http://paste.lisp.org/display/136095

 The (asdf:component-depends-on ...)  does look like it gives the
 correct order, though. (What is the canonical function to see the
 list which will be written out by asdf/bundle:monolithic-fasl-op? I
 remember you said it's not really component-depends-on -- so what is
 it again?

 By the way, I just made a branch of github.com/genworks/gendl.git
 called asdf-monofasl-broken which has that extra source/try.lisp file
 and the :component for it in the gendl.asd file, for
 github.com/genworks/gendl.git.

 I tried this on acl-9.0-linux-x86, acl-9.0m-linux-x86, and
 ccl-1.9-f96-macosx-x64.

 Thanks for the work on this so far, please let me know if there is
 anything else I can do.


Regards,

 Dave


P.S. Thanks for the uiop/filesystem:delete-directory-tree, I will use
     it with caution.

P.P.S. Is there a recursive copy-directory? I didn't see one at first
       glance.



On Mon, Mar 18, 2013 at 12:45 AM, Dave Cooper <david.cooper at genworks.com>wrote:

>
> Dear Faré,
>
> * *Looks like there is a strange regression, at least on
> acl-9.0-linux-x86 and acl-9.0m-linux-x86:
>
>  The --all-systems file is not being written at all! I get this:
>
>      http://paste.lisp.org/display/136095
>
>  The (asdf:component-depends-on ...)  does look like it gives the correct
> order, though. (What is the canonical function to see the list which will
> be written out by asdf/bundle:monolithic-fasl-op? I remember you said it's
> not really component-depends-on -- so what is it again?
>
>  By the way, I just made a branch of github.com/genworks/gendl.git called
> asdf-monofasl-broken which has that extra source/try.lisp file and the
> :component for it in the gendl.asd file, for github.com/genworks/gendl.git
> .
>
>  I tried this on acl-9.0-linux-x86, acl-9.0m-linux-x86,
> and ccl-1.9-f96-macosx-x64.
>
>  Thanks for the work on this so far, please let me know if there is
> anything else I can do.
>
>
> Regards,
>
>  Dave
>
> P.S. Thanks for the uiop/filesystem:delete-directory-tree, I will use it
> with caution.
>
> P.P.S. Is there a recursive copy-directory? I didn't see one at first
> glance.
>
>
>
>
> On Sun, Mar 17, 2013 at 11:40 AM, Faré <fahree at gmail.com> wrote:
>
>> Dear Dave,
>>
>> I fixed in 2.32.13 the bug you found with monolithic-fasl-op.
>> It was a subtle bug in dependency propagation,
>> that was ultimately rooted in the incorrect decision of
>> having the monolithic bundle operations inherit from the non-monolithic
>> ones.
>> This imposed contradictory constraints on the code,
>> which prevented it from doing the right thing in all cases,
>> with the current code kind of working in the common case,
>> but not quite in other not-so-uncommon cases, as you discovered.
>>
>> Thanks for your bug report, and my apologies for taking a few days
>> before I sorted it all out.
>>
>> As a bonus, 2.32.12 included a few utilities like
>> delete-empty-directory and delete-directory-tree
>> that should help you get rid of cl-fad.
>>
>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
>> http://fare.tunes.org
>> A competent and self-confident person is incapable of jealousy in
>> anything.
>> Jealousy is invariably a symptom of neurotic insecurity.
>>         — Robert Heinlein, "Time Enough For Love"
>>
>
>
>
> --
> My Best,
>
> Dave Cooper, Genworks Support
> david.cooper at genworks.com, dave.genworks.com(skype)
> USA: 248-327-3253(o), 1-248-330-2979(mobile)
> UK: 0191 645 1699
>



-- 
My Best,

Dave Cooper, Genworks Support
david.cooper at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20130318/0eb07acb/attachment.html>