Hello ASDF developers,
I just upgraded my version of ASDF to 1.661, more or less the latest and greatest.
I would like to know how to turn off the compiler output cache that ASDF now uses.
In the currently available manual (on the web site) there is a mention of variable *centralize-lisp-binaries* and a few other variables that would control that area of ASDF. But *centralize-lisp-binaries* is no where to be found in the current source code. The manual obviously lags significantly behind the evolution of the code...
So how does one turn off the compiler output cache in this new version of ASDF?
Thanks,
Jean-Claude Beaudoin
Oops, the website is out of date. We really ought to fix that.
I just added this FAQ to the manual (in doc/asdf.texinfo):
@subsection ``How can I wholly disable the compiler output cache?''
To permanently disable the compiler output cache for all future runs of ASDF, you can:
@example mkdir -p ~/.config/common-lisp/asdf-output-translations.conf.d/ echo ':disable-cache' > ~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf @end example
This assumes that you didn't otherwise configure the ASDF files (if you did, edit them again), and don't somehow override the configuration at runtime with a shell variable (see below) or some other runtime command (e.g. some call to @code{asdf:initialize-output-translations}).
To disable the compiler output cache in Lisp processes run by your current shell, try (assuming @code{bash} or @code{zsh}):
@example export ASDF_OUTPUT_TRANSLATIONS=/: @end example
To disable the compiler output cache just in the current Lisp process, use (after loading ASDF but before using it):
@example (asdf:initialize-output-translations "/:") @end example
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Statists seek the solution to all human problems in arbitrary political power and bureaucracies above society. They choose to ignore that when they are not all too humans, politicians and bureaucrats are oh so inhuman.
On 3 April 2010 10:39, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
Hello ASDF developers,
I just upgraded my version of ASDF to 1.661, more or less the latest and greatest.
I would like to know how to turn off the compiler output cache that ASDF now uses.
In the currently available manual (on the web site) there is a mention of variable *centralize-lisp-binaries* and a few other variables that would control that area of ASDF. But *centralize-lisp-binaries* is no where to be found in the current source code. The manual obviously lags significantly behind the evolution of the code...
So how does one turn off the compiler output cache in this new version of ASDF?
Thanks,
Jean-Claude Beaudoin
On 4/3/10 Apr 3 -10:16 AM, Faré wrote:
Oops, the website is out of date. We really ought to fix that.
I just added this FAQ to the manual (in doc/asdf.texinfo):
@subsection ``How can I wholly disable the compiler output cache?''
To permanently disable the compiler output cache for all future runs of ASDF, you can:
@example mkdir -p ~/.config/common-lisp/asdf-output-translations.conf.d/ echo ':disable-cache' > ~/.config/common-lisp/asdf-output-translations.conf.d/99-disable-cache.conf @end example
This assumes that you didn't otherwise configure the ASDF files (if you did, edit them again), and don't somehow override the configuration at runtime with a shell variable (see below) or some other runtime command (e.g. some call to @code{asdf:initialize-output-translations}).
To disable the compiler output cache in Lisp processes run by your current shell, try (assuming @code{bash} or @code{zsh}):
@example export ASDF_OUTPUT_TRANSLATIONS=/: @end example
To disable the compiler output cache just in the current Lisp process, use (after loading ASDF but before using it):
@example (asdf:initialize-output-translations "/:") @end example
Since output translation was not the default in Classic ASDF, would it be reasonable to make this more user-friendly? I.e., add something like
(asdf:disable-output-translations)
as an alias for
(asdf:initialize-output-translations "/:")
On Sun, 4 Apr 2010, Robert Goldman wrote:
Since output translation was not the default in Classic ASDF, would it be reasonable to make this more user-friendly? I.e., add something like
(asdf:disable-output-translations)
as an alias for
(asdf:initialize-output-translations "/:")
The complexity isn't much different to the user. Assuming this is a stable API, I'd rather document "the right way" than introduce another function. On the other hand, if asdf:i-o-t is in any way unstable, it would be nice for casual users to have a stable asdf:d-o-t.
As a side question, I've read through the latest manual and am having trouble figuring out how to approximate the default behavior of asdf-binary-locations with centralize-binaries set nil. In short, the fasl for a lisp file was put in a :IMPLEMENTATION subdirectory next to the source file.
For LibCL, I'd either like to keep that behavior or store all fasls to a central subdirectory. Either way, the goal is to allow simple OS X-style upgrades by simply deleting the old LibCL tree. Any suggestions for the :output-translations directive?
Thanks, Daniel
On 4/4/10 Apr 4 -9:20 PM, Daniel Herring wrote:
On Sun, 4 Apr 2010, Robert Goldman wrote:
Since output translation was not the default in Classic ASDF, would it be reasonable to make this more user-friendly? I.e., add something like
(asdf:disable-output-translations)
as an alias for
(asdf:initialize-output-translations "/:")
The complexity isn't much different to the user. Assuming this is a stable API, I'd rather document "the right way" than introduce another function. On the other hand, if asdf:i-o-t is in any way unstable, it would be nice for casual users to have a stable asdf:d-o-t.
I am sorry; I absolutely disagree. The novice user, who just wants his or her fasl files dropped down next to the source files, in the way Classic ASDF used to do it, and in the way COMPILE-FILE does it, should not be required to figure out what the "/:" above means. This is a very major backward compatibility loss.
I would in order prefer the following:
1. disable output-translations by default.
2. provide a clean disable-output-translations.
I would far prefer that, as in the old days, the novice user would encounter output-translations only if he or she needs them (e.g., is an oddball like me running multiple lisp implementations).
Best, Robert
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
- provide a clean disable-output-translations.
Done in 1.665: (asdf:disable-output-translations)
I would far prefer that, as in the old days, the novice user would encounter output-translations only if he or she needs them (e.g., is an oddball like me running multiple lisp implementations).
See above.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Always remember that you are unique. Just like everyone else.
On 4/4/10 Apr 4 -9:50 PM, Faré wrote:
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
Ah. I see. Then is there a "disable output translations for MY files, and do the right thing with system installed code"?
I agree with you about people who use clisp and ecl, multiple SBCLs, ACL + SBCL, but I'm not convinced that those people are common enough that we should arrange the world around them. I am, after all, one of these people and I am a user of ASDF-BINARY-LOCATIONS.
However, there are a lot of people out there who use only a single CL. Indeed, I work with them, both in my company and out.
- provide a clean disable-output-translations.
Done in 1.665: (asdf:disable-output-translations)
Given your remarks above, is this going to do something bad, by wrecking system-installed code?
What I would like us to be able to offer is something that will feel like classic ASDF (or, for that matter, COMPILE-FILE) --- if you have foo.lisp, you get foo.fasl (or whatever), by default, next to foo.lisp. If you don't want that, we have something way better to offer you in asdf-output-translations. But if you /do/ want that, how do you get it?
Thanks,
r
Robert Goldman rpgoldman@sift.info writes:
On 4/4/10 Apr 4 -9:50 PM, Faré wrote:
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
Ah. I see. Then is there a "disable output translations for MY files, and do the right thing with system installed code"?
I agree with you about people who use clisp and ecl, multiple SBCLs, ACL
- SBCL, but I'm not convinced that those people are common enough that
we should arrange the world around them. I am, after all, one of these people and I am a user of ASDF-BINARY-LOCATIONS.
However, there are a lot of people out there who use only a single CL. Indeed, I work with them, both in my company and out.
Even if they work only with one implementation, why do you think they want their source directories be cluttered with fasls which just plays bad with RCS, grep, tar, and other tools?
-T.
On 4/5/10 Apr 5 -9:53 AM, Tobias C. Rittweiler wrote:
Robert Goldman rpgoldman@sift.info writes:
On 4/4/10 Apr 4 -9:50 PM, Faré wrote:
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
Ah. I see. Then is there a "disable output translations for MY files, and do the right thing with system installed code"?
I agree with you about people who use clisp and ecl, multiple SBCLs, ACL
- SBCL, but I'm not convinced that those people are common enough that
we should arrange the world around them. I am, after all, one of these people and I am a user of ASDF-BINARY-LOCATIONS.
However, there are a lot of people out there who use only a single CL. Indeed, I work with them, both in my company and out.
Even if they work only with one implementation, why do you think they want their source directories be cluttered with fasls which just plays bad with RCS, grep, tar, and other tools?
With all due respect, I don't care why they want this. I just know that they do. They want ASDF to just build systems for them and get out of their way and not complicate their lives. They want the configuration of ASDF to be handed to them on a platter.
I have weaned many of these people from just using big files full of
(compile-file-if-needed ...) (load ...)
They do not want to learn ASDF any more than I want to learn autoconf just to build a piece of software, and I respect that. I don't fix my car, I just drive it.
cc by default drops .o files right in front of you. People seem to live with that just fine.
I used a symbolics for many years happily without fussing with the location of the binaries.
I think it's great that we have output-translations, and I have gradually spread their use, but I want to make the first spoonful of ASDF go down easily. This, IMO, means that if someone tells you to use ASDF, and gives you an ASDF system definition, you can load it and run. You don't have to learn the whole thing, you just do it, and it acts pretty much like a smarter replacement for COMPILE-FILE, just like make is a smarter replacement (from a user standpoint) for cc.
I also want the first spoonful of ASDF2 go down easily. This, IMO, means that it should behave as much like ASDF 1 as possible, modulo bug fixes, when it's turned on. Fiddling with the buttons and dials should give you all kinds of new goodness, but the /obligation/ to fiddle with buttons and dials should be avoided.
There are far too many FMs out there, and we cannot expect users to R them! If they want a new feature (if they want to install a shiny SBCL next to their copy of an old one, and need to keep the fasls from being confused, or if they like to have all their fasls together somewhere), great, they will read the manual. If they just want to load a system, they shouldn't have to and, in any case, we should not expect them to.
OK, so should the default be no translation, except for software that is system installed?
I still think that the cache being on by default is ultimately simpler, least surprising, and more useful.
Mario's analogy with make is OK to a point, but ASDF differs very much from make, too. And with multiple implementations, making a "don't map" default can really get in the way. Especially as I'd like to promote some portability and "test with multiple architectures/implementations" style. I do catch more bugs thanks to SBCL, CLISP, ECL, etc.
Can anyone setup a google questionnaire or some other survey?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I walked a mile with Pleasure, / She chattered all the way; But left me none the wiser, / For all she had to say. // I walked a mile with Sorrow / And ne'er a word said she; But, oh, the things I learned from her / When Sorrow walked with me! — Robert Browning Hamilton
On 5 April 2010 16:05, Robert Goldman rpgoldman@sift.info wrote:
On 4/5/10 Apr 5 -9:53 AM, Tobias C. Rittweiler wrote:
Robert Goldman rpgoldman@sift.info writes:
On 4/4/10 Apr 4 -9:50 PM, Faré wrote:
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
Ah. I see. Then is there a "disable output translations for MY files, and do the right thing with system installed code"?
I agree with you about people who use clisp and ecl, multiple SBCLs, ACL
- SBCL, but I'm not convinced that those people are common enough that
we should arrange the world around them. I am, after all, one of these people and I am a user of ASDF-BINARY-LOCATIONS.
However, there are a lot of people out there who use only a single CL. Indeed, I work with them, both in my company and out.
Even if they work only with one implementation, why do you think they want their source directories be cluttered with fasls which just plays bad with RCS, grep, tar, and other tools?
With all due respect, I don't care why they want this. I just know that they do. They want ASDF to just build systems for them and get out of their way and not complicate their lives. They want the configuration of ASDF to be handed to them on a platter.
I have weaned many of these people from just using big files full of
(compile-file-if-needed ...) (load ...)
They do not want to learn ASDF any more than I want to learn autoconf just to build a piece of software, and I respect that. I don't fix my car, I just drive it.
cc by default drops .o files right in front of you. People seem to live with that just fine.
I used a symbolics for many years happily without fussing with the location of the binaries.
I think it's great that we have output-translations, and I have gradually spread their use, but I want to make the first spoonful of ASDF go down easily. This, IMO, means that if someone tells you to use ASDF, and gives you an ASDF system definition, you can load it and run. You don't have to learn the whole thing, you just do it, and it acts pretty much like a smarter replacement for COMPILE-FILE, just like make is a smarter replacement (from a user standpoint) for cc.
I also want the first spoonful of ASDF2 go down easily. This, IMO, means that it should behave as much like ASDF 1 as possible, modulo bug fixes, when it's turned on. Fiddling with the buttons and dials should give you all kinds of new goodness, but the /obligation/ to fiddle with buttons and dials should be avoided.
There are far too many FMs out there, and we cannot expect users to R them! If they want a new feature (if they want to install a shiny SBCL next to their copy of an old one, and need to keep the fasls from being confused, or if they like to have all their fasls together somewhere), great, they will read the manual. If they just want to load a system, they shouldn't have to and, in any case, we should not expect them to.
On 4/5/10 Apr 5 -11:58 AM, Faré wrote:
OK, so should the default be no translation, except for software that is system installed?
I still think that the cache being on by default is ultimately simpler, least surprising, and more useful.
I'd go with "ultimately simpler" and "more useful," but not "least surprising," at least not for an ASDF Classic user!
I would feel more confident shipping with the translation on by default if it didn't seem like it was complicated to turn it off. If I understand you correctly, one cannot simply turn it off, one must somehow grok how it handles system installed s/w to understand how to disable it correctly. If I'm wrong, please correct me.
Based on that (possibly erroneous) premise, it sounds like turning it on from off is an easier operation than turning it off from on, which reinforces my desire to see it off by default.
However, if there's a very simple single function, with no arguments (no need to understand, or even copy anything out of the DSL for A-O-T) that gives asdf classsic behavior, that would dissolve a lot of my objections.
I see four families of users I'd like to see supported with minimal-effort configurations:
1. ASDF classic users who want ASDF classic + bugfixes (at least initially);
2. ASDF-BINARY-LOCATIONS users ditto, with no centralized binaries
3. As 2, but with centralized binaries.
4. People who want the latest and greatest, with sensible default output relocations.
I would prefer that all of these be able to configure minimally, and in CL only, so that people who are currently using their CL init files as configurations will be on solid ground. Note that I'm not saying that the new configuration arrangement is bad, just that people should be able to work their way up to it with baby steps.
Is this reasonably achievable without crippling people who want all the good new stuff?
Mario's analogy with make is OK to a point, but ASDF differs very much from make, too. And with multiple implementations, making a "don't map" default can really get in the way. Especially as I'd like to promote some portability and "test with multiple architectures/implementations" style. I do catch more bugs thanks to SBCL, CLISP, ECL, etc.
Can anyone setup a google questionnaire or some other survey?
I'm reluctant to do this, because it seems to me that the people least likely to answer are the ones most relevant to the survey.
Best, r
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I walked a mile with Pleasure, / She chattered all the way; But left me none the wiser, / For all she had to say. // I walked a mile with Sorrow / And ne'er a word said she; But, oh, the things I learned from her / When Sorrow walked with me! — Robert Browning Hamilton
On 5 April 2010 16:05, Robert Goldman rpgoldman@sift.info wrote:
On 4/5/10 Apr 5 -9:53 AM, Tobias C. Rittweiler wrote:
Robert Goldman rpgoldman@sift.info writes:
On 4/4/10 Apr 4 -9:50 PM, Faré wrote:
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
Ah. I see. Then is there a "disable output translations for MY files, and do the right thing with system installed code"?
I agree with you about people who use clisp and ecl, multiple SBCLs, ACL
- SBCL, but I'm not convinced that those people are common enough that
we should arrange the world around them. I am, after all, one of these people and I am a user of ASDF-BINARY-LOCATIONS.
However, there are a lot of people out there who use only a single CL. Indeed, I work with them, both in my company and out.
Even if they work only with one implementation, why do you think they want their source directories be cluttered with fasls which just plays bad with RCS, grep, tar, and other tools?
With all due respect, I don't care why they want this. I just know that they do. They want ASDF to just build systems for them and get out of their way and not complicate their lives. They want the configuration of ASDF to be handed to them on a platter.
I have weaned many of these people from just using big files full of
(compile-file-if-needed ...) (load ...)
They do not want to learn ASDF any more than I want to learn autoconf just to build a piece of software, and I respect that. I don't fix my car, I just drive it.
cc by default drops .o files right in front of you. People seem to live with that just fine.
I used a symbolics for many years happily without fussing with the location of the binaries.
I think it's great that we have output-translations, and I have gradually spread their use, but I want to make the first spoonful of ASDF go down easily. This, IMO, means that if someone tells you to use ASDF, and gives you an ASDF system definition, you can load it and run. You don't have to learn the whole thing, you just do it, and it acts pretty much like a smarter replacement for COMPILE-FILE, just like make is a smarter replacement (from a user standpoint) for cc.
I also want the first spoonful of ASDF2 go down easily. This, IMO, means that it should behave as much like ASDF 1 as possible, modulo bug fixes, when it's turned on. Fiddling with the buttons and dials should give you all kinds of new goodness, but the /obligation/ to fiddle with buttons and dials should be avoided.
There are far too many FMs out there, and we cannot expect users to R them! If they want a new feature (if they want to install a shiny SBCL next to their copy of an old one, and need to keep the fasls from being confused, or if they like to have all their fasls together somewhere), great, they will read the manual. If they just want to load a system, they shouldn't have to and, in any case, we should not expect them to.
Hi,
Faré fahree@gmail.com writes:
Mario's analogy with make is OK to a point, but ASDF differs very much from make, too. And with multiple implementations, making a "don't map" default can really get in the way. Especially as I'd like to promote some portability and "test with multiple architectures/implementations" style. I do catch more bugs thanks to SBCL, CLISP, ECL, etc.
How about a special
asdf:*output-translation-defaults*
that controls the default, and have that default to "classic behavior"? then people who do not want the "don't map" default (like you) just need to add the line
(setf asdf:*output-translation-defaults* ...
or something like that to their lisp's startup file to get what they want.
Mario.
"Tobias C. Rittweiler" tcr@freebits.de writes:
Even if they work only with one implementation, why do you think they want their source directories be cluttered with fasls which just plays bad with RCS, grep, tar, and other tools?
As a datapoint: because it has been like this for ages, and normally people do not seem to be bothered too much by it.
Also, i'd like to remark that this is a default that works out of the box most of the time.
Mario
On 5 April 2010 14:12, Robert Goldman rpgoldman@sift.info wrote:
On 4/4/10 Apr 4 -9:50 PM, Faré wrote:
I would in order prefer the following:
- disable output-translations by default.
I think we can't do that, because of things like system-installed source code and users who use both clisp and ecl (that share the .fas suffix) or i386 and x86-64 SBCL (that share the .fasl suffix), etc.
If a novice wants to know where the fasls are, I prefer to give the explanation once than to give plenty of explanations with as many special rules.
Ah. I see. Then is there a "disable output translations for MY files, and do the right thing with system installed code"?
I could add a keyword argument to disable-output-translations for that -- and the question remains, which should be the default?
Note to Mario: I tend to prefer a functional interface where you call a function to initialize the complete state of the output-translation facility, to an interface with plenty of special variables that you must all set or reset, save or restore, to set the state of the facility.
I agree with you about people who use clisp and ecl, multiple SBCLs, ACL
- SBCL, but I'm not convinced that those people are common enough that
we should arrange the world around them. I am, after all, one of these people and I am a user of ASDF-BINARY-LOCATIONS.
I believe that people who don't care don't care and shouldn't care: a user-cache does automagically the right thing for all of them.
However, there are a lot of people out there who use only a single CL. Indeed, I work with them, both in my company and out.
But do they care that the fasls be in current directory rather than a central cache?
The only break cases I can imagine are: * user removes directory, recreates it from an archive with pre-modified source being backdated, asdf reuses fasls from modified source unless the user explicitly clears the cache.
* user keeps installing and deleting new software of software, trying or upgrading CL implementations, moving stuff around, yet has a machine with a small disk. The cache grows big and needs to be explicitly cleared.
I'd tend to think either case would require a user who is enough of an expert to learn to clear the cache, and to be tempted to use multiple implementations at which point the cache is a good default.
- provide a clean disable-output-translations.
Done in 1.665: (asdf:disable-output-translations)
Given your remarks above, is this going to do something bad, by wrecking system-installed code?
Probably. If you do that, you are probably avoiding system-installed code. Or there should be two versions of disable, one that takes precedence and one that doesn't.
Reminds me that the current code uses a stable-sort according to the length of the directory component of the source pattern...
What I would like us to be able to offer is something that will feel like classic ASDF (or, for that matter, COMPILE-FILE) --- if you have foo.lisp, you get foo.fasl (or whatever), by default, next to foo.lisp. If you don't want that, we have something way better to offer you in asdf-output-translations. But if you /do/ want that, how do you get it?
(disable-output-translations) will do that.
I think the main question is which is a better, more newbie-friendly and future-proof default.
I lean the central cache way. But I can be convinced otherwise.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Democracy is a religion too. It's the worship of jackals by jackasses. — H. L. Mencken
On Tue, 6 Apr 2010, Faré wrote:
I lean the central cache way. But I can be convinced otherwise.
I agree that central caching is a good idea, but think a single central cache is overly simplistic. Traditional unix systems have /bin, /usr/bin, and /usr/local/bin -- each with its purpose -- as well as miscellaneous other directories in the PATH. MS boxes have a similar thing with c:\windows... and c:\progra~1...
- Daniel
On 6 April 2010 04:58, Daniel Herring dherring@tentpost.com wrote:
On Tue, 6 Apr 2010, Faré wrote:
I lean the central cache way. But I can be convinced otherwise.
I agree that central caching is a good idea, but think a single central cache is overly simplistic. Traditional unix systems have /bin, /usr/bin, and /usr/local/bin -- each with its purpose -- as well as miscellaneous other directories in the PATH. MS boxes have a similar thing with c:\windows... and c:\progra~1...
Well, you can configure
Speaking of Windows, I'm pretty sure the "central cache" currently does the wrong thing on implementations where drive letters are interpreted as host or device instead of directory (as in e.g. cygwin). Which implementations are they? Can someone using one of them come up with something that works? I opened this: https://bugs.launchpad.net/asdf/+bug/556217
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] To explain the unknown by the known is a logical procedure; to explain the known by the unknown is a form of theological lunacy. — David Brooks, "The Necessity of Atheism"
Faré has added asdf:disable-output-translations, so the original question is solved.
I'm still trying to figure out the following.
On Sun, 4 Apr 2010, Daniel Herring wrote:
As a side question, I've read through the latest manual and am having trouble figuring out how to approximate the default behavior of asdf-binary-locations with centralize-binaries set nil. In short, the fasl for a lisp file was put in a :IMPLEMENTATION subdirectory next to the source file.
For LibCL, I'd either like to keep that behavior or store all fasls to a central subdirectory. Either way, the goal is to allow simple OS X-style upgrades by simply deleting the old LibCL tree. Any suggestions for the :output-translations directive?
Thanks, Daniel
(asdf:enable-asdf-binary-locations-compatibility :centralize-binaries nil)
Can you test and report whether it works?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Reality must take precedence over public relations, for Mother Nature cannot be fooled. — R.P. Feynman
On 5 April 2010 04:16, Daniel Herring dherring@tentpost.com wrote:
Faré has added asdf:disable-output-translations, so the original question is solved.
I'm still trying to figure out the following.
On Sun, 4 Apr 2010, Daniel Herring wrote:
As a side question, I've read through the latest manual and am having trouble figuring out how to approximate the default behavior of asdf-binary-locations with centralize-binaries set nil. In short, the fasl for a lisp file was put in a :IMPLEMENTATION subdirectory next to the source file.
For LibCL, I'd either like to keep that behavior or store all fasls to a central subdirectory. Either way, the goal is to allow simple OS X-style upgrades by simply deleting the old LibCL tree. Any suggestions for the :output-translations directive?
Thanks, Daniel _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
-
Daniel Herring -
Faré -
Jean-Claude Beaudoin -
m_mommer＠yahoo.com -
Robert Goldman -
Tobias C. Rittweiler