asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] Subsumed README.source-registry into the manual
by Robert Goldman 13 Mar '10

13 Mar '10

I had to do this quite quickly, so the import was a bit rough and ready. BTW, I think the two configuration chapters should be pushed UP in the manual, and the object model should be pushed DOWN below them, since the former is for advanced users, but the latter is for in-depth programmers. The current flow is pretty awkward. But I don't have time for that today. cheers, r

1 0

[asdf-devel] ASDF 2 confusion
by Nikodemus Siivola 13 Mar '10

13 Mar '10

The manual talks about both ASDF-VERSION and "ASDF 1" vs "ASDF 2", but doesn't relate the two. Is anything post 1.600 "ASDF 2"? Might I suggest to drop the "ASDF 2" language from the manual in that case -- because it is just confusing. Cheers, -- Nikodemus

1 0

[asdf-devel] Git merge practice
by Nikodemus Siivola 13 Mar '10

13 Mar '10

Please, when merging branches that will end up in the repo, merge INTO master before pushing, as opposed to merging master to feature branch. Example: commit 4158a412c3ed75c027a47996b52057e812e8b5ed Merge: 50e98da... 9b5eaf9... Author: Francois-Rene Rideau <fare(a)tunes.org> Date: Fri Mar 12 10:51:42 2010 -0500 Merge branch 'master' of http://common-lisp.net/project/asdf/asdf Conflicts: README.asdf-output-translations This is would be more informative if it had instead been Merge branch 'some-feature' of http://common-lisp.net/project/asdf/asdf </end of sermon> Cheers, -- Nikodemus

1 1

[asdf-devel] output-translations documentation
by Robert Goldman 13 Mar '10

13 Mar '10

I have not been using the output-translations (because my colleagues are still using "classic" asdf), and so I'm not familiar with the configurations. I have gone over the readme, but I was left with (at least) a few questions: 1. There's no description of what happens if you have left the environment variable unset and you don't have any of the magical files. What would happen if you were to do (asdf:initialize-output-translations) ? What would you get? [The README says "Indeed, few people use and customize these packages; these people are experts who can trivially adapt to the new configuration." but I don't think that this division of the world into "ASDF by itself" and "Wizards" is accurate. All my colleagues, and several people we have worked with are people who DO use but DO NOT customize ASDF-BINARY-LOCATIONS. That is, they are not Wizards, but they do use A-B-L. So I'm very much interested in what happens to such people.] 2. Related to the above, can you provide a recipe for getting the same behavior as ASDF-BINARY-LOCATIONS? A-B-L was quite easy to use --- if you just turned it on, it would split your fasls by implementation type. Is there a simple set of commands --- that can be put entirely into one's lisp init file --- that would replicate this behavior? 3. In the readme I see: (ensure-output-translations) checks whether output translations have been initialized. If not, initialize them. This function will be called before any attempt to operate on a system. If your application wants to override the provided defaults, it will have to use the below function process-output-translations. but there is no mention of process-output-translations anywhere else in the file. What I'd like to do: In general, I'd like to beef up the discussion of "all lisp" configurations of output-translations. I ask because although a long-term unix user, I'm not a big fan of the way linux has led to a multiplication of configuration files in different locations. I like to have all my lisp configuration either in my init file (clinit.cl or .sbclrc) or in a file explicitly loaded therefrom. I have a lot of trouble managing the complexity of interacting configuration files, so I simply avoid them. This stands me in good stead with my colleagues --- we stick a file in a project repository, near the root, that configures everything (including the ASDF *central-registry*), using local information (including *load-truename*) and we are happier with that than having to wrangle scattered configurations. Indeed, I typically have a set of functions, one for each project, that will configure my lisp appropriately. I will usually start a lisp session then, before anything else, execute one of these functions, which will populate ASDF:*central-registry* and set any necessary contextual variables, etc. The ability to do this is particularly important for my firm because we are a contract research house (a "soft money lab"), and so are often concurrently working on several large systems. We must be able to switch contexts (including sometimes multiple, inconsistent versions of a single library), and having multiple different configuration files scattered around makes project context switches very difficult. For similar reasons, to the maximum extent possible, I try not to configure with environment variables, because it's difficult to control their flow. E.g., it's difficult to switch from project to project while in a long-running emacs session if unseen environment variables affect the system. Similarly, I find it hard to predict what will happen if I change them in one terminal window --- did that get propagated to that emacs process or not? So I'd like to make sure I capture into the manual --- not to the exclusion of all else, of course! --- a set of instructions that will be useful for people like me, who will want to configure everything in their lisp and only the absolute minimum externally. cheers, r

2 8

[asdf-devel] notes on the manual discussion of asdf-output-locations
by Robert Goldman 12 Mar '10

12 Mar '10

1. The manual in several places uses version 1.6 as synonymous with 1.600. But if we are to eat our own dogfood and comply with our own version-satisfies function, 1.6 ~= (1 6) while 1.600 ~= (1 600) and 600 > 6 I have fixed the references I found. 2. In a couple of places the manual suggests making files with names of the form nn-filename. We should explain what is the purpose of these integers. 3. I don't want to repeatedly have to translate stuff out of read me files. I have put all of the information from the README.asdf-output-locations file into the manual, and killed the README so that it doesn't become an attractive nuisance. I have pushed these changes. I'd encourage everyone to please have a peek at the new manual. Question: I have been assuming that everyone on the list is capable of opening this up in emacs and using texinfo mode to format this to their choice of HTML, info, and pdf. If that is not true, please let me know; it should be possible to put a formatted copy on the ASDF web page for people who are interested in screening the documentation. Best, R

2 2

[asdf-devel] revising asdf manual
by Robert Goldman 12 Mar '10

12 Mar '10

The section 8/9 merge was easy. The section 7 (where does asdf write its files?) one is going to be more difficult. It turns out that this stuff is discussed in THREE locations: 1. The "configuring ASDF chapter; 2. Section 7 3. README.asdf-output-translations. Getting those three merged sensibly is going to be a bit more work than I'd hoped. I'm inclined to start by having the configuration chapter just crossref to section 7, and merge all the stuff into section 7. Then we can figure out how to reorganize things. I think we should probably update this to restore some one-paragraph "here's how you turn it on with a minimum of fuss" introduction. Regrettably, I don't see how that's possible with the full, heavyweight new configuration procedure. Cheers, r

2 1

[asdf-devel] texinfo documentation
by Faré 11 Mar '10

11 Mar '10

>> I can't find my way through the texinfo documentation. Too much manual >> section management. Could we be using something nicer? ReST? Exscribe? >> Gary King's CL-Markdown? > > Texinfo is standard and the toolchain is available to everyone. > > CL-Markdown has a big dependency chain, and a brittle one. > > If you use emacs, it will take care of all of the manual section > management: Texinfo > Update every node, Texinfo > Node..., Texinfo > > Create menu.... Similarly, emacs will take care of building for you, to > a number of different formats. > > So far, I'm pretty much the only one editing the manual. I promise to > stop if the format changes. > I understand. If you do the section work or walk me through it on IRC, I can do the filling the blanks for specifying how ASDF computes pathnames from module names, and what is or isn't portable to use. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The revolution will be won, not, as the authoritarians would claim, when the last political boss is hanged with the bowels of the last state propagandist, but, as the libertarians know, when the ever-repeated attempts to lure people into subservience are systematically greeted with laughter and drowned in ridicule by free men who are well-armed both physically and intellectually.

2 2

[asdf-devel] Loading asdf.lisp fails on Lispworks 6.0
by Yves Vandriessche 11 Mar '10

11 Mar '10

Loading the latest asdf.lisp ;;; hash - 7e34af2cdcb62c007ac4751bbbff543dd7d117ba In Lispworks 6.0 yields the following error: > > CL-USER 1 > (load "~/Desktop/asdf") > ; Loading text file /Users/yvdriess/Desktop/asdf.lisp > > Error: Symbol "ENVIRONMENT-XIABLE" not found at all in the LISPWORKS > package. > 1 (continue) Make a new symbol. > 2 Try loading ~/Desktop/asdf again. > 3 Give up loading ~/Desktop/asdf. > 4 Try loading another file instead of ~/Desktop/asdf. > 5 (abort) Return to level 0. > 6 Return to top loop level 0. > > Type :b for backtrace or :c <option number> to proceed. > Type :bug-form "<subject>" for a bug report template or :? for other > options. > > ASDF 2 : 1 > :b > Call to ERROR > Call to CERROR > Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 1 LOAD) > Call to LOAD > Call to EVAL > Call to CAPI::CAPI-TOP-LEVEL-FUNCTION > Call to CAPI::INTERACTIVE-PANE-TOP-LOOP > Call to MP::PROCESS-SG-FUNCTION An older version of asdf.lisp still works though, $Revision: 1.118 $

2 1

[asdf-devel] A dream for ASDF2
by nuntius＠strider2.example.org 11 Mar '10

11 Mar '10

Tobias C. Rittweiler wrote: Re: [asdf-devel] Is this necessary in this form? Re: ASDF 1.501 > Isn't asdf-output-locations somewhat like a CL pendant to `make install' > if you squint your eyes? > > Shouldn't that be an integral part of ASDF? Exactly yes and absolutely no. Not necessarily in that order. My issue is that there is a great similarity; this similarity is driven by a need inherent in the use of libraries; but ASDF (due to history) has certain things absolutely backwards. There are many users that a build system must support. - developers do incremental compiles - maintainer creates a release (builds sources, docs, etc. into a self-contained archive) - maintainer checks that the release actually builds, cleans, installs, etc. - user or system integrator configures the release for local needs - the release is compiled (often into a separate directory or on a separate computer) - the release is tested (before install) - the release is installed (often to a read-only space, as root, or into a temporary directory that will be archived for distribution) - the release is loaded (often without sources) - the release is uninstalled ASDF needs a coherent story for the person doing each of these jobs. Instead, the current model lumps most everything into a single "load-op", and there is no principled way to perform or configure each of the above phases separately. My biggest concern with the recent changes is that they build a big scaffold that institutionalizes a design in need of fundamental changes. Some parts of .asd files may need incompatible changes; but I think most uses are completely upgradeable. However, I do not think the recent ASDF proposals will be. I would like the ASDF architecture to look something like - bootstrap a few (self-contained) core utils using a special install sequence (simple COMPILE, test, and install scripts) - ASDF uses LOAD to pull these in; as each loads, more functionality becomes available (aka SBCL boostrap). - All other packages can now be built with the full ASDF. - (optional) ASDF may upgrade itself without the bootstrap sequence. ASDF features I would like: - Standard way to pass configuration options to ASDF for building a specific system. For example, ASDF should let me configure which compression backend cl-pdf uses, and ASDF should write these choices to file for me. This should be a replayable config file that can be modified for reconfiguration, or read in for compilation and install. I should be able to have several builds at once, each with a different set of choices. - Standard options for each system. For example, a popular one might allow ASDF to autorecompile fasls when the sources change. Another would be an install prefix. Another is to modify the installed system name (e.g. add version info; asdf-1.5 would load the ASDF package, version 1.5). Another to enable the system config cache (below). - Generic configuration cache, independent of use. In other words, a simple configuration format where I can set key/value pairs. Some of which may happen to control ASDF source locations, others may control ASDF output locations, yet others may be defined by end-user ASDF files. This cache should have three levels, one for the sysadmin, one for the user, and one for inside the system configuration area (usually the source tree). Compare the autoconf site configuration mechanism. http://www.gnu.org/software/autoconf/manual/html_node/Site-Configuration.ht… - ASDF compile/install spits out a system.fasl. Semantically, loading this causes the entire library to be loaded. On some CL's, it might simply be the concatenation of the compiled source files; on others, it might LOAD them all in order. The above is a long-enough list for today. I think it covers most of the bases. These things aren't problems I'm creating; they are lessons I have gleaned from GNU autotools and other build systems. Whenever ASDF takes a shortcut, we have issues. For example, "" # We still need to find a way to precompile libraries # Because asdf is now taking care of placing the fasl file in the correct place, we cannot remove fasls for a specific implementation or library, so we nuke them all. Not optimal. "" - http://pvaneynd.livejournal.com/133491.html These are part of the standard autotools procedure; they represent a couple use cases from the first list above. Later, Daniel P.S. Here's a draft response I penned for an earlier post Subject: Re: [asdf-devel] ASDF 1.501 > Next, comes a similar revamp of ASDF-BINARY-LOCATIONS configuration. > Or maybe a wholesale replacement of ABL with something that's simpler > and configured in a way similar to source-registry? What do YOU think? What do I really think? Its great that ASDF is getting some TLC, but the whole "register the sources" thing is fundamentally flawed. >From the end-user's perspective, the whole purpose of a "defsystem" (henceforth library loader) is to get one or more packages into the running lisp.

2 1

[asdf-devel] Error when loading asdf.lisp: Package "LINUX" does not exist
by alberich 11 Mar '10

11 Mar '10

Hello, I'm using opensuse 4.3 and clisp 2.44.1 When trying to load asdf.lisp (git-version), load breaks with the error message that package "LINUX" did not exist (line 500). I could, however not find a file defining a "linux" package. After commenting out ; #+clisp (defun get-uid () (linux:getuid)) loading asdf.lisp works fine. Still, when trying to load asdf-install.lisp, load stops with the error message that the file SB-POSIX did not exist. Any ideas? Regards Alain Berich

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel