asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

make-build
by Faré 21 Jul '17

21 Jul '17

Dear Daniel, if you're willing to fork ASDF over make-build, would putting a make-build compatibility function back in ASDF make you adopt the upstream version again? I have an implementation for it at the end of https://gitlab.common-lisp.net/asdf/asdf/merge_requests/34 but I'd need you to provide some more test case (a simple one exists somewhere in some old version in git). There were many fixes in ASDF 3.2 and 3.3, including ECL-specific fixes, compared to the 3.1.7 from which you forked, and forking is just more work for both you and us. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Social peace will come when the socialists will love the poor more than they hate the rich. — Not Golda Meir

2 1

source-registry configuration
by Greg Bennett 20 Jul '17

20 Jul '17

Running under Linux Mint 18.1 64 bit, and either ccl or sbcl Apologies, I'm afraid I have made a mess of configuring the path to some .asd files. I believe that items 3,4,6,7,8 of Section 8.1 Configurations do not exist. I believe I have used item 5 as in Section 4.1 Configuring ASDF to find your systems. In ./config/common-lisp/source-registry.conf.d I once created the file gb-lisp.conf containing the single line (:tree "/home/gwbennett/asdf-tests") <- no trailing / instead of (:tree "/home/gwbennett/asdf-tests/") <- trailing / I have since replaced that file with source.conf holding just the line (:tree "/home/gwbennett/asdf-tests/") In the asdf-tests directory there is a file gb-a.asd and associated lisp files When I try (asdf:load-system "gb-a") I get (under ccl64 Version 1.11-r16812M) > Error: Is a directory : #P"/home/gwbennett/asdf-tests" > While executing: CCL::MAKE-FILE-STREAM, in process listener(1). Under sbcl 1.3.18 I get an analogous message, always pointing to the same pathname. If I remove the .conf file completely, restart either lisp, retry the load-system, the error persists. Some how I seem to have managed to get the incorrect specification squirreled away in asdf's memory in a way which survives not just restarting either lisp, but restarting linux too. What in the world have I managed to do ? More usefully, how do I undo it ? Thanks for advice and assistance. Cheers Greg Bennett

3 2

read-depend branch is ready for another review...
by Robert Goldman 17 Jul '17

17 Jul '17

Tests now passing on all implementations, and there's been substantial clean-up. Likely the first two commits on this branch should be merged with the plan branch directly, since they don't have anything to do with read dependencies per se. Then we could move on to reviewing (and then squash-merging) read-depends. Cheers, r

2 9

relocate/locate fasl files
by Greg Bennett 17 Jul '17

17 Jul '17

2 1

Updated read-depends branch
by Robert Goldman 10 Jul '17

10 Jul '17

Incorporated some of Fare's suggestions and also improved the testing.

1 0

the new read-depends branch is pushed
by Robert Goldman 30 Jun '17

30 Jun '17

This is a solution that seems to work well enough to be reviewed for merging.

2 1

Problem with adding input files...
by Robert Goldman 30 Jun '17

30 Jun '17

Recording the included files (from read-file-form and read-file-line) has so far failed to solve the problem of ASDF missing updates to the included files. I could use a little advice here. Running the test I have pushed, I tried tracing asdf/action:action-up-to-date-p. It is not called during the second invocation of (asdf:load-system "test-include") So at the moment I do not see how the flow of control works to decide whether or not it is necessary to redo the DEFINE-OP. And maybe DEFINE-OP isn't the operation that should be re-triggered by changes to the system definition file or included files? Is the right place for these new dependencies on included files DEFINE-OP or PREPARE-OP? thanks, r

2 7

Possible incompleteness in INPUT-FILES for DEFINE-OP
by Robert Goldman 30 Jun '17

30 Jun '17

I think I may have stumbled on an incompleteness in this method. Here's the test case: 1. Define a system. S1, with a version loaded from a version file; 2. Load S1 into session. 3. Hack hack hack. 4. Bump S1's version number in the version.lisp-expr file 5. Load S2 that depends on new version of S1. As far as I can tell, ASDF is simply checking the .asd file, not S1-version.lisp-expr, to see if it's stale. So my load in step 5 is failing. This is, I believe, because S1-version.lisp-expr is not in the set of INPUT-FILES for S1's DEFINE-OP. It's a little unsettling to change this on the fly, but I think the right thing is probably to push the version.lisp-expr file onto a set of ancillary dependencies when it's read. If this sounds right, I'll stick this in as a ticket, and try to find where we could inject a fix. Best, r

3 8

Random ASDF component question
by Robert Goldman 29 Jun '17

29 Jun '17

Sorry to bother you, but why is it that the BUILD-OPERATION is attached to COMPONENT instead of SYSTEM?

2 1

Re: Testing Quicklisp with ASDF
by Anton Vodonosov 26 May '17

26 May '17

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel