Hello,
as Bruno said, ``GCS doesn't mandate that the build will break.''
I think we could be more careful and include some workarounds.
Generally, there are two problem situations:
Problem A:
a script.sh.in starts with
prefix = @prefix@
doc = @docdir@
this has to be fixed by adding `datarootdir = @datarootdir@' manually.
I made this change for several tools used in Gnome, but I'm sure there
are many tools which are not ready for this change, and will find out
only when their root file system will suddenly contain /doc, /man, /info,
and /locale.
Problem B:
On Tue, Apr 11, 2006 at 12:49:41PM -0700, Noah Misch wrote:
> Suppose you'll unpack and configure a software distribution bootstrapped with
> Autoconf 2.60 and Automake 1.9.6. You have Autoconf 2.59 and Automake 1.9.6
> installed. You edit some `Makefile.am', and the Automake-supplied rule calls
> `automake' and `config.status' to regenerate `Makefile.in' and then `Makefile'.
> The Autoconf 2.59 used to trace `configure.ac' will not recognize `datarootdir'
> as a substituted variable, so `Makefile.in' will have no `datarootdir =
> @datarootdir@'. `configure', generated by a newer Autoconf, will substitute
> `datadir = ${datarootdir}', yielding an empty `$(datadir)' in makefiles.
Until now, we always told people that no workaround for Problem A will be
available, and that Automake will just work.
But the Problem B has convinced me that it might be reasonable to implement
some workaround.
The woraround can:
1) either fix config files which don't contain the string "datarootdir"
2) or only for Automake-generated Makefile.in's (the exact criterium is
whether a corresponding *.am exists).
Alternative 2) is more invasive, yet it fixes Problem B. People would still
face Problem A, but as we used to say until now: ``hey, they use docdir
(infodir, ...) explicitly, outside of the makefile, so you have to take care
of the prerequisite config variables''.
Alternative 1) is ``less clean'', but it would fix also Problem A, so I think
it might be more practical.
So I suggest to adopt 1), and to drop it after a few years.
The proposal
http://lists.gnu.org/archive/html/bug-autoconf/2005-03/msg00027.html
goes in this direction, but needs more work, as Bruno said.
I might do that work when we come to an agreement what we want.
Have a nice day,
Stepan Kasal
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
