Re: [RFC/PATCH 0/3] Thinning the git toplevel directory

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 23, 2011, 08:29 UTC
Message-ID: <20110223082929.GB30485@elie>
In-Reply-To: <20110223045143.GA11846@sigill.intra.peff.net>

Jeff King wrote:

> On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:

Show 6 quoted lines

>> I had an impression that "make -C lib/" would be one of the goals, iow,
>> when we split the directory structure, the next step would be to split the
>> top-level Makefile so that each directory is covered by its own Makefile,
>> just like Documentation/ is already usable that way.
>
> Ugh.

Two half-baked ideas:

 A. top-level Makefile generates GIT-BUILD-OPTIONS and does not do
    any work itself --- it just calls "make" in subdirectories to
    do the real work.  Other Makefiles slurp in

     - GIT-BUILD-OPTIONS, to get the build options
     - build-helpers/Makefile, for some pattern rules describing
       how to build things

    Benefit:

    GIT-BUILD-OPTIONS becomes the normal way to pass build options,
    so it is well tested and robust.

    Downsides:

    If the project grows too much, all those "make" calls start to
    take time.  It is possible for parallel "make" invocations to
    trample on each other's work if they are not well coordinated.

 B. top-level Makefile slurps in Makefiles from subdirs.  Other
    Makefiles would

     - check if basic rules (pattern rules and GIT-BUILD-OPTIONS
       generation) have been slurped in yet, and if not, include
       them;
     - check if build options have been slurped in yet, and
       if not, include GIT-BUILD-OPTIONS;
     - keep careful track of what directory "make" was run from; [*]
     - define variables listing targets to be built in this
       directory and rules describing how to build them.

    Benefit:

    GIT-BUILD-OPTIONS becomes the normal [...].  Single "make"
    process, fast and predictable.  "make" still works from
    subdirectories.

    Downside:

    [*] is a little hazy and sounds hackish.

I admit that I have some irrational excitement about a lib/ that could eventually be built and used separately from git. Mostly because I think it could encourage people to make lib/ code comprehensible and hard to misuse and to keep commands/ code minimal.

>           I really like that I can trust it to handle dependencies
> correctly, because it means I can bisect without resorting to "make
> clean" for each step.

Cross-directory dependencies have to be declared just as carefully as dependencies within a directory. I wonder if there is any reason not to make "make" under t/ imply "make -C .. all".

Sleepily, Jonathan