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
Hm. On a little more thought, it occurs to me that these version-defining files can't be normal dependencies, because they aren't loaded like other files, they are included.
Hm. So they only affect computing whether or not a system definition is up-to-date -- they aren't proper dependencies. That's unfortunate, because it adds a special case.
No, you're right that files from :read-file-form and :read-file-line perfectly fit as INPUT-FILES for DEFINE-OP. I haven't given any thought on whether it's easy or hard to properly inject them as results of INPUT-FILES.
NB: I don't have much cycles for ASDF at the moment, but I will gladly review patches or fix urgent bugs.
PS: What do you think about releasing ASDF 3.3 after next month, just taking steps to avoid escalating from WARNING to STYLE-WARNING until next release?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When a pamphlet was published entitled "100 Authors Against Einstein", Einstein retorted "If I were wrong, one would be enough."
On 6/26/17 Jun 26 -10:07 AM, Faré wrote:
No, you're right that files from :read-file-form and :read-file-line perfectly fit as INPUT-FILES for DEFINE-OP. I haven't given any thought on whether it's easy or hard to properly inject them as results of INPUT-FILES.
NB: I don't have much cycles for ASDF at the moment, but I will gladly review patches or fix urgent bugs.
I'll try to get a patch done sometime this week. I think I should just base the topic branch off the plan branch, right?
PS: What do you think about releasing ASDF 3.3 after next month, just taking steps to avoid escalating from WARNING to STYLE-WARNING until next release?
3.3 being the "plan branch," right? I think it sounds good, as long as my machines can get in some quality time running the test suite ;-)
On Tue, Jun 27, 2017 at 7:15 PM, Robert Goldman rpgoldman@sift.net wrote:
On 6/26/17 Jun 26 -10:07 AM, Faré wrote:
No, you're right that files from :read-file-form and :read-file-line perfectly fit as INPUT-FILES for DEFINE-OP. I haven't given any thought on whether it's easy or hard to properly inject them as results of INPUT-FILES.
NB: I don't have much cycles for ASDF at the moment, but I will gladly review patches or fix urgent bugs.
I'll try to get a patch done sometime this week. I think I should just base the topic branch off the plan branch, right?
PS: What do you think about releasing ASDF 3.3 after next month, just taking steps to avoid escalating from WARNING to STYLE-WARNING until next release?
3.3 being the "plan branch," right? I think it sounds good, as long as my machines can get in some quality time running the test suite ;-)
Yes, you can either use the "plan" branch directly, or start a new branch off of it if you're not too sure.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Without education, we are in a horrible and deadly danger of taking educated people seriously. — G. K. Chesterton
What seems like the obvious solution to this problem is to invoke RECORD-DEPENDENCY (with PLAN as NIL), but I'm afraid it's not entirely clear how to use this function. This is the DEFGENERIC:
(defgeneric record-dependency (plan operation component) (:documentation "Record an action as a dependency in the current plan"))
So the action is the (OPERATION . COMPONENT) pair. But in that case what do you mean by "record as a dependency"? I think of a dependency as a relationship between two actions, as in "in order to perform the foo operation on bar, you must perform the bletch operation on baz." But this has only one action as argument. So is this the depended on action or the dependent action? I presume the former, but if so, what is the dependent action?
Thanks!
On Thu, Jun 29, 2017 at 7:28 PM, Robert Goldman rpgoldman@sift.net wrote:
What seems like the obvious solution to this problem is to invoke RECORD-DEPENDENCY (with PLAN as NIL), but I'm afraid it's not entirely clear how to use this function. This is the DEFGENERIC:
(defgeneric record-dependency (plan operation component) (:documentation "Record an action as a dependency in the current plan"))
So the action is the (OPERATION . COMPONENT) pair. But in that case what do you mean by "record as a dependency"? I think of a dependency as a relationship between two actions, as in "in order to perform the foo operation on bar, you must perform the bletch operation on baz." But this has only one action as argument. So is this the depended on action or the dependent action? I presume the former, but if so, what is the dependent action?
It looks like you need some RECORD-INPUT-FILE function analog to RECORD-DEPENDENCY, that will inform ASDF that the action being performed has some additional input file that wasn't otherwise previously declared.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a five year period we can get one superb programming language. Only we can't control when the five year period will begin. — Alan Perlis
Thanks. I'll add that. I just didn't want to duplicate code if there was already a method that did what I wanted
Sent from my iPhone
On Jun 29, 2017, at 18:34, Faré fahree@gmail.com wrote:
On Thu, Jun 29, 2017 at 7:28 PM, Robert Goldman rpgoldman@sift.net wrote: What seems like the obvious solution to this problem is to invoke RECORD-DEPENDENCY (with PLAN as NIL), but I'm afraid it's not entirely clear how to use this function. This is the DEFGENERIC:
(defgeneric record-dependency (plan operation component) (:documentation "Record an action as a dependency in the current plan"))
So the action is the (OPERATION . COMPONENT) pair. But in that case what do you mean by "record as a dependency"? I think of a dependency as a relationship between two actions, as in "in order to perform the foo operation on bar, you must perform the bletch operation on baz." But this has only one action as argument. So is this the depended on action or the dependent action? I presume the former, but if so, what is the dependent action?
It looks like you need some RECORD-INPUT-FILE function analog to RECORD-DEPENDENCY, that will inform ASDF that the action being performed has some additional input file that wasn't otherwise previously declared.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a five year period we can get one superb programming language. Only we can't control when the five year period will begin. — Alan Perlis
OK, if you get a chance, have a peek at the test-read-depends branch. Right now it just has documentation fixes and a test. I have a candidate solution, but it's not ready for prime time.
-
Faré -
Robert Goldman -
Robert P. Goldman