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? -Noah On Sat, Sep 7, 2013 at 10:38 AM, Noah Watkins <noah.watkins@xxxxxxxxxxx> wrote: > The non-recursive approach is interesting. I just had a quick look in > the tree I despise building the most, openmpi. It has 414 Makefile.am, > and uses recursive builds. The rebuild definitely takes a while to > visit all the sub-dirs, and is pretty annoying when my patience is low > :) > > And there is definitely a big +1 for avoiding the SUBDIRS > synchronization that slows down parallel make. > > 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. > > Given that the Ceph tree is relatively small (certinaly in comparison > to the 414 directory openmpi monster), are there benefits to the > non-recursive approach that are not performance related? > > - Noah > > On Sat, Sep 7, 2013 at 1:52 AM, Roald van Loon <roaldvanloon@xxxxxxxxx> wrote: >> Hi Noah, >> >> I just had a quick look at your build-refactor branch, and I think the >> greatest difference is that you use recursive builds and I don't. I'm >> more in favor of non-recursive builds using includes for a number of >> reasons. I think the most important reasons for me are; >> >> 1) recursive make leads to repetitive AM code >> 2) recursive make takes much more time to compile (as each directory >> needs to run configure and probably most important: you loose optimal >> -jX usage due to serialization) >> 3) non-recursive make knows all deps so rebuildings is much quicker >> (it only compiles/links what is required instead of entering all >> subdirs) >> >> There is ÏMHO one good reason to use recursive build, and that is >> separation of AM code. However, that can be easily achieved with >> includes and subdir-objects. >> >> I think this is the most important difference between your and my >> approach, and I like to hear your arguments for recursive builds so we >> can agree on recursive vs non-recursive make. Then I think it would be >> great to combine work! >> >> Roald >> >> On Fri, Sep 6, 2013 at 7:27 PM, Noah Watkins <noah.watkins@xxxxxxxxxxx> wrote: >>> Hi Roald, >>> >>> Sage just pointed me at your wip-automake branch. I also just pushed >>> up a branch, make-refactor, that I was hacking on a bit. Not sure how >>> much overlap there is, or if my approach is bogus, but I thought I'd >>> point it out to see if there is anything that can be combined :) >>> >>> -Noah >>> >>> On Wed, Aug 21, 2013 at 2:01 PM, Roald van Loon <roaldvanloon@xxxxxxxxx> wrote: >>>> On Wed, Aug 21, 2013 at 10:41 PM, Sage Weil <sage@xxxxxxxxxxx> wrote: >>>>> Yes, the Makefile.am is in dire need of from TLC from someone who knows a >>>>> bit of autotools-fu. It is only this way because in the beginning I >>>>> didn't know any better. >>>> >>>> Well, my average knowledge of autotools could at least fix this >>>> particular issue and clean up a bit more. It's a start I guess and >>>> helps me to continue my RGW things. >>>> >>>> I'll send out a pull request when I've found some time to implement >>>> and test this. >>>> >>>> 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
