Karl,
Sorry for the late reply.
Here are the sequence of the commands that show the issue described:
*Test use of relative path to identify external lib:*
$ tar xfz autotool-bug-rel.tar.gz
$ cd autotool-bug/proj
$ ./bootstrap.sh
$ ./configure --with-mylib=../lib
$ make
$ ls -la src/.deps # Note the testApp-main.Po
$ ls -la ../lib # Note the .deps and .dirstamp
$ ls -la ../lib/.deps # Note the testApp-mylib_log.Po and
.dirstamp
$ cd ../..
$ mv autotool-bug autotool-bug-rel # Move it out of the way
------------------------------
*Test use of absolute path to identify external lib:*
$ tar xfz autotool-bug-abs.tar.gz
$ cd autotool-bug/proj
$ ./bootstrap.sh
$ ./configure --with-mylib=../lib
$ make
Making all in src
make[1]: Entering directory '/home/fabrizio/temp/autotool-bug/proj/src'
Makefile:353:
/home/fabrizio/temp/autotool-bug/lib/.deps/testApp-mylib_log.Po: No such
file or directory
make[1]: *** No rule to make target
'/home/fabrizio/temp/autotool-bug/lib/.deps/testApp-mylib_log.Po'. Stop.
make[1]: Leaving directory '/home/fabrizio/temp/autotool-bug/proj/src'
Makefile:331: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
$ ls -la src
total 72
drwxr-xr-x 4 fabrizio fabrizio 4096 Dec 7 07:33 .
drwxr-xr-x 4 fabrizio fabrizio 4096 Dec 7 07:33 ..
drwxr-xr-x 2 fabrizio fabrizio 4096 Dec 7 07:33 .deps
drwxr-xr-x 3 fabrizio fabrizio 4096 Dec 7 07:33 home ######
???????
-rw-r--r-- 1 fabrizio fabrizio 83 Sep 24 2019 main.c
-rw-r--r-- 1 fabrizio fabrizio 22554 Dec 7 07:33 Makefile
-rw-r--r-- 1 fabrizio fabrizio 106 Nov 24 14:01 Makefile.am
-rw-r--r-- 1 fabrizio fabrizio 22001 Dec 7 07:33 Makefile.in
--------------------------------
*Differences between the two use case:*
$ diff configure.ac ../../autotool-bug-rel/proj/configure.ac
28c28
< dnl MYLIB_PATH=`realpath --relative-to src "${MYLIB_PATH}"`
---
> MYLIB_PATH=`realpath --relative-to src "${MYLIB_PATH}"`
31c31
< MYLIB_PATH=`readlink -f ${MYLIB_PATH}`
---
> dnl MYLIB_PATH=`readlink -f ${MYLIB_PATH}`
In the 'relative path' case, MYLIB_PATH uses realpath to calculate ../lib
relative to the 'src' directory.
In the 'absolute path' case, MYLIB_PATH contains the full absolute path of
the ../lib.
Note that in the 'absolute path' case, there is a new 'home' directory
under 'src' containing the full tree to the .Po file from the library.
Just try to run those commands and unless is something simple to address,
please close the ticket and let's move on.
I understand that this situation is not really a representative use case
and is not supported.
Regards,
Fabrizio
On Sat, Nov 28, 2020 at 9:46 PM Karl Berry <k...@freefriends.org> wrote:
> Hi Fabrizio - unfortunately, your examples work for me, in that I can
> run, in the proj/ directory, either
> ./configure --with-mylib=../lib
> or
> ./configure --with-mylib=/abs/path/to/autotool-bug/lib
>
> and then make, in either the proj/ directory or the proj/src
> subdirectory, and it all completes successfully.
> All this with both your tarballs. So I remain unclear as to what you're
> doing. Sorry.
>
> Since configure is run in the proj/ directory, not proj/src, it seems
> evident that any method, absolute or relative, which specifies mylib to
> be the ../../lib directory cannot work, because that directory will not
> exist relative to proj/.
>
> Can you tell me exactly what commands you are running, starting with
> tar xf <tarfile> (and which <tarfile> to use), to see the problem?
> Just one sequence to reproduce the problem is enough.
>
> a wrong directory: proj/src/home/fabrizio/test/lib/.deps
>
> In any event, this blind concatenation of paths surely looks
> wrong. Maybe if the path (whatever it is) is absolute, the concatenation
> should be avoided.
>
> Unfortunately, I cannot discern where the computations are happening,
> whether it's somewhere in the depcomp script or the Makefile that's
> calling it.
>
> In addition, I agree with Hans-Bernhard that using a directory outside
> of top_srcdir is not exactly supported, although evidently it works in
> some cases. Even if it cannot be handled properly, perhaps a real error
> message could be given, or at least the deficiency documented.
>
> Thanks,
> Karl
>
