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."