Re: Automake 1.14 and subdir-objects

[Václav Zeman]

On 14 August 2014 00:56, David Beer <address@hidden> wrote:

> Gavin,
>
> I am going to test out and see if the BUILT_SOURCES option works. Making a
> single Makefile would not be an option as there are over 500 Makefiles in
> my project and combining them into one would not be maintainable.
>

I am not sure if log4cplus is the best or even comparable show case, as it
is two orders of magnitude smaller than 500 Makefiles, but I will chime in
anyway.

For log4cplus, I have converted existing multiple Makefiles into a single
Makefile by using Make includes. The only problem, I can see in your
situation using this solution, is possible namespace pollution.


>
> I'm curious though - am I really the only person having this issue? How are
> people using unit tests with the new version of automake? It would seem
> that these changes make it very difficult for anyone who has unit tests in
> their project.
>
>
> On Thu, Jul 31, 2014 at 4:21 PM, Gavin Smith <address@hidden>
> wrote:
>
> > On Thu, Jul 31, 2014 at 9:32 PM, David Beer <address@hidden
> >
> > wrote:
> > > Gavin,
> > >
> > > Thanks for your reply. Here's a more specific breakdown of what the
> > project
> > > does:
> > >
> > > src/a/Makefile.am:
> > >
> > > a_SOURCES = bob.c tom.c
> > >
> > > src/b/Makefile.am:
> > >
> > > b_SOURCES = mary.c ../a/tom.c
> > >
> > > The purpose was so that tom.c would be recompiled with a different
> > > preprocessor switch. There were only a few files that failed for this
> > case,
> > > so I was able to work around this. The other case:
> > >
> > It is clearer now what you are trying to do. It might be worth noting
> > that you can specify target-specific compliation flags with variables
> > like a_CPPFLAGS and b_CPPFLAGS: however, this would normally be done
> > when a and b were targets defined in the same Makefile.am. This would
> > lead the created object files to have different names, so might work
> > in your case, but I believe that this kind of sharing of source files
> > between Makefile.am's is not really supported. I imagine there could
> > be problems with e.g. dependency tracking. Maybe consider using a
> > "non-recursive" build system with a single Makefile.am if it is
> > appropriate for your project.
> >
> > Another idea is to specify the files like tom.c in "src/b/Makefile.am" as
> >
> > BUILT_SOURCES=tom.c
> >
> > and then have a hand-written rule to copy the tom.c file into the
> > build directory for b, e.g.
> >
> > tom.c:
> >         cp $(top_builddir)/a/tom.c .
> >
> > (I haven't tested this.)
> >
>
>
>
> --
> David Beer | Senior Software Engineer
> Adaptive Computing
>



-- 
VZ