Re: resolution of symlinks in asdf

Christophe Rhodes <[email protected]> wrote:

>> Kevin Layer <[email protected]> writes:
>> 
>> > I added an option for getting around this behavior, :resolve-symlinks.
>> > The changes are backward compatible--no existing program will break
>> > due to the additional option.
>> >
>> > Attached is a diff -u with respect to 1.97.  Can someone on the commit
>> > list do the deed?
>> 
>> This may be expedient, but I don't think it makes sense conceptually:
>> the location that the binary files end up at is not a property of the
>> system, 

By definition it is a property of the system--the defsystem macro
itself indirects through symbolic links.

Furthermore, as far as I'm concerned, it is a property of any system
that is built as part of ACL, and we have many that are not.

>> it is a property of the site policy: as you have in fact
>> implicitly observed by the fact that your contractor presumably had a
>> working system, but when integrated in your site's filesystem it
>> didn't do what you wanted.
>> 
>> I don't know whether this is possible or not, but I think that what
>> should happen is that your site with the symlink farms should define
>> output-files methods in your site init files to place the binaries in
>> appropriate places. 

At Franz there are no such thing as "site init files".  20 years ago
we found that running different environments from our customers
resulted in real bugs not being found.  As a result, we have no site
init files.

>> (It may, of course, be that there isn't enough
>> information around by the time the output-files method runs to put
>> them in the right place, in which case we'll need to talk again.)

I don't see how this could work.  The only pathname stored by the
defsystem macro (unless passed in by the user, not the case here) has
been resolved through a symlink.  The information about the original
symlink is lost.

Kevin