New autoconf macro

[David Kastrup]

Hi, I did some changes in aclocal.m4 and tex-site.el.in, mostly as
proof-of-concept.

Try this with

./configure --with-auto-dir=woozle
and
./configure --with-auto-dir=/woozle

and see the result in tex-site.el. The Lisp removes possible double
slashes, and adds a single slash at the end.

AC_LISPIFY_DIR should be good for all such directories.

[Jan-Ake Larsson]

Post by David Kastrup
Hi, I did some changes in aclocal.m4 and tex-site.el.in, mostly as
proof-of-concept.
Try this with
./configure --with-auto-dir=woozle
and
./configure --with-auto-dir=/woozle
and see the result in tex-site.el. The Lisp removes possible double
slashes, and adds a single slash at the end.
AC_LISPIFY_DIR should be good for all such directories.

Yep. IIRC the _expanded variables were introduced for the purpose of
using them in lisp code where ${prefix} and suchlike does not make
sense. With the new AC_LISPIFY_DIR (that I think would correctly
expand those), we can get rid of the _expanded variables.

Only one of the variables (lispdir_expanded) is used in Makefile
(masked as auctexdir), and even that wasn't the case until three days
ago. The shell syntax can be used there, so I think we can go back to
using plain, unexpanded variables in Makefile.

The only other place the _expanded variables are used are in
tex-site.el, which is handled by the new code. Getting rid of them
would take quite a few lines off our autoconf macros.

/JÅ

[David Kastrup]

Post by Jan-Ake Larsson

Post by David Kastrup
Hi, I did some changes in aclocal.m4 and tex-site.el.in, mostly as
proof-of-concept.
Try this with
./configure --with-auto-dir=woozle
and
./configure --with-auto-dir=/woozle
and see the result in tex-site.el. The Lisp removes possible double
slashes, and adds a single slash at the end.
AC_LISPIFY_DIR should be good for all such directories.

Yep. IIRC the _expanded variables were introduced for the purpose of
using them in lisp code where ${prefix} and suchlike does not make
sense. With the new AC_LISPIFY_DIR (that I think would correctly
expand those), we can get rid of the _expanded variables.

I am not completely sure. I don't think that AC_LISPIFY_DIR does any
expansion by itself currently, though if that should prove necessary,
it will be quite easy to achieve by using substitute-env-vars in the
Lisp definition. substitute-in-file-name also replaces
$... sequences, but it also collapses "anything//" to "/", so we need
to clean up double slashes with expand-file-name, anyway.

Post by Jan-Ake Larsson
ago. The shell syntax can be used there, so I think we can go back
to using plain, unexpanded variables in Makefile.

IIRC, the whole business of unexpanded variables was to accommodate
our own somewhat misguided approach related to package building, and
it may be that by now all of this half-expanded/quoted stuff is
completely unnecessary since we started supporting DESTDIR.

If I am correct in that assumption, we should be able to get rid of
not only AC_FULL_EXPAND.

[Jan-Ake Larsson]

I presume you mean

Post by David Kastrup
If I am correct in that assumption, we should be able to get rid of
not only AC_FULL_EXPAND.

_________/\__________________
/ \
all _expand variables but also

/JÅ

[David Kastrup]

Post by Jan-Ake Larsson
I presume you mean

Post by David Kastrup
If I am correct in that assumption, we should be able to get rid of
not only AC_FULL_EXPAND.

_________/\__________________
/ \
all _expand variables but also

No, we actually currently have stuff like options set to the _string_
'${prefix}/whatever', with ${prefix} later getting expanded in the
Makefile (either by make or the shell, forgot which). And not even
this weirdness will be needed anymore if I am correct. The current
idea of lispdir-relative settings coupled with DESTDIR should be all
we need. No late expansion of shell variables anymore. It can all be
done at configure time. This means, of course, that

make prefix=somethingelse

will _not_ work anymore, since most variables will not be
prefix-relative. But I don't think this is a problem, is it?

[Jan-Ake Larsson]

Post by David Kastrup

Post by Jan-Ake Larsson
I presume you mean

Post by David Kastrup
If I am correct in that assumption, we should be able to get rid of
not only AC_FULL_EXPAND.

_________/\__________________
/ \
all _expand variables but also

No, we actually currently have stuff like options set to the _string_
'${prefix}/whatever', with ${prefix} later getting expanded in the
Makefile (either by make or the shell, forgot which).

By make.

Post by David Kastrup
And not even
this weirdness will be needed anymore if I am correct. The current
idea of lispdir-relative settings coupled with DESTDIR should be all
we need. No late expansion of shell variables anymore. It can all be
done at configure time. This means, of course, that
make prefix=somethingelse
will _not_ work anymore, since most variables will not be
prefix-relative. But I don't think this is a problem, is it?

It is not so wierd, most of autoconf's defaults are like that. They
get expanded by make and are actually mostly the reason why

make prefix=foo

works. So I would expect it to _start_ working rather than the
opposite.

A few questions:

1) A while ago I introduced a fix for a CVS mishap in
EMACS_EXAMINE_PACKAGEDIR checking for an extra auctex subdirectory.
The fix has been in place a year and a half. No release was made
with the erroneous autoconf code, but a few has been made
containing the fix. Perhaps I can remove it now?

2) All the line continuation backslashes in EMACS_EXAMINE_PACKAGEDIR
seem unnecessary, EMACS_TEST_LISPDIR makes do without them.

3) AC_FULL_EXPAND is performed on arguments to --with-texmf-dir, for
the purpose of doing only test -d ${withval}, I am unsure of the
reason for this? I mean, shell variables would be expanded as
needed there. It is also used in EMACS_TEST_LISPDIR, but there I
think we can just amend the lisp code, or trust shell expansion.
Neither of these do shell escaping, there are double quotes in
effect.

4) Why is $3 "there for historical reasons" in EMACS_LISP, the macro
is internal to our code? I take it that $5 and $6 are used to avoid
some extra quoting business, is this true?

/JÅ

[David Kastrup]

Post by Jan-Ake Larsson

Post by David Kastrup

Post by Jan-Ake Larsson
I presume you mean

Post by David Kastrup
If I am correct in that assumption, we should be able to get rid of
not only AC_FULL_EXPAND.

_________/\__________________
/ \
all _expand variables but also

No, we actually currently have stuff like options set to the _string_
'${prefix}/whatever', with ${prefix} later getting expanded in the
Makefile (either by make or the shell, forgot which).

By make.

Post by David Kastrup
And not even this weirdness will be needed anymore if I am correct.
The current idea of lispdir-relative settings coupled with DESTDIR
should be all we need. No late expansion of shell variables
anymore. It can all be done at configure time. This means, of
course, that
make prefix=somethingelse
will _not_ work anymore, since most variables will not be
prefix-relative. But I don't think this is a problem, is it?

It is not so wierd, most of autoconf's defaults are like that. They
get expanded by make and are actually mostly the reason why
make prefix=foo
works. So I would expect it to _start_ working rather than the
opposite.

Not sure about that.

Post by Jan-Ake Larsson
1) A while ago I introduced a fix for a CVS mishap in
EMACS_EXAMINE_PACKAGEDIR checking for an extra auctex subdirectory.
The fix has been in place a year and a half. No release was made
with the erroneous autoconf code, but a few has been made
containing the fix. Perhaps I can remove it now?

I suppose so. No idea what this was about, anyway.

Post by Jan-Ake Larsson
2) All the line continuation backslashes in EMACS_EXAMINE_PACKAGEDIR
seem unnecessary, EMACS_TEST_LISPDIR makes do without them.

Probably yes.

Post by Jan-Ake Larsson
3) AC_FULL_EXPAND is performed on arguments to --with-texmf-dir, for
the purpose of doing only test -d ${withval}, I am unsure of the
reason for this? I mean, shell variables would be expanded as
needed there.

No. If we have --with-texmf-dir='${prefix}/something' then the $ was
preserved in the variables until make time. At least that was the
idea. But when we have DESTDIR, we won't need to preserve the
${prefix} for as long as that if I am not mistaken.

Post by Jan-Ake Larsson
It is also used in EMACS_TEST_LISPDIR, but there I think we can just
amend the lisp code, or trust shell expansion. Neither of these do
shell escaping, there are double quotes in effect.

If we have "$somevar", and somevar='${someother}', then we only get
one level of expansion.

Post by Jan-Ake Larsson
4) Why is $3 "there for historical reasons" in EMACS_LISP, the macro
is internal to our code?

Good question.

Post by Jan-Ake Larsson
I take it that $5 and $6 are used to avoid some extra quoting
business, is this true?

Yes. They mean that we can pass a shell-variable verbatim into Emacs,
no expansion, no quoting, no Lisp string syntax, no other stupidities.
Essential for dealing with backslashes in file names and similar
idiocies with which we are inflicted.

If you want to work on the stuff, feel free to do so. I am currently
still entangled with UTF-8 and other business. I have just noticed to
my severe indignation that my system has LC_CTYPE set to C under X,
which is intolerable. I suspect fluxbox (which I recently switched
to), but have yet to find the culprit. It already mangled the
telephone book of my mobile with a bad conversion.

So I'll be still busy at least today with other junk.

[Jan-Ake Larsson]

Post by David Kastrup

Post by Jan-Ake Larsson
3) AC_FULL_EXPAND is performed on arguments to --with-texmf-dir, for
the purpose of doing only test -d ${withval}, I am unsure of the
reason for this? I mean, shell variables would be expanded as
needed there.

No. If we have --with-texmf-dir='${prefix}/something' then the $ was
preserved in the variables until make time. At least that was the
idea. But when we have DESTDIR, we won't need to preserve the
${prefix} for as long as that if I am not mistaken.

Yes. But the expansion is only needed for the test (test -d ${withval}).
make handles this, no problem. That is, we only need that expansion if
we are going to use the variable _inside_ configure.

Anyway, the need to use --with-texmf-dir='${prefix}/something' as
opposed to an absolute path has drastically diminished. Gone, I would
say. Perhaps we can avoid expansion there?

And in the PACKAGEDIR stuff there is code to exchange the content of
$prefix (say '/usr') for the string '${prefix}' in the returned
directory string. Perhaps we can remove that too?

Post by David Kastrup

Post by Jan-Ake Larsson
It is also used in EMACS_TEST_LISPDIR, but there I think we can just
amend the lisp code, or trust shell expansion. Neither of these do
shell escaping, there are double quotes in effect.

If we have "$somevar", and somevar='${someother}', then we only get
one level of expansion.

Correct. Would expansion from within lisp handle several levels?

Related question, many-level expansion is handled by the while:;do
case construct, but what does the sed do? Ah, it removes dangerous
quote characters. For the purpose of avoiding syntax errors, perhaps?
It doesn't seem to exchange them for something useful, so I presume
this is just to avoid errors.

Post by David Kastrup
If you want to work on the stuff, feel free to do so. I am currently
still entangled with UTF-8 and other business. I have just noticed to
my severe indignation that my system has LC_CTYPE set to C under X,
which is intolerable. I suspect fluxbox (which I recently switched
to), but have yet to find the culprit. It already mangled the
telephone book of my mobile with a bad conversion.
So I'll be still busy at least today with other junk.

I'll see what happens. Perhaps tonight.
/JÅ

[David Kastrup]

Post by Jan-Ake Larsson

Post by David Kastrup

Post by Jan-Ake Larsson
3) AC_FULL_EXPAND is performed on arguments to --with-texmf-dir, for
the purpose of doing only test -d ${withval}, I am unsure of the
reason for this? I mean, shell variables would be expanded as
needed there.

No. If we have --with-texmf-dir='${prefix}/something' then the $ was
preserved in the variables until make time. At least that was the
idea. But when we have DESTDIR, we won't need to preserve the
${prefix} for as long as that if I am not mistaken.

Yes. But the expansion is only needed for the test (test -d
${withval}). make handles this, no problem. That is, we only need
that expansion if we are going to use the variable _inside_
configure.
Anyway, the need to use --with-texmf-dir='${prefix}/something' as
opposed to an absolute path has drastically diminished. Gone, I
would say. Perhaps we can avoid expansion there?

That's my guess.

Post by Jan-Ake Larsson
And in the PACKAGEDIR stuff there is code to exchange the content of
$prefix (say '/usr') for the string '${prefix}' in the returned
directory string. Perhaps we can remove that too?

My guess too.

Post by Jan-Ake Larsson

Post by David Kastrup

Post by Jan-Ake Larsson
It is also used in EMACS_TEST_LISPDIR, but there I think we can
just amend the lisp code, or trust shell expansion. Neither of
these do shell escaping, there are double quotes in effect.

If we have "$somevar", and somevar='${someother}', then we only get
one level of expansion.

Correct. Would expansion from within lisp handle several levels?

Well, up to now we don't expand anything in Lisp, but we can take any
number of levels we want to.

Post by Jan-Ake Larsson
Related question, many-level expansion is handled by the while:;do
case construct, but what does the sed do? Ah, it removes dangerous
quote characters.

Wrong. It adds quote characters so that the expansion does not lose
any quotes that are part of the file name.

Post by Jan-Ake Larsson

Post by David Kastrup
If you want to work on the stuff, feel free to do so. I am
currently still entangled with UTF-8 and other business. I have
just noticed to my severe indignation that my system has LC_CTYPE
set to C under X, which is intolerable. I suspect fluxbox (which I
recently switched to), but have yet to find the culprit. It
already mangled the telephone book of my mobile with a bad
conversion.
So I'll be still busy at least today with other junk.

I'll see what happens. Perhaps tonight.

Whatever "tonight" means. I'll holler before I start tampering with
anything.