Re: automake datadir files location and versioning

[Jens Petersen]

Tom Tromey <address@hidden> writes:

> >>>>> "juhp" == Jens Petersen <address@hidden> writes:
> 
> juhp> While the recent versioning of automake is a good thing, I
> juhp> guess it introduces some issues with backward compatibility.
> juhp> For example quite a few packages/people assume that
> juhp> config.{guess,sub} are located in /usr/share/automake (not
> juhp> /usr/share/automake-<apiversion>).  With the introduction of
> juhp> versioning they will no longer be able to find those files.
> 
> juhp> While I know that there is better and official way for
> juhp> packages to get those files (automake -a), any thoughts on
> juhp> this issue?
> 
> My first inclination is to let them fend for themselves.  This
> directory has always been an implementation detail of automake.  I
> don't think we've ever documented or advertised its contents, and
> we've always felt free to change it at will.
> 
> Can you give an example of what programs rely on this?
> I'm curious to know what we might be breaking.

[The main problem seems to be projects that use symlinks for
config.sub, install-sh, missing, mkinstalldirs, etc.
Examples include sgml-common and docbook-utils (both in
ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES/),
though I am sure there are lots of other examples.  In fact
I just realised that some of my own projects do this.]

But actually it seems that automake is to blame here!  Try:

% mkdir test; cd test
% touch configure.ac Makefile.am
% automake -a
% ls -l
total 0
-rw-r--r--    1 petersen petersen        0 Jan 22 17:39 Makefile.am
-rw-r--r--    1 petersen petersen        0 Jan 22 17:39 configure.ac
lrwxrwxrwx    1 petersen petersen       34 Jan 22 17:39 install-sh -> 
/usr/share/automake/install-sh
lrwxrwxrwx    1 petersen petersen       31 Jan 22 17:39 missing -> 
/usr/share/automake/missing
lrwxrwxrwx    1 petersen petersen       37 Jan 22 17:39 mkinstalldirs -> 
/usr/share/automake/mkinstalldirs

Not sure what to do about this...

Jens