On 03/11/2013 08:45 PM, Bert Wesarg wrote:
> [ Removing patches@ and 13524@ from Cc. ]
>
I think it's better if this discussion remains public. I'm re-adding
automake-patches, and since you have apparently uncovered a new bug
in automake, I'm also re-adding bug-automake, so that this discussion
will be registered in the bug tracker.
> On Mon, Mar 11, 2013 at 7:58 PM, Stefano Lattarini
> <stefano.lattar...@gmail.com> wrote:
>> On 03/11/2013 01:05 PM, Bert Wesarg wrote:
>>> On Mon, Mar 11, 2013 at 10:46 AM, Stefano Lattarini
>>> <stefano.lattar...@gmail.com> wrote:
>>>> On 03/11/2013 10:31 AM, Bert Wesarg wrote:
>>>>> I have the impression that variable references in filenames aren't
>>>>> supported anyway, right?
>>>>>
>>>> Wrong, actually.
>>>
>>> But when I prefixing a source file with '$(src)/' and use
>>> subdir-objects then I get something like this in the Makefile.in
>>>
>>> $(src)/test-test.o: $(src)/test.c
>>>
>>> And after a configure I get an '$(src)' directory in my build dir.
>>>
>> Yes -- and this is intended behavior of subdir-objects. Why do you
>> think Automake is acting wrong? (Honest question, I might be missing
>> something here ...)
>
> Why would I want a directory named '$(src)' in my build directory?
>
Oh, but $(src) would of course be expanded at make runtime, not used
literally.
> If anything than this variable should be resolved.
>
And it isn't? That would be a bug. (Apparently, from what I read
below, this indeed the case, sadly).
> Anyway, when running make I get:
>
> Makefile:299: .deps/test-test.Po: No such file or directory
> make: *** No rule to make target `.deps/test-test.Po'. Stop.
>
> Because the file '.deps/test-test.Po' is here
> '$(src)/.deps/test-test.Po', literally. So maybe automake is not to
> blame here but the autoconf machinery which creates the dummy .Po
> files at configure time.
>
Ah, I think I'm beginning to understand the issue. This appears to be
an actual bug. And since that configure machinery comes from Automake
provided macros, it is an Automake bug :-(
Since I'm short of time right now, I won't be able to pursue this
issue shortly, nor write a proper test case. If you can and want
offer one, that would be great; otherwise, I hope I'll be able to
write one myself in reasonable time.
And here is a quick and brutal proposal to resolve the issue:
- since it's not a regression, simply keep the buggy behaviour
in the 1.x Automake series;
- from Automake 2.0 onward, only enable the automatic dependency
tracking if GNU make is used; we can thus assume the presence
of the "-include" directive (which ignore non-existing files,
rather than punting), and its use will allow us to get rid of
the configure time machinery for the initial creation of .deps
directories (this has already been done in Automake-NG, and has
worked beautifully so far).
I think the approach described above is acceptable because automatic
dependency tracking is important only for developers or power users,
and those should be using GNU make anyway.
> Actually, I first prefixed it with '$(srcdir)/',
>
> test_SOURCES = $(srcdir)/test.c
>
> just to see the generated make rule:
>
> $(srcdir)/test-test.o: $(srcdir)/test.c
>
> which would completely circumvent VPATH builds, would it?
>
Yes. The answer is: don't use $(srcdir) in your source files -- they
will be picked up anyway thanks to VPATH. A better and more friendly
solution would be to enhance Automake so that it can understand that
the object file generated from a '$(srcdir)/foo.c' is to be placed in
the build directory even when the 'subdir-object' option is active --
which is clearly the right thing to do. As usual, patches welcome
(just having a test case exposing the issue would be a good start).
> But than I
> saw the '$(srcdir)' directory which just looks very odd. Than I used
> another variable to see the same behavior.
>
> I tried playing with this after you mentioned to make subdir-objects
> the default sometime in the future and our automake files use
> extensively variable references in the source file names.
>
And it's very appreciated that you have taken the time to bring these
issues up. Thank you.
Best regards,
Stefano
