- asdf-devel - mailman3.common-lisp.net

[asdf-devel] clisp getuid
by Pascal Bourguignon 08 Feb '10

08 Feb '10

In asdf.lisp downloaded from the web page this afternoon, line 500. With clisp, the package LINUX is available only in special circumstances. (it has to run on Linux, AND the glibc bindings module must have been compiled AND clisp must have been launched with it, usually with -Kfull). So when using the LINUX package on clisp, we must test for it explicitely: #+(and clisp #.(cl:if (cl:find-package "LINUX") '(:and) '(:or))) (defun get-uid () (linux:getuid)) A better alternative is to use POSIX:UID, which is available on a wider range of systems (IIRC, MS-Windows is POSIX too): #+clisp (defun get-uid () (POSIX:UID)) (and similarly for the PID if needed, (POSIX:PROCESS-ID)) -- __Pascal Bourguignon__

2 1

[asdf-devel] A shot at fixing the module dependency bug
by Robert Goldman 08 Feb '10

08 Feb '10

OK, I have committed a first shot at fixing this. However, there is no easy way to have a module update its components upon dependency change but not have a system update its components upon dependency change, because a system is a subclass of module. So my path may not be desirable, or at any rate the community may want to think about it a bit before adopting it. Furthermore, I did the patch as a minimal perturbation to TRAVERSE, which has a structure which I, at least, find somewhat difficult to follow. The structure is one large function with a FORCED variable which holds the plan (sequence of OP . COMPONENT pairs). This large function contains three sub-functions in LABELS that destructively modify the FORCED variable. I think a good case could be made for breaking those sub-functions out (for easier tracing, if nothing else), and having them return values that are appended onto the list, instead of side-effecting. But this is an aesthetic matter, and would also create many problems for understanding the modifications I made, so I did NOT do this. Since these changes seem to me controversial, I did not push my changes into the main repository, but instead added a "module-depends" branch to the common-lisp.net git repository. I hope that this will make the changes easier to assess. Cheers, r

2 1

[asdf-devel] Launchpad bug 502946
by Robert Goldman 07 Feb '10

07 Feb '10

Wrt https://bugs.launchpad.net/asdf/+bug/502946, module is not recompiled if _intra_-system dependency changes, I have spent quite some time groveling over the source code to TRAVERSE, and I believe that this is going to be quite difficult to fix. There are a number of assumptions baked into TRAVERSE, and some complicated uses of a variable scoped over the body of TRAVERSE, together with a number of local functions and a soupcon of unstated assumptions. I'm pretty sure that modules are substantially broken and, in the short term, I would discourage ASDF system designers from using them at all. I have been banging my head on this for at least a working day's worth of hours, and I need someone with whom to discuss the code, either by voice, IM or IRC. Email is not going to be high enough bandwidth. If anyone is interested in this enough to share the pain with me, please drop me a line and we can coordinate. Thanks, r

1 0

[asdf-devel] asdf 1.600
by Faré 04 Feb '10

04 Feb '10

I just released ASDF 1.600 in the official repository. Since my last "official release" 1.502, there is * AOT replacing ABL. AOT allows you to define a set of pathname translations in a configuration file. * Some cleanup of the ECL integration. * *asdf-revision* has been replaced by *asdf-version* * minor updates to tests, documentation I think I did all the major changes I wanted for upgradability and configuration. Now for a round of testing, bug fixes and documentation before I try to push the result as "ASDF 2". You are welcome to try the new functionality and send feedback, remarks, questions. Which glaring bugs would you like to see fix before an official release? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A student who changes the course of history is probably taking an exam.

3 12

[asdf-devel] [PATCH 1/2] Quash style-warnings in the compile-script for tests.
by rpgoldman＠sift.info 04 Feb '10

04 Feb '10

From: Robert P. Goldman <rpgoldman(a)real-time.com> Previously, style warnings in compiling asdf.lisp would cause the test script to fail. Modified to quash style warnings (but not other warnings) during build. --- test/compile-asdf.lisp | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-) diff --git a/test/compile-asdf.lisp b/test/compile-asdf.lisp index 60bca6d..168c189 100644 --- a/test/compile-asdf.lisp +++ b/test/compile-asdf.lisp @@ -4,15 +4,19 @@ (cond ((probe-file "asdf.lisp") (multiple-value-bind (result warnings-p errors-p) - (compile-file "asdf.lisp") + ;; style warnings shouldn't abort the compilation [2010/02/03:rpg] + (handler-bind ((style-warning + #'(lambda (w) + (princ w *error-output*) + (muffle-warning w)))) + (compile-file "asdf.lisp")) (declare (ignore result)) - (cond (warnings-p + (cond (warnings-p (leave-lisp "Testuite failed: ASDF compiled with warnings" 1)) - (errors-p + (errors-p (leave-lisp "Testuite failed: ASDF compiled with ERRORS" 2)) (t (leave-lisp "ASDF compiled cleanly" 0))))) (t (leave-lisp "Testsuite failed: unable to find ASDF source" 3))) - - \ No newline at end of file + -- 1.6.5.3

3 4

[asdf-devel] Bootstrapping asdf
by Robert Goldman 04 Feb '10

04 Feb '10

"The best is the enemy of the good." --- Voltaire There seems to be a strong sentiment from at least part of this mailing list that ASDF loading should be reorganized so that some minimal core functionality is loaded, and more can be loaded on demand. I'd like to go on record as opposing this. I see the arguments for tidiness involved, but I think there are some powerful arguments against doing this: 1. It raises the bar for ASDF novices. Every line we add to a lisp init file is a huge cost, from my point of view. I'd prefer we kept it to (require :asdf). 2. It makes testing more complicated. In order to be confident that code works properly, we will now have to test it in a number of configurations that will grow exponentially with the number of modules to be loaded. If we have a relatively big core, we can get away with one run of the test suite per lisp implementation X platform. 3. Related to 2, it makes development of ASDF system definitions more tricky. Now, in order to write an asdf system definition, you will have to track which modules you have loaded, and which modules the eventual users of your system definition are likely to have loaded. You may have to modify your ASDF system definition so that it forces load of modules. This is deeply undesirable, IMO, since doing this is outside the declarative DEFSYSTEM core of ASDF. 4. It is effort that we do not have in superabundance. There are outstanding ASDF bugs --- simple bugs like tests failing --- that are not getting fixed. An exercise in refactoring and tidiness will take more of the lifeblood away from core development. 5. It will create a revision control system merge hassle. Restructuring means moving stuff back and forth among files. This will neatly foil diff and emerge. I had enough of that back when we moved to git. I still haven't recovered the work I did on implementing clean-op, and backporting from markdown to texinfo was a drag. This last is not critical, if the transition is made in one swift, well-scheduled cut-over. Best, R

3 2

[asdf-devel] LispWorks fix
by Chun Tian (binghe) 04 Feb '10

04 Feb '10

Hi, ASDF I found a typo in LispWorks support code which stops ASDF compiling: diff --git a/asdf.lisp b/asdf.lisp index 3c5dbbd..ad97554 100644 --- a/asdf.lisp +++ b/asdf.lisp @@ -438,7 +438,7 @@ and NIL NAME and TYPE components" ;;; what about VERSION??? #+cmu (cdr (assoc (intern x :keyword) ext:*environment-list*)) #+lispworks - (lispworks:environment-xiable x) + (lispworks:environment-variable x) #+allegro (sys:getenv x) #+gcl Please fix it. --binghe

2 1

[asdf-devel] A dream for ASDF2
by Daniel Herring 04 Feb '10

04 Feb '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 (collect sources, build 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.

3 3

[asdf-devel] Two patches in passing
by Robert Goldman 04 Feb '10

04 Feb '10

I found some cases where the tests could go bad. One where the tests could fail to find asdf.fasl (or equivalent) and one where a style-warning in SBCL could cause the tests to fail. Those are the two messages that should be coming through. I'm not fully sure how to use git send-email yet....

1 0

[asdf-devel] [PATCH] Fix for launchpad bug 516794.
by rpgoldman＠sift.info 04 Feb '10

04 Feb '10

From: Robert P. Goldman <rpgoldman(a)real-time.com> There was code here that caused a style warning because it was checking for the return of safe-file-write-date being NIL, which it could never be. This indicated odd treatment of missing file write dates in operation-done-p. I have revised this. --- asdf.lisp | 55 +++++++++++++++++++++++++------------------------------ 1 files changed, 25 insertions(+), 30 deletions(-) diff --git a/asdf.lisp b/asdf.lisp index 39160ee..edd2d66 100644 --- a/asdf.lisp +++ b/asdf.lisp @@ -799,7 +799,11 @@ to `~a` which is not a directory.~@:>" ;; that's the case, well, that's not good, but as long as ;; the operation is otherwise considered to be done we ;; could continue and survive. - (or (file-write-date pathname) 0)) + (or (file-write-date pathname) + (progn + (warn "Missing FILE-WRITE-DATE for ~S: treating it as zero." + pathname) + 0))) (defun find-system (name &optional (error-p t)) (let* ((name (coerce-name name)) @@ -992,35 +996,26 @@ to `~a` which is not a directory.~@:>" (defmethod input-files ((operation operation) (c module)) nil) (defmethod operation-done-p ((o operation) (c component)) - (flet ((fwd-or-return-t (file) - (let ((date (safe-file-write-date file))) - (cond - (date) - (t - (warn "~@<Missing FILE-WRITE-DATE for ~S: treating ~ - operation ~S on component ~S as done.~@:>" - file o c) - (return-from operation-done-p t)))))) - (let ((out-files (output-files o c)) - (in-files (input-files o c))) - (cond ((and (not in-files) (not out-files)) - ;; arbitrary decision: an operation that uses nothing to - ;; produce nothing probably isn't doing much - t) - ((not out-files) - (let ((op-done - (gethash (type-of o) - (component-operation-times c)))) - (and op-done - (>= op-done - (apply #'max - (mapcar #'fwd-or-return-t in-files)))))) - ((not in-files) nil) - (t - (and - (every #'probe-file out-files) - (> (apply #'min (mapcar #'safe-file-write-date out-files)) - (apply #'max (mapcar #'fwd-or-return-t in-files))))))))) + (let ((out-files (output-files o c)) + (in-files (input-files o c))) + (cond ((and (not in-files) (not out-files)) + ;; arbitrary decision: an operation that uses nothing to + ;; produce nothing probably isn't doing much + t) + ((not out-files) + (let ((op-done + (gethash (type-of o) + (component-operation-times c)))) + (and op-done + (>= op-done + (apply #'max + (mapcar #'safe-file-write-date in-files)))))) + ((not in-files) nil) + (t + (and + (every #'probe-file out-files) + (> (apply #'min (mapcar #'safe-file-write-date out-files)) + (apply #'max (mapcar #'safe-file-write-date in-files)))))))) ;;; So you look at this code and think "why isn't it a bunch of ;;; methods". And the answer is, because standard method combination -- 1.6.5.3

1 0