Standardize build system - Githubissues

mighty-gerbils / gerbil

Gerbil Scheme

https://cons.io

GNU Lesser General Public License v2.1

1.14k stars 112 forks source link

Standardize build system #1052

Open Marie-Joseph opened 8 months ago

Marie-Joseph commented 8 months ago

The way Gerbil's build system currently works makes it quite difficult to package, especially on distributions that aim for reproducibility. Here are some ways you can make the build more manageable:

don't require network at build time
don't use git at build time (sometimes people aren't building from git)
don't vendor dependencies (this is bad practice anyway)
expose any paths to required binaries (or anything that should be in PATH for that matter) through environment variables or command line options
actually use the variables mentioned above (GERBIL_GSC is mentioned in src/build/build0-lib.scm and apparently used nowhere else, for example)
don't use bespoke build scripts (just use make)

It's probably fine to ignore that last one as long as all the others are taken into account.

I really like Gerbil and want to use it more, but the incredibly weird way it's built makes keeping it up-to-date a pain. I've been trying to maintain the Guix package for it, but now that you've vendored Gambit I'm having to unknit some horrific spaghetti to be able to build it.

It occurs to me this is similar to how Racket vendored Chez. Don't take Racket as an example of how to develop a Scheme. Its BC codebase was notoriously atrocious, and the way CS is handled requires hacks to package. (This should change now that mainline Chez has incorporated the Racket changes, though.) Everyone I know who wants to use Scheme for anything more than research avoids Racket because its packaging story is so bad. Do not treat it as a blueprint for a language ecosystem. I am begging you as someone who loves Scheme and who packages for Linux distributions.

fare commented 8 months ago

Note that I have a packaging of Gerbil packages in Nix, that works around these issues. It gets regularly upstreamed in nixpkgs, and the latest is generally at: https://github.com/muknio/nixpkgs/tree/devel

fare commented 8 months ago

Also, @drewc has a variant of Gerbil in his Guix extension druix — I'm not sure how up-to-date it is, but either way, you two may want to synchronize on Gerbil support for Guix: https://github.com/drewc/druix

Marie-Joseph commented 8 months ago

His Gerbil package is just a copy-paste of the one I submitted to mainline for 0.17. 0.18 changing the build system broke that build method.

Edit: I'm a dingus and forgot what I actually did for the 0.17 update. There was just an issue with getting the right version to print so the changes I made were quite minor. We were working from the same code (that he wrote?)

Really, the main issue is the gambit vendoring. Do y'all need unreleased features for gerbil?

fare commented 8 months ago

Yes, we do depend on unreleased features, such as crucially the fix to https://github.com/gambit/gambit/issues/659 — and then we modified Gerbil to fit the new Gambit source code location changes, so current Gerbil will not run on older Gambit.

See how I deal with it in Nix, if that helps.

fare commented 8 months ago

I understand the Nix code might not be very readable, but I'm available to show you around the code—contact me personally (e.g. by email, or on IRC) for an online meeting.

Marie-Joseph commented 8 months ago

Thanks! I really, really appreciate that. A cursory glance suggests this fix should be fairly easy to port, but I'll contact you if I run into issues!

In the longer term, then, can we expect Gambit to be un-vendored whenever there's a Gambit release with the requisite fixes?

fare commented 8 months ago

There is no current plan to un-vendor Gambit, and instead plans to keep increasing the coupling so as:

to enjoy the latest features such as this critical (to us) bug fix, or the latest progress on JS support or multithreading.
to remove the onerous (to us) conditional compilation we used to have to support both older and newer variants of Gambit (e.g. for missing R7RS bits, various bug fixes or changes in internal representations)
to reduce the exponential complexity of version matches and mismatches between Gerbil and Gambit, and the difficulty of making sure that Gerbil finds at an expected path the right version of Gambit compiled with the right options, and that this Gambit won't be upgraded without Gerbil noticing.

Maybe in the far future, things will stabilize so much that these stop being issues, but likely not in the foreseeable future.

(I was annoyed, because I had created such as nice connection between Gerbil and Gambit in Nix, but I understand the issue especially for systems outside Nix and Guix.)

drewc commented 8 months ago

Thanks! I really, really appreciate that. A cursory glance suggests this fix should be fairly easy to port, but I'll contact you if I run into issues!

I'm working on it now. We should have a "guix" subdirectory and an --install-from-file ready by tomorrow.

As well, the packages in druix were not a copy/paste. There were no gerbil package in upstream guix at the time! :)

Especially gerbil-unstable was quite useful. Things have changed with the inclusion of gambit, for the better. No need for druix for Gerbil right now. Yay!

drewc commented 8 months ago

@Marie-Joseph : Have a look here : https://github.com/mighty-gerbils/gerbil/tree/guix-package

It will be a part of the point release and it works great locally but, you know, guix? :P

vyzo commented 2 months ago

this is mostly done with v0.18, no?

Anything else to do here?