Re: [PATCH v3] new option: object-shortname

[Mathieu Lirzin]

Hello Thomas,

Thomas Martitz <address@hidden> writes:

> Am 03.03.2017 um 16:06 schrieb Mathieu Lirzin:
>>
>> Thomas Martitz <address@hidden> writes:
>>
>>> My use case is to make use of non-recursive Automake for faster build
>>> times and global dependencies, while also generate subdirectory
>>> Makefiles for the convenience of my co-workers, so that they can keep
>>> running make only in the directories they work in (they do since since
>>> 15-20 years because our build system always used recursive Automake. I
>>> can't just remove recursive Automake).
>> Having both recursive and non-recursive makefiles for the same files in
>> the same project is somewhat weird.  :)
>
> But IMO it works really nice (with my patches). It gives the best of
> non-recursive
> automake while maintaining strong modularity per subdirectory.
>
>> If the problem is that your co-workers want to be able to type 'make' in
>> the repository they are in, what about generating wrapper Makefiles
>> containing:
>>
>>    all:
>>      make -C ..
>
> This is not the same. It weakens modularity of the subdirectories
> (can't be built individually, e.g. in git submodule scenarios) and
> needs manual tweaking for each target.
>
> The "all" target isn't sufficient, there are lots of custom targets
> (some of which are recursive), then there is also other
> Automake-specific stuff like script files, EXTRA_DIST, CLEANFILES
> etc. which has to be handled. The subdirectories must contain Automake
> Makefile fragments as well.

If this is not sufficient I would suggest either taking some time to
educate your co-worker about the benefits of non-recursive makefiles and
the '--directory/-C' feature of Make which allow them to invoke 'make'
even when they are not in the top build directory.  If that's not an
option, then I would recommend switching back to a recursive makefile.

>>> So the setup looks like this:
>>>
>>> $ cat root/Makefile.am
>>> include a/Makefile.am.inc
>>> include b/Makefile.am.inc
>>>
>>> $ cat root/a/Makefile.am
>>> include Makefile.am.inc
>>>
>>> $ cat root/a/Makefile.am.inc
>>> bin_PROGRAMS += %D%/prog_a
>>                 ^^^
>> You must initialize bin_PROGRAMS before using "+=" on it.
>
> Yes, of course. My mail did not aim to present a valid setup. It was
> shortened to show the key points.

OK, np.

>>> %C%_prog_a_SOURCES = a.c
>>> %C%_prog_a_CFLAGS = $(AM_CFLAGS)
>>>
>>> $ cat root/b/Makefile.am
>>> include Makefile.am.inc
>>>
>>> $ cat root/b/Makefile.am
>>> bin_PROGRAMS += %D%/prog_b
>>> %C%_prog_b_SOURCES = b.c
>>>
>>>
>>> This generates:
>>> root/Makefile
>>> root/a/Makefile
>>> root/b/Makefile
>>>
>>> where root/Makefile does *not* do recursive automake but knows about
>>> all libs and programs.
>>>
>>> This sort of works today, but there is one big problem (assume
>>> subdir-objects is used)
>>>
>>> $ cd root; make a/prog_a
>>> # this compiles prog_a using a/a_prog_a-a.o
>>>
>>> $ cd root/a; make prog_a
>>> # this compiles prog_a _again_, using a/prog_a-a.o
>> Maybe I have misinterpreted some of your instructions but this command
>> fails for me with:
>>
>>    make: *** No rule to make target 'a.c', needed by 'prog_a-a.o'.  Stop.
>>
>> I have created a git repository that will let you reproduce what I have:
>>
>>    https://notabug.org/mthl/automake-shortname
>>
>> Please let me know what I missed
>
> I have created a fork of your repository, which completes the setup:
>
>   https://notabug.org/kugel/automake-shortname

It works for me now.  Thanks.

> The last commit adds the option, so you can see the effect.
>
> Without the option, "make && make -C a" compiles a.c twice, to two
> differently named object files (a/a_prog_a-a.o and a/prog_a-a.o). With
> the option only one compilation takes place.
>
> Please consider my patch. It's a small change to Automake but
> the effect makes a huge difference to us.

Sorry, but I am still not convinced.  While I agree it is only a small
change regarding the amount of code, this new option has to be
documented and maintained.  Beyond optimizing the support of recursive
and non-recursive makefiles providing the same targets which is a hack
that can't reasonably be documented in Automake manual, I can't find a
reason to justify its presence.

Having said that I would happily accept a patch that fixes the usage of
%C%, %D% in _SHORTNAME, which beyond the inconvenience of having to
define it for each program or library, would achieve your goal of not
compiling some files twice when invoking make in different locations.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37