alanruttenberg at gmail.com
Thu Mar 11 13:15:58 UTC 2010
On Thu, Mar 11, 2010 at 8:06 AM, Mark Evenson <evenson at panix.com> wrote:
> On Mar 11, 2010, at 1:53 PM, Alan Ruttenberg wrote:
>> The problem surfaced with what seems to me to be a regression in the
>> use of the abcl-binary-locations system, which puts compiled files in
>> separate directories according to implementation. I'm working on
>> packaging up my application in a single jar. I move the systems inside
>> the jar and then try to load using asdf. Because of the use of
>> :relative, the call to OUTPUT-FILES-USING-MAPPINGS duplicates the
>> leading directory components, and then the compiled file is not found.
> In your usage of ASDF-BINARY-LOCATIONS the system in the JAR does
> not have FASLs, which are compiled somewhere to the local filesystem,
> right? Just packaging the entire ASDF system with FASLs in the JAR
> does work (c.f. the abcl-contrib.jar containing ASDF-INSTALL built
> by the 'abcl.contrib' target). Maybe you could circumvent the usage
> of ASDF-BINARY-LOCATIONS for jars for the time being?
Ok. I'll do that for now.
>> The thing is that with the current setup has it that there is never an
>> :absolute directory. I think this will violate assumptions of programs
>> beyond abcl-binary-locations. I believe the assumption will be that
>> truename will give you something that has an :absolute pathname.
> The assertion that TRUENAME by convention always returns an :ABSOLUTE
> directory component certainly leans the argument towards implementing
> that behavior. We'd have to examine the Zip specification (I assume
> there's a RFC) to see if doing this would be ambiguous for actual
> absolute entries in the jar.
> Once I test loading from OSGi bundles, I'll try to see what's
> blocking ASDF-BINARY-LOCATIONS from working.
Ok, thanks. An also thank you both very much(!) for looking athe OSGi
stuff. I'm completely clueless about how any of that works so I don't
even know where to start.
> "A screaming comes across the sky. It has happened before, but
> there is nothing to compare to it now."
More information about the armedbear-devel