Support for X or other configure flags

[terlar]

I know that this might be missing the target, as this is mainly intended for CI use. But recently I switched over my local test-environment to using these nix derivations as well. However, sometimes I would like to test a UI feature, but since it is compiled with with-x=no among other things I can't. I wonder if it would be possible to add extra options, or if that would miss the point with cache and all.

https://github.com/purcell/nix-emacs-ci/blob/emacs-snapshot-2020-01-27/emacs.nix#L39-L49

Is there no case on CI where you would like to toggle specific features?

Feel free to close this if this is missing the point and out of scope.

Thank you for a great solution, makes testing my packages against different versions a breeze.

[purcell]

I guess I'm not averse to it, but I would want GUI support on both platforms, and for the "with X" configurations to be variants in addition to the existing builds, not replacements for them. I believe the download size for these variants would be significantly larger. I'm not super motivated to work on it myself, I'm afraid.

[Silex]

I'm also interested in X support. Do you have a rough guide of what needs to be done for it to move forward (so maybe I can start some PR)? Based on my images X support adds 50-100 MB (25.1 is using nix-emacs, 25.3 is my current build):

philippe@stvs-pv-laptop-01:/mnt/c/Users/Philippe Vaucher$ docker images | grep silex | grep ci
silex/emacs          25.1-ci       0d117dc22581   4 days ago       394MB
silex/emacs          25.3-ci       370b56ba15b5   10 days ago      484MB

philippe@stvs-pv-laptop-01:/mnt/c/Users/Philippe Vaucher$ docker images | grep silex | grep alpine
silex/emacs          25.1-alpine   790e6d47d922   4 days ago       178MB
silex/emacs          25.3-alpine   f16d9018b97c   8 weeks ago      224MB

[purcell]

The route to this would be incorporating more code from the upstream nixpkgs expression into emacs.nix here, together with additional conditional flags so that elements in overlay.nix can be defined with those flags on/off. Then we'd have a bunch of overlay elements with those flags turned on. I am a bit worried about two things here: firstly, a combinatorial explosion of emacs builds if we add various feature flags like this, and secondly, the total cache size in cachix, which is limited to 1GB of artifacts across all cached versions.

[Silex]

I am a bit worried about two things here: firstly, a combinatorial explosion of emacs builds if we add various feature flags like this, and secondly, the total cache size in cachix, which is limited to 1GB of artifacts across all cached versions.

1. I agree this looks like it could lead to havoc. One trick we could use is just two versions: "bare" and "featurefull". We'd start with "bare" being the current version, and "featurefull" with X support (and maybe --with-native-compilation). My guess is that would be untouched for months, then maybe someone wants FOO and we can add it to featurefull or not.
2. That can be a problem rapidly indeed. Can you disable cachix for some versions?

[purcell]

2\. Can you disable cachix for some versions?

Probably, yes, but I'd rather not. I should look into the cache usage, if stats for that exist.

[terlar]

Hmm, where does it say that cachix is limited to 1GB of artifacts?

Free for Open Source Community plan has 5 GB storage for Open Source projects.

Should be at least 5GB?

I think it sounds good to start with providing two flavors, one with multiple features enabled and one lightweight.

[purcell]

Ah, nice, I think that might have changed since the early days of cachix.

[Silex]

What would be good names? featurefull and lightweight?

Also is +100MB really a showstopper? One version is simpler 😉

[Silex]

Related to #49.

[tgbugs]

It would be great to get some version building with --with-native-compilation, it seems that there are some changes to compiler warnings when it is enabled that would be great to catch in CI.

[purcell]

@tgbugs I was thinking about this when I was updating the snapshot version recently. I figured it wasn't particularly worthwhile for the sake of performance, but if there are compiler warning differences then that becomes more interesting: do you have any pointers?

[tgbugs]

If I understand the question correctly, you need libgccjit installed, and should probably run make with NATIVE_FULL_AOT=1 so that the native binaries are already built otherwise every CI job could involve running the compiler over the same builtin elisp packages.

We are also in the process of exploring whether the difference in compiler warnings is expected behavior, if it is not then this might not matter, however having a native comp build for CI might help catch Emacs regressions like this (assuming this is a regression).

[purcell]

Yeah, if there's a case that isn't a regression — ie. there are additional useful compiler warnings that are only produced in the presence of native compilation — then this would certainly make sense to explore. Catching regressions in Emacs itself is probably not a primary goal though.