Jeff King wrote:
> On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html