Mark H Weaver <
address@hidden> ezt írta (időpont: 2018. aug. 23., Cs, 9:18):
Hi Ludovic,
address@hidden (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.
Having said this, I haven't looked at this issue carefully, so perhaps
I'm midjudging the difficulty of adding such a mechanism.
What do you think?
Mark
I think there are actually three different levels of problems solved by graft hooks.
One level is global, like the debugging symbols, and I'm fine with it in (guix grafts).
Another level is language/build system/ecosystem specific, like the Racket or the
java manifest issue, so I believe it would be nice to be able to use build system
code to address problems at this level. I can also believe that there are problems
relating to this on the individual package level, where the solution that Mark mentioned
comes into play. WDYT?
Reflecting on this a Racket build system seems to be a good idea.
g_bor