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

[Thomas Martitz]

Hello Mathieu,

thank you for your timely reactions. This is really positive after 
trying to get any feedback for over a year.

Am 07.03.2017 um 18:44 schrieb 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.

On the other hand, why not allow Automake to cover more use cases with 
simple enhancements?


> > 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.


Alright, this makes me bitter, since I'm trying to get feedback on this 
for more than a year, and the previous indications seemed like the 
change would be OK (e.g. [1])

Let me try to come from a different direction and completely ignore my 
use case. Even for normal, non-recursive use, Automake generates 
unwieldy long file names. Consider this:

$ cat root/Makefile.am:
AUTOMAKE_OPTIONS = subdir-objects
include 
projects/fancy_product/lib/config_parser/test/regression_tests/Makefile.inc

$ cat 
root/projects/fancy_product/lib/config_parser/test/regression_tests/Makefile.inc

bin_PROGRAMS = helper
helper_SOURCES = %D%/helper.c
helper_CFLAGS = $(AM_CFLAGS)


Running make generates:
root/projects/fancy_product/lib/config_parser/test/regression_tests/projects_fancy_product_lib_config_parser_test_regression_tests_helper-helper.o

This is completely unnecessary, as there is no chance that objects 
overwrite each other (due to subdir-objects, this is a problem with 
non-subdir-objects, if different subdirs have source files with the same 
name). It can also create real problems, which is why _SHORTNAME exists 
at all.

It would be far more useful if objects would generally have shorter file 
names under subdir-objects, i.e. 
root/projects/fancy_product/lib/config_parser/test/regression_tests/helper-helper.o 
(helper- prefix due to target specific CFLAGS).

So if it's a problem to support this as an option, then I would like to 
ask to simply switch the generated file names unconditionally when 
subdir-objects is enabled (this was already suggested in [1]). I was 
afraid of changing any existing behavior, this is why I decided for a 
new opt-in behavior. But I don't think the object file names are 
documented such that they are not allowed to change. I would like to 
prepare that change if it's OK for you.


> 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.

This is truly very hard, maybe impossible. I have looked into it [1]. 
The core issue is that _SHORTNAME, unlike all other variables, is 
already evaluated when generating Makefile.in., as the make targets are 
already completed. Automake conditionals can only comment out lines in 
the Makefile, they cannot make complex changes like renaming make 
targets or dependencies or process recipes.

It would be a major change, if possible at all, under the current 
architecture of Automake.

[1] http://lists.gnu.org/archive/html/automake/2016-01/msg00011.html
[2] http://lists.gnu.org/archive/html/automake/2016-01/msg00007.html

Best regards.