On 14 August 2014 00:56, David Beer <db...@adaptivecomputing.com> 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 <gavinsmith0...@gmail.com> > wrote: > > > On Thu, Jul 31, 2014 at 9:32 PM, David Beer <db...@adaptivecomputing.com > > > > 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
