Re: PR224

[Robert Collins]

----- Original Message -----
From: "Tom Tromey" <address@hidden>
>
> I looked at this PR.  Why do you want this change?
>
> Right now if you write:
>
>     AUTOMAKE_OPTIONS = subdir-objects
>     bin_PROGRAMS = wish
>     wish_SOURCES = generic/a.c generic/b.c
>
> ... you end up with `.deps/generic/a.Po'.
> The PR asks for `generic/.deps/a.Po'.

Yes. Simply put this breaks with any dependencies not in the current
sub-tree. And that is problematic. It _also_ leads to multiple .Po files
for a single source file, scattered around the build environment, which
'generic/.deps/a.Po' avoids....

if you write
==
  AUTOMAKE_OPTIONS = subdir-objects
  noinst_PROGRAMS = test1
  wish_SOURCES = $(top_srcdir)/src/a.c $(top_srcdir)/src/b.c test1.c
==
in $(top_srcdir)/test/Makefile.am

you end up with
.deps/../../top_srcdirname/src/a.Po
where you need one of
.deps/../../../top_srcdirname/src/a.Po
or (better IMO)
../../top_srcdirname/src/.deps/a.Po

> Does it make a difference?

Yes. Turning on subdir-objects breaks makefiles such as the above. And
yes convenience libraries can help.

> As I recall the reason things are done this way is that it is a little
> faster to compute the .Po file name when we don't have to change the
> directories.

I can accept that. Generating .deps/basename is easier. However simply
prepending the src->build translated path to the name ends up with the
correct result.

> On the other hand, changing this might let us have `..' path
> components.  I don't see that as a very high priority, but I'd welcome
> a patch.

Heh. Here is the original email
(http://sources.redhat.com/ml/automake/2001-08/msg00125.html) and your
response (http://sources.redhat.com/ml/automake/2001-08/msg00145.html)
(which I quote
"Actually, while this probably should be valid, right now it isn't.
Could you submit a PR for this?" :].

I'm not fluent with perl (and the support functions in automake) or I
would look closer at doing this myself (I've generated the odd automake
patch before).

Rob