I'm particularly keen on doing what we can to reduce build time. I also agree there is a fair bit of tree restructuring that needs to be done. (For example, libcommon.la is huge and includes lots of stuff that most targets don't actually need; breaking this into smaller pieces would probably help.) Anyway, my gut says that starting with the includes seems like an easy incremental path to get us there. Then we can break out any fully modular components where it makes sense... sage On Sat, 7 Sep 2013, Roald van Loon 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
