From: ludo@gnu.org (Ludovic Courtès)
To: Timothy Sample <samplet@ngyro.com>
Cc: guix-devel@gnu.org
Subject: Re: Graft hooks
Date: Fri, 24 Aug 2018 12:09:44 +0200 [thread overview]
Message-ID: <87pny8qdnb.fsf@gnu.org> (raw)
In-Reply-To: <87y3cy8db6.fsf@ngyro.com> (Timothy Sample's message of "Wed, 22 Aug 2018 14:29:49 -0400")
Hello Timothy,
Timothy Sample <samplet@ngyro.com> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
[...]
>>>> I agree that this would be the right thing to do! (I’d really like to
>>>> do it for GDB as discussed in <https://bugs.gnu.org/19973>.)
>>>>
>>>> Package properties would be the right way to make it extensible, but
>>>> there are complications (notably we’d need to use gexps, but build
>>>> systems don’t use gexps yet.)
>>>
>>> But soon, right? ;)
>>
>> Well, it’s complicated. :-)
>>
>> Also, I realized that some things, like the .gnu_debuglink and build-id
>> hooks, don’t really fit in any package; they’re transverse.
>
> You’re right. Packages are the wrong place. What about build systems?
> Maybe it makes sense (theoretically) to define graft hooks in build
> systems, and then modify them (if necessary) using the “arguments” field
> of a package. Isn’t it the GNU or Go build systems that are ultimately
> responsible for these checksums? Shouldn’t it be their job to tell the
> grafting code how to fix them?
It’s not completely clearcut. For instance, the GCC toolchain can
produce .gnu_debuglink and build-IDs, but the GCC toolchain and
‘gnu-build-system’ are not the only one doing so: ‘guile-build-system’,
‘go-build-system’, etc. could do that as well. So .gnu_debuglink and
build-IDs are an example of something that doesn’t “belong” to any
single package or build system, I think.
[...]
>> Regarding timestamps: I guess there’s no problem since timestamps are
>> reset in the store.
>
> Whoops! I didn’t mean the file metadata, I meant in the bytecode files
> themselves. Also, I only saw the changes in diffoscope and assumed they
> were timestamps. I looked more closely and realized they were more
> checksums that I didn’t notice before (it should have been obvious
> because they are 20 bytes...). They are supposed to be updated.
> Nothing to see here. :)
OK. :-)
> Following my note above, I think I will try and finish my update code in
> Guile, and then use the existence of “share/racket” as the heuristic to
> determine if it should run.
>
> Maybe I will package a Racket library, too, so I can test it.
Great, thank you!
Ludo’.
next prev parent reply other threads:[~2018-08-24 10:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-12 19:49 Graft hooks Timothy Sample
2018-08-13 0:28 ` Christopher Lemmer Webber
2018-08-13 7:19 ` Gábor Boskovits
2018-08-20 9:12 ` Ludovic Courtès
2018-08-21 15:42 ` Timothy Sample
2018-08-22 14:21 ` Ludovic Courtès
2018-08-22 18:29 ` Timothy Sample
2018-08-24 10:09 ` Ludovic Courtès [this message]
2018-08-22 19:15 ` Christopher Lemmer Webber
2018-08-23 7:15 ` Mark H Weaver
2018-08-23 9:54 ` Gábor Boskovits
2018-08-24 10:17 ` Ludovic Courtès
2018-08-24 21:59 ` Mark H Weaver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pny8qdnb.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=samplet@ngyro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).