----- Original Message ----- From: "Tom Tromey" <[EMAIL PROTECTED]> > > 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