Re: subdir-objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux