I'm so excited to have a refactored automake setup :) I was just looking through build-refactor, and it doesn't really look like there is much that could be reused for the non-recrusive approach. I'll leave it up for a few days, just in case. On Sat, Sep 7, 2013 at 1:11 PM, Roald van Loon <roaldvanloon@xxxxxxxxx> wrote: > On Sat, Sep 7, 2013 at 7:47 PM, Noah Watkins <noah.watkins@xxxxxxxxxxx> wrote: >> Oh, and one question about the non-recursive approach. If I stick a >> Makefile.am in the test/ directory I can do things like: >> >> LDADD = all-the-test-dependencies >> >> and then avoid redundant per-target primaries like test_LDADD = (deps) >> $(LDADD), because it applies to everything in the Makefile. >> >> Is that possible with the include approach, or would a naked LDADD in >> an included Makefile fragment affect all the targets in the file >> including it? > > LDADD = xyz would indeed affect all targets. However, it's not > something you want to do anyway; using an _LDADD at a target is less > confusing and less prone to errors because you know exactly what > libraries a target needs. > > For instance, in test/Makefile.am you can have a debug target > depending on libglobal, which has dependencies set by libglobal > itself; > > CEPH_GLOBAL = $(LIBGLOBAL) $(PTHREAD_LIBS) -lm $(CRYPTO_LIBS) $(EXTRALIBS) > > And then in test/Makefile.am; > > ceph_test_crypto_SOURCES = test/testcrypto.cc > ceph_test_crypto_LDADD = $(CEPH_GLOBAL) > bin_DEBUGPROGRAMS += ceph_test_crypto > > And a unittest also depending on libosd; > > unittest_pglog_SOURCES = test/osd/TestPGLog.cc > unittest_pglog_LDADD = $(LIBOSD) $(CEPH_GLOBAL) > check_PROGRAMS += unittest_pglog > > However, libosd requires libos and libosdc, but that dependency is set > by libosd; > > LIBOSD += $(LIBOSDC) $(LIBOS) > > This way, you have the dependencies in the right place. With recusive > builds you'll need an "LDADD = libosd.la libosdc.la libos.la > libglobal.la $(PTHREAD_LIBS) -lm $(CRYPTO_LIBS) $(EXTRALIBS)", so > basically you're setting the dependencies of the required libraries in > the makefile requiring those libraries, which is IMHO way to complex. > >>> I think the benefits of using recursive builds are that it may be >>> familiar to the most people, it reflects the methods/suggestions in >>> the automake manual, and, most importantly, it would seem that its use >>> forces good decomposition where as a non-recursive approach relies on >>> guidelines that are easily broken. > > I don't know how which method is more familiar, but I personally think > that anyone understanding recursive automake is capable of > understanding a simple include :-) > > The decomposition is a valid argument. I think that there are some > libraries which might benefit from complete separation, like librados > and a "libceph_client" or something like it. Those can be separated, > but most other can't. The mon, mds, os, and osd subdirs have > inter-dependencies for instance. > > We might need to restructure the source tree anyway because at some > points it has grown messy (for instance, libcommon including stuff > from mds, mon but also from include). However, I think implementing a > recursive automake right now forces us to do two things at once; > cleanup the makefiles and do some restructuring in the subdirs. I > personally think it's best to start with cleaning up makefiles and use > an include per subdir, so we can restructure the subdirs into > segregated libraries later on. > > So I all boils down to; what to do first :-) Because I agree some > things are better of with recursive builds, but it might be wise not > to do that before we have revisited the source tree layout. > > Roald -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
