build-specific lisp files (generated by configure)

build-specific lisp files (generated by configure)

[Glenn Morris]

I was playing with the idea of moving some lisp variables that configure
sets (system-configuration etc) from C to lisp. Say, to an
auto-generated lisp/emacs-config.el.

It seems to work fairly nicely, but leaves you with the issue that you
now have a build-specific (even worse than platform-specific) file in
lisp/. This is a problem if you want to share lisp/ between different
builds (eg X and no-X builds). I thought about simply not installing
emacs-config.el (i.e., treat it like a C source file), but that would
fail for installed CANNOT_DUMP builds.

It's not important, but I wondered if anyone had an idea for a solution?

Re: build-specific lisp files (generated by configure)

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> It's not important, but I wondered if anyone had an idea for a solution?

I'd guess the solution is to introduce a build-specific lisp directory,
alongside ${archlibdir}.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build-specific lisp files (generated by configure)

[Glenn Morris]

Andreas Schwab wrote:

> Glenn Morris <rgm@gnu.org> writes:
>
>> It's not important, but I wondered if anyone had an idea for a solution?
>
> I'd guess the solution is to introduce a build-specific lisp directory,
> alongside ${archlibdir}.

Yes, but what would it even be called?
It's name would depend on the specific configure options used. Yuck.
So I guess the idea doesn't work. Oh well.

Re: build-specific lisp files (generated by configure)

[Stefan Monnier]

>>> It's not important, but I wondered if anyone had an idea for a solution?
>> I'd guess the solution is to introduce a build-specific lisp directory,
>> alongside ${archlibdir}.
> Yes, but what would it even be called?
> It's name would depend on the specific configure options used. Yuck.
> So I guess the idea doesn't work. Oh well.

I'm not sure I completely understand the issue, but could we generate
the file in src/config.el and then from loadup.el load it via
(expand-file-name "src/config.el" source-directory)?

Of course, if this src/config.el is where source-directory is defined,
we'll need to pass the /foo/src/config.el name from src/Makefile to
the temacs process on the command line.


        Stefan

Re: build-specific lisp files (generated by configure)

[Glenn Morris]

Stefan Monnier wrote:

> I'm not sure I completely understand the issue, but could we generate
> the file in src/config.el and then from loadup.el load it via
> (expand-file-name "src/config.el" source-directory)?

Sure, but that's not really the problem.

The problem is installed CANNOT_DUMP builds where the source has been
deleted. For them, we'd have to install config.el somewhere. And where
would it go? It would have to be a build-specific location.

Not that we really support CANNOT_DUMP builds anyway (pretty sure I
accidentally broke the Makefiles for those a while ago).

Anyway, it's not important, since there's no need to make such a change.

Re: build-specific lisp files (generated by configure)

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Yes, but what would it even be called?

Just like archlibdir, only under libdir.

> It's name would depend on the specific configure options used. Yuck.

Why?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build-specific lisp files (generated by configure)

[Glenn Morris]

Andreas Schwab wrote:

> Just like archlibdir, only under libdir.
>
>> It's name would depend on the specific configure options used. Yuck.

s/It's/Its  :(

> Why?

Because it would contain things like `system-configuration-options'.

Maybe it could live in lisp, but have a name like config-`uuidgen`.el.
Yuck. :)

Re: build-specific lisp files (generated by configure)

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Because it would contain things like `system-configuration-options'.

And why is that a problem?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build-specific lisp files (generated by configure)

[Glenn Morris]

Andreas Schwab wrote:

> Glenn Morris <rgm@gnu.org> writes:
>
>> Because it would contain things like `system-configuration-options'.
>
> And why is that a problem?

See my first message.

Re: build-specific lisp files (generated by configure)

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> See my first message.

Please expand.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build-specific lisp files (generated by configure)

[Glenn Morris]

Andreas Schwab wrote:

> Glenn Morris <rgm@gnu.org> writes:
>
>> See my first message.
>
> Please expand.

I thought you liked brief communcations. :)

Because eg both Red Hat and Debian provide Emacs packages in with-x and
without-x flavours, with a shared emacsen-common package that contains
the lisp/ files. Those X and no-X binaries are supposed to be
co-installable (pointless though that may be). Both would have the same
arch triplet (eg x86_64-linux-gnu), but they would have different values
of system-configuration-options, so would need separate config.el files.

Re: build-specific lisp files (generated by configure)

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> of system-configuration-options, so would need separate config.el files.

So they just need to resolve another file conflict.  Not our problem.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: build-specific lisp files (generated by configure)

[Glenn Morris]

Andreas Schwab wrote:

> So they just need to resolve another file conflict.  Not our problem.

Maybe you're right. At the moment I don't feel like this is something
worth pursuing though.