Re: Graft hooks

t;> 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 (gu

Re: Graft hooks

>> >> 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

Re: Graft hooks

5>. 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 >> n

Re: Graft hooks

; <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/rac

Re: Graft hooks

ingle 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

Re: Graft hooks

Ludovic Courtès writes: > >> Here’s a draft patch (it’s mercifully small). I have a few questions >> about it, but if it looks like the right approach, I will clean it up >> and submit it. >> >> Basically, it checks if we are grafting Racket, and then adds some code >> to the build expression to

Re: Graft hooks

<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? ;) >

Re: Graft hooks

cess). > + (invoke raco "setup" "--no-launcher" "--no-install" > + "--no-post-install" "--no-info-domain" "--no-docs" 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? Thanks, Ludo’.

Re: Graft hooks

ble use a heuristic like whether there is a “debug” output. For Go, it gets tricky because we would have to check if Go was used to build part of the output (I guess we could check the dependency graph, but that sounds like it could be slow). Similarly, if we ever have a “racket-build-system”, w

Re: Graft hooks

Hello Timothy, Timothy Sample skribis: > The basic idea would be to add a field (or use a property) to the > package record. Let’s call it “graft-hook”. It would be Scheme code > that gets run after grafting takes place, giving us a chance to patch > special things like checksums. The hook wo

Re: Graft hooks

Christopher Lemmer Webber ezt írta (időpont: 2018. aug. 13., H, 2:28): > Timothy Sample writes: > > > Hi Guix, > > > > I just submitted a patch for , but now I’m > > wondering if there isn’t a more general way to solve the problem. > > > > The bug has to do with grafti

Re: Graft hooks

Timothy Sample writes: > Hi Guix, > > I just submitted a patch for , but now I’m > wondering if there isn’t a more general way to solve the problem. > > The bug has to do with grafting and checksums. I know three bugs that > follow this theme: the one above (Racket), <

Graft hooks

Hi Guix, I just submitted a patch for , but now I’m wondering if there isn’t a more general way to solve the problem. The bug has to do with grafting and checksums. I know three bugs that follow this theme: the one above (Racket), (GDB), a