Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> l...@gnu.org (Ludovic Courtès) writes: > >> Since this is used when grafting Racket, I would suggest moving this >> graft to the “build side” entirely, similar to what I did in >> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19973#25>. Probably >> you’d just add a single procedure to (guix build graft) and add it to >> %graft-hooks. >> >> That procedure could be the same as what you have above, except that >> it’d run OUT/bin/raco, if it exists, and do nothing if OUT/bin/raco does >> not exist. >> >> WDYT? > > I think it would be quite unfortunate if _every_ graft had to run > _every_ graft hook, or if every graft hook had to be defined in > (guix grafts) and/or (guix build graft). > > It's reasonable to have a few global graft hooks, e.g. for handling > debugging information, but I would greatly prefer for Guix to also have > a mechanism allowing individual packages or build systems to introduce > graft hooks without modifying (guix grafts) or (guix build graft), and > for such a mechanism to be used for Racket and its libraries. Sure, like I wrote, a more extensible solution along the lines of what Timothy and you suggest sounds better long-term. It just happens to be harder to implement today (in particular until ‘wip-build-systems-gexp’ is merged), and not entirely clear how this could work, as discussed with Timothy. That’s why I’m proposing the simple approach for now. I think we can revisit the issue if/when we have graft hooks tied to a particular package or build system. Note that the .gnu_debuglink hook in <https://bugs.gnu.org/19973> runs only when there’s a “debug” output, and the Racket hook that Timothy proposes would only run when Racket is available. So you get extra run-time overhead only if there’s something to do. HTH, Ludo’.
