> > (define-public foo > > (let ((hashes > > (with-input-from-file > > (string-append (dirname (current-filename)) > > "/foo.hashes") > > read))) > > (package ...))) > > > Not fully answering your question, but if “foo.hashes” contains hashes > for origins and similar, you could make “foo.hashes” contain something > like: > > (list (base32 …) …) > > and, in the .scm, write: > > (include "foo.hashes") > > The ‘include’ directive includes the file at macro-expansion time, > similar to #include in C. i did find guile's INCLUDE and tried to use it, but it also didn't work when guix pull'ing it. see the attached, now abandoned commit. IIRC the issue is that the implementation of INCLUDE tries to load the file relative to the cwd, but cwd is not changed by the code that is driving the compilation when guix pull'ing the code. (does each thread has its own cwd at all...?) it works when i build it using `./pre-inst-env guix build foo`. i briefly tried to analyse what's the difference between the two situations, but i ran out of steam. it is the same reason i need to call READ like below in my current implementation: (define (%read-module-relative-file module filename) (with-input-from-file (or (search-path %load-path (string-append (dirname (module-filename module)) "/" filename)) (error "%read-module-relative-file failed for" filename)) read)) ...which is not beautiful. > Back to the original issue, I suppose ‘current-filename’ return #f when > this .scm is first loaded, before it’s compiled. Anyway, it’s probably > best to load it at macro-expansion time as you suggested. is my analysis is correct, namely that cwd is not (always?) changed at macroexpand time, and thus the implementation of INCLUDE is broken for relative paths? is this a bug to be fixed in guile? if so, shall i try to add a test case for this somewhere? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom.” — Isaac Asimov (1920–1992)