I have submitted new changes applying your suggested changes. Tested the new derivation and it installs properly.

This should ideally be rebased into one commit with the message crumbs: init at version 0.0.2.

I added a few more comments, but it looks good to me overall.

Removed a trailing comma in the includes header of default.nix

@Thesola10 looks like you might have mixed something up on that last push:

hash mismatch in fixed-output derivation '/nix/store/7km1gylsg0xscbp538rfq4w8rqa3zbp8-source':
wanted: sha256:1m7fwjw74fy8pgsvjda1c7awl2y5jr0r3fb5a6v5rddym5w52s0b
got: sha256:0j7axygbaz3bcpjngybigk333lga67bg7g8gw47j4xx3gyc9qf2n

@aanderse there's a reason behind it. I think I had used a specific commit for reference instead of version 0.0.2

@Thesola10 is this currently building on your system? I pulled again and got this:

autoreconf: running: automake --add-missing --copy --force-missing
Makefile.am: error: required file './README' not found
autoreconf: automake failed with exit status: 1

this is very weird. noticed it also does that with 0.0.3...

Upon second look, it seems that the --force-missing option that autoreconfHook adds is causing this. I just wrote a test configurationPhase locally to test that and it works again. Can I push that, or is there a cleaner way?

Also, I'm kind of weirded out by the fact that @GrahamcOfBorg doesn't seem to test whether the actual derivation can build properly...

Also, I'm kind of weirded out by the fact that @GrahamcOfBorg doesn't seem to test whether the actual derivation can build properly...

I'll be asking the bot to build your program once it builds on my machine.

Can I push that, or is there a cleaner way?

Please rewrite the git history.

Please rewrite the git history.

Of course. I was asking if there was a better way than to redefine configurePhase.

Of course. I was asking if there was a better way than to redefine configurePhase.

Ah... sorry I read that wrong the first time 😆 I'll defer to @jtojnar for all autoreconfHook related questions though :)

You really should not override configurePhase it breaks things like configureFlags. You can call automake in preConfigure.

Or you can override the flags autoreconfHook sets with autoreconfFlags:

@jtojnar thanks for the advice! After testing, though, what worked was setting automake and autoconf as nativeBuildInputs, and overriding automakeFlags to --add-missing.

I would not expect automakeFlags to do anything, it is not defined in nixpkgs.

It looks like they have pre-generated ./configure script in the repo so autotools should not be needed at all, unless the script is incorrectly generated and we need to re-generate it.

I would not expect automakeFlags to do anything,

You're right, it does not seem necessary. In any case, using autoconf and automake instead of autoreconfHook seems to work.

After another test, it would seem that configure is pre-generated. Which is weird, since I remember a previous version required to automake it.

@Thesola10 seems like only outstanding issue is addressing the 0.0.3 comment mentioned in #58960 (comment).

the 0.0.3 comment

Do you mean that I need to bump the derivation to crumbs 0.0.3? I can do that, just making sure

I think all of the discrepancies in the build process (like autoreconfHook) come from the difference between master and release tags in the crumbs repo.

the 0.0.3 comment

Do you mean that I need to bump the derivation to crumbs 0.0.3? I can do that, just making sure

I did mean that. I ran checked out your branch and it does build fine as is on 0.0.3.
While in there I happened to notice this: https://github.com/fasseg/crumbs/blob/master/crumbs-completion.bash
Any motivation to add this to your package? Seems valuable 😄

Any motivation to add this to your package?

Would adding it into $out/share/bash-completion/completions work?

Here are a few examples of bash and fish shell completions searching through the codebase turned up:

https://github.com/NixOS/nixpkgs/blob/cfa3f9bb996e4c871c8574fb5302512ed4485abc/pkgs/development/tools/kubectx/default.nix

https://github.com/NixOS/nixpkgs/blob/11318d1ba2d3a06dcffa9144042c1397eff4ac9e/pkgs/applications/science/logic/elan/default.nix

https://github.com/NixOS/nixpkgs/blob/25e7f59516b2c8254df13b448a2ed5e28b848dd3/pkgs/applications/version-management/pijul/default.nix

Added the autocomplete scripts in a postInstall directive, since I saw these examples were overriding installPhase (which I kinda don't like, always prefer builtin to handwritten) edit: turns out only kubectx does that . The files end up where they need to be, and the derivation builds fine.
Oh and I bumped to 0.0.3 while we're at it.

Looking good. The fish completions reference gfind instead of find so I made this change and then they worked:

  prePatch = ''
    sed -i 's|gfind|find|' crumbs-completion.fish
  '';

and in the postInstall

-    cp $src/crumbs-completion.bash $out/share/bash-completion/completions/crumbs
-    cp $src/crumbs-completion.fish $out/share/fish/vendor_completions.d/crumbs.fish
+    cp crumbs-completion.bash $out/share/bash-completion/completions/crumbs
+    cp crumbs-completion.fish $out/share/fish/vendor_completions.d/crumbs.fish

and in the postInstall

-    cp $src/crumbs-completion.bash $out/share/bash-completion/completions/crumbs
-    cp $src/crumbs-completion.fish $out/share/fish/vendor_completions.d/crumbs.fish
+    cp crumbs-completion.bash $out/share/bash-completion/completions/crumbs
+    cp crumbs-completion.fish $out/share/fish/vendor_completions.d/crumbs.fish

Wouldn't the reference to $src make it more semantically clear what is happening?

$src wasn't patched.

The original repo mentions a /etc/crumbs.conf file, and a quick strace confirms that our built crumbs accesses it from its derivation path (expected). Should I add configuration entries to generate the file? And if so, would the config entry go in nixos/modules/programs/?

As far as I can tell crumbs.conf is trivial and provides a very sane default. Given the crumbs executable has a way to override the location of crumbs.conf I think leaving everything as you currently have it is perfectly reasonable.

Side note -- why is the "changes requested" blocker still present? Is my branch ready for merging?

@GrahamcOfBorg build crumbs

I guess I was waiting to hear if you were satisfied with my response 😄

@Thesola10 thank you for your contribution! 🎉