Hello,
Thomas Martitz <ku...@rockbox.org> 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. :)
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 ..
> 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.
> %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
> As you can see, prog_a is compiled twice simply because the file name
> of the object file is different. This is a big problem.
>
> Now, one workaround would be to use _SHORTNAME
>
> $ echo %C%_prog_a_SHORTNAME = a >> root/a/Makefile.am.inc
>
> This very inconvinient, because it's only need as a workaround and is
> needed in every Makefile.am.inc. But worse, is also unworkable because
> _SHORTNAME does not work inside conditionals.
>
> if ENABLE_PROG_A
> include a/Makefile.am.inc
> end
>
> generates a Automake warning and generates an incorrect Makefile.in.
>
> We do require Automake conditionals like this because of our modularity.
>
>
> So my suggested fix is a new Automake option that applies the effect
> of _SHORTNAME automatically without a single line of _SHORTNAME, and
> without the defect when used inside a conditional. As a result, prog_a
> is built from prog_a-a.o regardless of where make was invoked, and is
> not built twice for two make invocations.
>
> The ability to use _SHORTNAME to override even that is, of course,
> still intact.
>
> In the end, if my use case above works, then this would seem to be
> like the ideal way to use Automake to me, since you can combine the
> best of both worlds (recursive and non-recursive Automake).
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
