evenson at panix.com
Thu Mar 11 13:06:33 UTC 2010
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?
> 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.
"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