docker-emacs
docker-emacs copied to clipboard
Silex
emacs.git vc source no longer available in /opt/emacs
Hi, thanks for making these. I've been using them for a couple years now with great success. With the latest changes, I see that (at least on master-dev) the emacs.git repo is no longer available in /opt/emacs, only what looks like the contents of a tarball. If this is intentional, is there a way of convincing you to reconsider? If not, any suggestions on an alternative elsewhere that includes the upstream .git source? Although this sort of messes with my happiness, I can't complain because it's your show. If this is indeed the end, thanks for the many years fo great work!
Hello,
I went for the tarball because that's much easier on the servers (compared to a full git clone each time a new image is built), and the source is the same (at least it should).
But ok I'll try to re-clone the repo like I did before (I had a cache system in place that I got rid of when going with the tarball).
Philippe Vaucher @.***> writes:
But ok I'll try to re-clone the repo like I did before.
I mean, please don't change your plans on my account. I just figured I'd ask in case you did it on a whim. But now that I look at your changes, it seems you redid everything as part of a broader mission (moving to Nix?).
Anyway, I liked having the VC source with all the build artifacts (the *.o, *.elc, etc.) in place, so anyone could easily test patches by running something like:
- git am 0001-one.patch ...
- make
- make check
And only the files touched by the patch set would have to be rebuilt before running the test suite. IOW, a huge time saver, and for me, the killer feature! But again, in this day and age, when it's so easy for anyone to just make their own, I wouldn't worry about trying to cater to everyone's niche use cases. Thanks for offering, though!
it seems you redid everything as part of a broader mission (moving to Nix?).
Yes, by moving to purcell's nix package I got rid of plenty of old bugs and gotchas, I was also able to use debian:latest and alpine:latest for all images, basically my life is much easier.
Before this I had to keep track of 3-4 different base OS (with their libraries versions) and around 10 different patches and 5 different configure flags, all of them depending of the emacs version. And some images were just segfaulting god knows why.
Anyway, I liked having the VC source with all the build artifacts (the *.o, *.elc, etc.) in place, so anyone could easily test patches by running something like: 1. git am 0001-one.patch ... 2. make 3. make check
Are you more interested by this or by having the git repo (or both?)
Restoring the git repo is "easy", restoring the *.o etc is more complicated.
@purcell: theorically, I guess after nix built the thing there is some directory that contains all the .o and all? or does it make clean by default? Any hints apprieciated 😉
Philippe Vaucher @.***> writes:
Before this I had to keep track of 3-4 different base OS (with their libraries versions) and around 10 different patches and 10 different configure flags, all of them depending of the emacs version
This move seems well worth it then in terms of shedding unnecessary stress. Nice.
Are you more interested by this or by having the git repo (or both?)
Yeah, I think you nailed it. Despite the bug's title, I guess I'm really mainly just interested in the *.o stuff.
Restoring the git repo is "easy", restoring the *.o etc is more complicated.
As you say, the git repo's just a --depth 1 clone away, but all the little objects are another story. I think my use case may be a bit of a hack and that for more complicated stuff, a clean build from scratch would still be needed. So I guess this probably isn't worth the extra effort to support then. Thanks anyway, though.
@jpneverwas: ok so you are more interested in the *.o stuff, I have an idea that might just work, assuming nix doesn't "make clean" as part of the process, is to simply copy the nix temporary build folder to /tmp/emacs
It could also solve the tarball thing since this is the source! I'd would require a bit of refactoring tho.
But this is unknown territory, let's keep this open and see where it goes.
@jpneverwas: your task is to find out how to have nix-env -iA emacs-26-3 -f https://github.com/silex/nix-emacs-ci/archive/master.tar.gz keep the .o, my guess is that it uses a temporary directory that it deletes at the end.
I just tried for a while and couldn't find how. Maybe @purcell has an idea :wink:
Idea: apply a patch that modifies the makefile to copy the build dir to some other place at the very end of "make install".
Yes, it cleans things up by default. In fact, it might not even build locally, if it downloads cached binaries. But if you really want .o somewhere, then you can suppress caching and use nix-build with -K (IIRC) to keep the build dir.
Of course, if you start copying that dir into the image, there's no guarantee that the end user could conveniently re-run the build process in a compatible way. For that, you'd have to put the same compiler etc in the image too, and build it the way Nix did.
Of course, if you start copying that dir into the image, there's no guarantee that the end user could conveniently re-run the build process in a compatible way. For that, you'd have to put the same compiler etc in the image too, and build it the way Nix did.
Yeah, the dev image would probably be simply the builder image.
Ok so nix-env just "install things" (cached or not) and nix-build is what might be used by nix-env, so I should call that to keep the artifacts.
I'll keep that issue open and see if I have time to hack on it. Thanks for the info!
Ok so nix-env just "install things" (cached or not) and nix-build is what might be used by nix-env, so I should call that to keep the artifacts.
Yes and no. I believe that nix-build will also use cached artifacts if available and determined to be suitable.
Yes and no. I believe that
nix-buildwill also use cached artifacts if available and determined to be suitable.
In my case I don't use cachix so I won't have cached artifacts.
Ok I have the build dir by using postFixup = "cp -a $(pwd) /tmp/emacs";, but as the build tools/libs are not installed anymore it's a bit useless... so I just have to install the build tools/libs.
But there has to be a better plan, so I asked on nixos/nix and we'll see how it goes.
Thanks for exploring this. I tried looking into Nix a bit, and it's pretty fascinating, but it's also this whole other country, I'm now realizing.
But even after going through the "first steps" guide, I see that the very thing this bug is asking for (the tool chain and the post-build environment) is at best nonstandard and at worst a flaunting of the Nix philosophy in the sense of trying to smuggle out undeclared side effects along with the official outputs.
As you're well aware, the older legacy setup you replaced happened to suit my use case because it was basically a snapshot of not only the build tree but also the actual system immediately after a make install.
I worry that trying to reconstitute all this in a separate deployment image may be more trouble than it's worth. Obviously, you know best and are just experimenting, but hopefully the time spent doing so will be worthwhile whatever the outcome. Thanks again.
Yeah, I'd be a bit wary of doing too much work to handle this special case. FWIW it's quite easy to use Nix locally to experiment with building a patched Emacs, or simply to provide the necessary dev dependencies to do so.
Thanks for your inputs, yeah probably that I'm going against nix here, and thus my plan B is actually the only way without modifying nix-emacs-ci too much.
I realised I could probably copy nix-emacs-ci into nix-emacs-ci-dev and basically move buildInputs as runtime dependencies.
But basically at the moment the -dev images are a bit useless. Maybe I should simply drop them OR continue this issue until I have something satisfactory.