Discussion:
Using $program_transform_name from ‘configure’
Ludovic Courtès
2014-04-23 16:40:58 UTC
Permalink
Hello,

$program_transform_name is apparently meant to be used in makefiles
only, as suggested in the manual and in this comment from ‘configure’:

--8<---------------cut here---------------start------------->8---
# Double any \ or $.
# By default was `s,x,x', remove it if useless.
ac_script='s/[\\$]/&&/g;s/;s,x,x,$//'
program_transform_name=`$as_echo "$program_transform_name" | sed "$ac_script"`
--8<---------------cut here---------------end--------------->8---

The doubled $ and \ make it impossible to use it directly within
configure.ac.

What’s the recommended way to use it in configure.ac?

Thanks,
Ludo’.
Eric Blake
2014-04-23 19:45:49 UTC
Permalink
Post by Ludovic Courtès
Hello,
$program_transform_name is apparently meant to be used in makefiles
What’s the recommended way to use it in configure.ac?
I'm not sure I follow the end goal. Why do you think you need to use it
from within configure.ac? Are you trying to set up a config.h
substitution that includes the transformed name that a program will be
installed under for use within the program? This is actually one use
case that I think really DOES make sense - there's discussion on the
grep mailing list about making 'egrep' a simple C program wrapper around
'grep -E', but if 'grep' is installed under a different name due to
program_transform_name, 'egrep' (or whatever actual name it gets
installed as) needs to know the transformed name to be exec'd.

One alternative would be to have 'grep' and 'egrep' both be shim
wrappers, that can be installed under any transformed name, which then
call ${libexecdir}/grep which gets installed without transform, although
that feels a bit awkward.

Off-hand, I _think_ what you want is something that mirrors what the
gnulib 'configmake' module is able to do - it propagates the value of
${srcdir} and friends into a "configmake.h" header created at make time,
which is then compiled into the C code so that the program can learn the
values that were chosen at configure-time and/or overridden at make
time. It sounds like exposing the transformed program name via a make
rule that runs $program_transform_name and feeds the .h file for use by
the rest of the program would give your C code introspective access into
the transformed name it will be installed as. But your problem
statement didn't give me many details to know if I'm on the right track
for solving the actual problem you are facing.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Ludovic Courtès
2014-04-23 22:49:07 UTC
Permalink
Post by Eric Blake
Post by Ludovic Courtès
Hello,
$program_transform_name is apparently meant to be used in makefiles
What’s the recommended way to use it in configure.ac?
I'm not sure I follow the end goal. Why do you think you need to use it
from within configure.ac? Are you trying to set up a config.h
substitution that includes the transformed name that a program will be
installed under for use within the program? This is actually one use
case that I think really DOES make sense - there's discussion on the
grep mailing list about making 'egrep' a simple C program wrapper around
'grep -E', but if 'grep' is installed under a different name due to
program_transform_name, 'egrep' (or whatever actual name it gets
installed as) needs to know the transformed name to be exec'd.
I’m looking at an instance of the same problem: Guile comes with a
binary called ‘guild’ that calls out to the ‘guile’ program.

The approach I implemented some time ago (and which, ahem, happens to be
broken because of this very issue) is:

1. ‘configure’ (erroneously) computes the transformed ‘guile’ program
name and substitutes it;
http://git.savannah.gnu.org/cgit/guile.git/tree/configure.ac#n1606

2. ‘guild.in’ uses that value.
http://git.savannah.gnu.org/cgit/guile.git/tree/meta/guild.in#n5
Post by Eric Blake
One alternative would be to have 'grep' and 'egrep' both be shim
wrappers, that can be installed under any transformed name, which then
call ${libexecdir}/grep which gets installed without transform, although
that feels a bit awkward.
Indeed.
Post by Eric Blake
Off-hand, I _think_ what you want is something that mirrors what the
gnulib 'configmake' module is able to do - it propagates the value of
${srcdir} and friends into a "configmake.h" header created at make time,
which is then compiled into the C code so that the program can learn the
values that were chosen at configure-time and/or overridden at make
time. It sounds like exposing the transformed program name via a make
rule that runs $program_transform_name and feeds the .h file for use by
the rest of the program would give your C code introspective access into
the transformed name it will be installed as.
Doesn’t seem easily transposed to the situation above.
Post by Eric Blake
But your problem statement didn't give me many details to know if I'm
on the right track for solving the actual problem you are facing.
Sorry about that, I hope it’s clearer now.

Thanks,
Ludo’.
Eric Blake
2014-04-23 23:10:44 UTC
Permalink
I’m looking at an instance of the same problem: Guile comes with a
binary called ‘guild’ that calls out to the ‘guile’ program.
The approach I implemented some time ago (and which, ahem, happens to be
1. ‘configure’ (erroneously) computes the transformed ‘guile’ program
name and substitutes it;
http://git.savannah.gnu.org/cgit/guile.git/tree/configure.ac#n1606
2. ‘guild.in’ uses that value.
http://git.savannah.gnu.org/cgit/guile.git/tree/meta/guild.in#n5
I don't see an AC_CONFIG_FILES() in configure.ac that tries to create
guild solely at configure time. Therefore, I assume it's being created
at make time - but which Makefile.am is responsible for creating it?
_That_ rule would be the place to run $program_transform_name as part of
the creation process, rather than trying to shoehorn the conversion into
configure.ac.
Post by Eric Blake
Off-hand, I _think_ what you want is something that mirrors what the
gnulib 'configmake' module is able to do - it propagates the value of
${srcdir} and friends into a "configmake.h" header created at make time,
which is then compiled into the C code so that the program can learn the
values that were chosen at configure-time and/or overridden at make
time. It sounds like exposing the transformed program name via a make
rule that runs $program_transform_name and feeds the .h file for use by
the rest of the program would give your C code introspective access into
the transformed name it will be installed as.
Doesn’t seem easily transposed to the situation above.
Still seems like the right way to go. Observe how the automake project
does things. First, it sets up a convenience macro for building a file
with make-time substitution by using config.status for the easy
conversions that configure.ac could provide and make syntax for the
remaining conversions:

http://git.savannah.gnu.org/cgit/automake.git/tree/Makefile.am#n41

then uses that macro in several other locations:

http://git.savannah.gnu.org/cgit/automake.git/tree/bin/Makefile.inc#n57
http://git.savannah.gnu.org/cgit/automake.git/tree/lib/Automake/Makefile.inc#n48
Post by Eric Blake
But your problem statement didn't give me many details to know if I'm
on the right track for solving the actual problem you are facing.
Sorry about that, I hope it’s clearer now.
Yep, and I hope my ideas have been helpful in return.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Eric Blake
2014-04-24 12:41:01 UTC
Permalink
Post by Eric Blake
I don't see an AC_CONFIG_FILES() in configure.ac that tries to create
guild solely at configure time. Therefore, I assume it's being created
at make time - but which Makefile.am is responsible for creating it?
No, there was a ‘GUILE_CONFIG_SCRIPT’ invocation in configure.ac, which
wraps ‘AC_CONFIG_FILES’.
Post by Eric Blake
_That_ rule would be the place to run $program_transform_name as part of
the creation process, rather than trying to shoehorn the conversion into
configure.ac.
Yeah I realized we can easily do that in Makefile.am (and we already did
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=d80b6acf198dddc90eba40a83de36b65ddf9f0ac
Yay, glad we found a solution.
+ cat $(srcdir)/guild.in \
could be simplified to pass the input file directly as sed's stdin,
rather than through a pipe, as in:

$(SED) < $(srcdir)/guild.in -e ...

Also, two potential gotchas:

You may want to use s,[@]installed_guile[@],$$guile,g to match the style
used in the lines below (in fact, doing this is necessary to avoid false
positives if you use gnulib's syntax-check rule that checks for
unsubstituted @var@ in makefiles, where automake $(var) should have been
used instead - but in that case, you'd also want to use $(bindir)
instead of @bindir@ when determining $$guile).

Your use of s,,,g is risky. If $$guile contains any commas after the
user's program transform, or if @bindir@ contains any commas, you have
an invalid sed script. You could work around it by changing , to \,
with another sed invocation, if you are worried about this case.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Ludovic Courtès
2014-04-24 21:48:39 UTC
Permalink
Post by Eric Blake
Post by Eric Blake
I don't see an AC_CONFIG_FILES() in configure.ac that tries to create
guild solely at configure time. Therefore, I assume it's being created
at make time - but which Makefile.am is responsible for creating it?
No, there was a ‘GUILE_CONFIG_SCRIPT’ invocation in configure.ac, which
wraps ‘AC_CONFIG_FILES’.
Post by Eric Blake
_That_ rule would be the place to run $program_transform_name as part of
the creation process, rather than trying to shoehorn the conversion into
configure.ac.
Yeah I realized we can easily do that in Makefile.am (and we already did
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=d80b6acf198dddc90eba40a83de36b65ddf9f0ac
Yay, glad we found a solution.
+ cat $(srcdir)/guild.in \
could be simplified to pass the input file directly as sed's stdin,
$(SED) < $(srcdir)/guild.in -e ...
Right.
Post by Eric Blake
used in the lines below (in fact, doing this is necessary to avoid false
positives if you use gnulib's syntax-check rule that checks for
used instead - but in that case, you'd also want to use $(bindir)
OK. I think this is addressed with:

http://git.sv.gnu.org/cgit/guile.git/commit/?id=7a85f2b68ce8c7c8a28e6bde03b7c9da01004db5
Post by Eric Blake
Your use of s,,,g is risky. If $$guile contains any commas after the
an invalid sed script. You could work around it by changing , to \,
with another sed invocation, if you are worried about this case.
I’m not worried. ;-)

Thanks,
Ludo’.
Nick Bowler
2014-04-28 15:57:17 UTC
Permalink
Post by Eric Blake
Yeah I realized we can easily do that in Makefile.am (and we already
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=d80b6acf198dddc90eba40a83de36b65ddf9f0ac
Yay, glad we found a solution.
+ cat $(srcdir)/guild.in \
could be simplified to pass the input file directly as sed's stdin,
$(SED) < $(srcdir)/guild.in -e ...
For the record, this is more than just a simplification. The
useless use of cat was a real bug. In the event of an error
reading the input file, the pattern

cat input | sed ... > output

pattern will ignore the problem (probably producing an empty
output file).

Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Ludovic Courtès
2014-04-24 09:54:42 UTC
Permalink
Post by Eric Blake
Post by Ludovic Courtès
I’m looking at an instance of the same problem: Guile comes with a
binary called ‘guild’ that calls out to the ‘guile’ program.
The approach I implemented some time ago (and which, ahem, happens to be
1. ‘configure’ (erroneously) computes the transformed ‘guile’ program
name and substitutes it;
http://git.savannah.gnu.org/cgit/guile.git/tree/configure.ac#n1606
2. ‘guild.in’ uses that value.
http://git.savannah.gnu.org/cgit/guile.git/tree/meta/guild.in#n5
I don't see an AC_CONFIG_FILES() in configure.ac that tries to create
guild solely at configure time. Therefore, I assume it's being created
at make time - but which Makefile.am is responsible for creating it?
No, there was a ‘GUILE_CONFIG_SCRIPT’ invocation in configure.ac, which
wraps ‘AC_CONFIG_FILES’.
Post by Eric Blake
_That_ rule would be the place to run $program_transform_name as part of
the creation process, rather than trying to shoehorn the conversion into
configure.ac.
Yeah I realized we can easily do that in Makefile.am (and we already did
for another script), so I took that route:

http://git.savannah.gnu.org/cgit/guile.git/commit/?id=d80b6acf198dddc90eba40a83de36b65ddf9f0ac

Thanks,
Ludo’.
Bob Friesenhahn
2014-04-24 01:34:38 UTC
Permalink
Post by Ludovic Courtès
Hello,
$program_transform_name is apparently meant to be used in makefiles
--8<---------------cut here---------------start------------->8---
# Double any \ or $.
# By default was `s,x,x', remove it if useless.
ac_script='s/[\\$]/&&/g;s/;s,x,x,$//'
program_transform_name=`$as_echo "$program_transform_name" | sed "$ac_script"`
--8<---------------cut here---------------end--------------->8---
The doubled $ and \ make it impossible to use it directly within
configure.ac.
What’s the recommended way to use it in configure.ac?
This is what I do in GraphicsMagick:


#
# program_transform_name is formed for use in a Makefile, so create a
# modified version for use in a shell script.
configure_transform_name=`echo ${program_transform_name} | sed 's,\\$\\$,$,'`
GMDelegateDefault=`echo gm | sed ${configure_transform_name}`

As far as I am aware, it has never caused a problem.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Loading...