Re: generating pc file
I said: 2. If the GNU standards stay as-is, the autotools need to make this easy to do, Bruce Korb: And that is easy to do. Just bundle up the configured substitutions into a macro a la adding this to Makefile.in: WHATEVERINAMEDIT = \ prefix=@prefix@ \ [...] ... Anyway, usage of WHATEVERINAMEDIT is quite straight forward: $(WHATEVERINAMEDIT) $(SHELL) script-du-jour I don't think that is easy to do at all, compared to the simplicity of the task. That's a bunch of lines already, and even then it omits the code for script-du-jour, which would add more code. Creating files with substitutions at build time should require exactly ONE simple line in .ac or .am to list the files to be generated. Anything more than one line, like the above, is overly complicated for such a common and trivial task. As a *practical* matter, this means that currently developers have only 2 reasonable choices for this common case: AC_CONFIG_FILES (wrong but works) and AX_CREATE_PKGCONFIG_INFO (less wrong and works). I'll accept invoking a predefined macro as being one simple line from the user's point of view, so I'll continue to recommend AX_CREATE_PKGCONFIG_INFO in my tutorial materials until someone comes up with something better. I'd love to see an AC_CONFIG_FILES_BUILD_TIME([filelist...]) or some such. I don't have the time to write that right now, but hopefully you see what I think is wrong with the current situation. And maybe I can convince someone else to write it...! --- David A. Wheeler ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
Bob Friesenhahn: Yes. The only make-time override which has any business being used as part of a formal build process is DESTDIR used with 'make install'. Anything else is a hack. :-) You may think so, but this capability is a clearly-documented promised capability under the GNU standards. And a lot of people support it. I even have a lot of crufty sed invocations in a shell script written specifically to make this happen. So either one of the following needs to happen: 1. The GNU standards need to be modified so that this is no longer the expectation, and that configure-time is enough. I'm *okay* with that kind of change, but it needs to be actually changed, so that users know that this is no longer a reasonable expectation. 2. If the GNU standards stay as-is, the autotools need to make this easy to do, or many programs will continue to fail to do it correctly. --- David A. Wheeler ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
On Fri, 21 Sep 2012, David A. Wheeler wrote: Bob Friesenhahn: Yes. The only make-time override which has any business being used as part of a formal build process is DESTDIR used with 'make install'. Anything else is a hack. :-) You may think so, but this capability is a clearly-documented promised capability under the GNU standards. It may be a promised capability, but there are no formal tests for it, and hardly any projects would think to add such tests. Anything which is not specifically periodically tested is usually broken. The common Automake 'make distcheck' test does not verify that the project correctly obeys the many make/environment variables which might be specified. The only make/shell variable it verifies is DESTDIR. Projects often break other standard capabilities as well. For example, a great many projects (including highest-profile GNU projects) break the function of specifying parameters like CFLAGS, LDFLAGS, CPPFLAGS to configure as described in the standard INSTALL file. To me, failing to support a configure-time specification is worse than failing to support an over-ride specified at make time via an environment variable or make argument. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
On 09/21/12 11:14, David A. Wheeler wrote: 2. If the GNU standards stay as-is, the autotools need to make this easy to do, And that is easy to do. Just bundle up the configured substitutions into a macro a la adding this to Makefile.in: WHATEVERINAMEDIT = \ prefix=@prefix@ \ [...] Russ proposed a slightly different variation on that that amounted to the same thing. Another variation is to get the make program to just export environment variables that correspond to the configured values. I think that would be nice, but you'd have to invent syntax to tell make This is an exported value because that won't happen by default. Anyway, usage of WHATEVERINAMEDIT is quite straight forward: $(WHATEVERINAMEDIT) $(SHELL) script-du-jour and that script can be as trivial as a cat command reading from a here doc. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
Russ Allbery: I suppose I should have been clearer. I believe the method using sed is correct, and generating the file at Autoconf time is not as correct (although it's workable). I agree that generating .pc files at configure time is the wrong time; it should be done at make time. Regarding AX_CREATE_PKGCONFIG_INFO, he says: That macro has gotten better (it at least doesn't put the user's CPPFLAGS and LDFLAGS into the *.pc file like it used to), but I still would not recommend people use it... I use the sed approach, but it's painful to create and maintain. Every time you need another variable substitution, you gotta modify it. Since it's not trivial, many people won't do it. I currently recommend that people use AX_CREATE_PKGCONFIG_INFO, because they're far more likely to actually do it, and it maintains. This is a need for *every* library. Shouldn't a trivial capability to generate replacements, at make time, be built into autoconf or automake?!? It might be something that needs coordination between them. Until there is, it seems that AX_CREATE_PKGCONFIG_INFO is the best available approach, since it's the closest-available to correct that's easy to do. --- David A. Wheeler ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
On 2012-09-20 12:05 -0400, David A. Wheeler wrote: Russ Allbery: I suppose I should have been clearer. I believe the method using sed is correct, and generating the file at Autoconf time is not as correct (although it's workable). I agree that generating .pc files at configure time is the wrong time; it should be done at make time. Regarding AX_CREATE_PKGCONFIG_INFO, he says: That macro has gotten better (it at least doesn't put the user's CPPFLAGS and LDFLAGS into the *.pc file like it used to), but I still would not recommend people use it... I use the sed approach, but it's painful to create and maintain. Every time you need another variable substitution, you gotta modify it. Since it's not trivial, many people won't do it. I currently recommend that people use AX_CREATE_PKGCONFIG_INFO, because they're far more likely to actually do it, and it maintains. This is a need for *every* library. Shouldn't a trivial capability to generate replacements, at make time, be built into autoconf or automake?!? It might be something that needs coordination between them. Until there is, it seems that AX_CREATE_PKGCONFIG_INFO is the best available approach, since it's the closest-available to correct that's easy to do. I wonder if all that's needed is an option to override a configure- time decision when you run config.status? Then you could use the config.status machinery to perform substitutions by calling it at make time, and not have to maintain your own code that does the same thing. Then the makefile could have a rule (either automatically provided by Automake or hand-written by the user) that looks something like: libfoo.pc: libfoo.pc.in $(top_builddir)/config.status $(SHELL) $(top_builddir)/config.status --file=$@ \ --override prefix=$(prefix) which behaves exactly as usual except that @prefix@ is replaced with the make-time expansion of $(prefix) instead of what it normally would be (obviously the actual command would need an override for each installation directory variable). Such a feature could be a bit tricky, though, as it looks like all this information gets hardcoded into a big giant string in the script. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
Nick Bowler nbow...@elliptictech.com writes:
I wonder if all that's needed is an option to override a configure- time
decision when you run config.status? Then you could use the
config.status machinery to perform substitutions by calling it at make
time, and not have to maintain your own code that does the same thing.
Then the makefile could have a rule (either automatically provided by
Automake or hand-written by the user) that looks something like:
config.status also doesn't fully expand the variables, though, which is
something that you'd want for this sort of application. Otherwise, you
have to know all of the possible ways in which one variable could
reference another so that you can set all of them (and you can only write
files that have a variable resolution system, although pkg-config does
have one). Note that the user can do things like
--libdir='${datadir}/foo' at configure time, even if it's not common.
So yes, you could use config.status, but only if it also had a flag that
said to fully expand the variables before substituting them in, and I
suspect that's a fair amount of change to the script.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
On 2012-09-20 13:14 -0700, Russ Allbery wrote:
Nick Bowler nbow...@elliptictech.com writes:
I wonder if all that's needed is an option to override a configure- time
decision when you run config.status? Then you could use the
config.status machinery to perform substitutions by calling it at make
time, and not have to maintain your own code that does the same thing.
Then the makefile could have a rule (either automatically provided by
Automake or hand-written by the user) that looks something like:
config.status also doesn't fully expand the variables, though, which is
something that you'd want for this sort of application. Otherwise, you
have to know all of the possible ways in which one variable could
reference another so that you can set all of them (and you can only write
files that have a variable resolution system, although pkg-config does
have one). Note that the user can do things like
--libdir='${datadir}/foo' at configure time, even if it's not common.
Ah, but make will fully expand the variables.
Suppose you have:
prefix = /usr
datadir = ${prefix}/share
then with my example make rule extended to include an override for
datadir, it would have
$(SHELL) $(top_builddir)/config.status --override datadir=$(datadir)
...
and config.status will see
--override datadir=/usr/share
so it would replace @datadir@ with /usr/share.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
Nick Bowler nbow...@elliptictech.com writes:
On 2012-09-20 13:14 -0700, Russ Allbery wrote:
config.status also doesn't fully expand the variables, though, which is
something that you'd want for this sort of application. Otherwise, you
have to know all of the possible ways in which one variable could
reference another so that you can set all of them (and you can only
write files that have a variable resolution system, although pkg-config
does have one). Note that the user can do things like
--libdir='${datadir}/foo' at configure time, even if it's not common.
Ah, but make will fully expand the variables.
Only the ones that you're explicitly overriding. What about all the other
variables that you may want to use with the same values that were set
during configure?
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
On 2012-09-20 13:43 -0700, Russ Allbery wrote:
Nick Bowler nbow...@elliptictech.com writes:
On 2012-09-20 13:14 -0700, Russ Allbery wrote:
config.status also doesn't fully expand the variables, though, which is
something that you'd want for this sort of application. Otherwise, you
have to know all of the possible ways in which one variable could
reference another so that you can set all of them (and you can only
write files that have a variable resolution system, although pkg-config
does have one). Note that the user can do things like
--libdir='${datadir}/foo' at configure time, even if it's not common.
Ah, but make will fully expand the variables.
Only the ones that you're explicitly overriding. What about all the other
variables that you may want to use with the same values that were set
during configure?
Indeed, this is true.
However, is this really a problem in practice for anything but
installation directory variables? All installation directory variables
are supposed to be overridable at make time, so they will all need
explicit overrides (at least all the ones you are intending to
substitute), and therefore they will all be fully expanded.
Other than installation directory variables (which need to be left
unexpanded so that make-time overrides work), if you need some
transformation done to a substituted variable at configure time, then
you should do that transformation at configure time. Then config.status
will work.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
Nick Bowler nbow...@elliptictech.com writes: However, is this really a problem in practice for anything but installation directory variables? All installation directory variables are supposed to be overridable at make time, so they will all need explicit overrides (at least all the ones you are intending to substitute), and therefore they will all be fully expanded. Ah, true. This means that you're always going to pass quite a long list of overrides to config.status, though, which sort of comes back to my feeling that it would be nice if Automake supported this sort of thing natively rather than requiring that people roll it themselves. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
On Thu, 20 Sep 2012, Nick Bowler wrote: However, is this really a problem in practice for anything but installation directory variables? All installation directory variables are supposed to be overridable at make time, so they will all need explicit overrides (at least all the ones you are intending to substitute), and therefore they will all be fully expanded. Regardless of what is supposed to be supported, make time overrides are not as reliable as settings from the configure script since it depends on the same overrides being applied each time that make is executed. Any variance will not be detected by make, and so already built build products won't be re-built and so they will be wrong. It is possible that make is executed several/many times during a build, and also at install time. That is why I use configure and config.status substitutions to build the .pc file for my package. :-) Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: generating pc file
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: Regardless of what is supposed to be supported, make time overrides are not as reliable as settings from the configure script since it depends on the same overrides being applied each time that make is executed. Any variance will not be detected by make, and so already built build products won't be re-built and so they will be wrong. It is possible that make is executed several/many times during a build, and also at install time. That is why I use configure and config.status substitutions to build the .pc file for my package. :-) Thus making the problem much better by *guaranteeing* that the *.pc file is wrong if there are any make-time overrides! Er, wait :) -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
