Enable dynamic modules in Emacs 25

[ubolonton]

This will help with setting up Travis CI for dynamic modules.

[rejeep]

Please explain in more detail why you want it and what you would use it for.

[ubolonton]

I'm working on the libgit2 support for magit and the underlying Rust binding that enables it.

I want to use evm to manage Emacs versions on CI (Travis specifically). The current recipes compile Emacs without module support.

[rejeep]

It sound like you want this for the Travis recipes?

[ubolonton]

It looks like the Travis recipes are for pre-built Linux binaries. I want to test on OS X as well.

By the way, how do I change the build scripts that are used to make these pre-built binaries?

[rejeep]

It looks like the Travis recipes are for pre-built Linux binaries. I want to test on OS X as well.

I think the way to solve this is using an option to Evm. I remember thinking about implementing this a long time ago, but never did it. I'm thinking something like this:

$ evm install emacs-25.3 --extra-options '--with-modules ...'

By the way, how do I change the build scripts that are used to make these pre-built binaries?

There are none, just instructions: https://github.com/rejeep/evm#adding-travis-binary

[ubolonton]

+1 on --extra-options. Besides modules, --without-threads will be another important variant for Emacs 26.

Does that mean we should wait for that instead? This is not blocking me anyway, as I'm using my fork for the moment.

[rejeep]

I don't work actively on this project anymore so waiting will not help I'm afraid, but I would be happy to accept a PR.

[sambrightman]

Are people only looking to allow for this in from-source builds, or is there some suggestion that binary builds should have better defaults? Allowing generic user-options for from-source builds seems a better answer than this PR indeed, but I was under the impression most people used the binary builds on Travis.

[rejeep]

Are people only looking to allow for this in from-source builds, or is there some suggestion that binary builds should have better defaults?

I would say they are two different things. The first is obvious, we should allow adding any option, it will never hurt. The second is trickier because we want to keep the precompiled binaries rather clean, but at the same time useful. We will have decide for each case.

[sambrightman]

I agree: a PR for the first would be welcome; the second doesn't seem to have a straightforward answer. Whilst it would be possible to provide a small set of variants, that seems like a slippery slope to combinatorial explosion (already a no threads variant is requested in this thread). Not sure what to do about that.

The PR as it stands should probably be closed - it changes the default instead of providing generic functionality.