On Wed, Jul 27, 2005 at 02:50:55PM -0700, Junio C Hamano wrote:
> Ryan Anderson <[EMAIL PROTECTED]> writes:
> > 003afd3ed1f83b4533b628182fa16c9ab0dc0467
> > diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/Makefile.inc
> > @@ -0,0 +1,50 @@
> > +MAN1_TXT=$(wildcard Documentation/git-*.txt)
> > +MAN7_TXT=Documentation/git.txt
> > +
> >...
> While I do not have strong objections to make the build process
> go faster, it is somewhat disturbing that the Makefile pieces
> maintained in subdirectories need to name things they touch
> using paths that include the subdirectory names.  I do not have
> a better alternative to suggest, though...
> I'd keep it in the proposed updates branch for now and wait for
> a bit until discussions on the list die out.

Sorry for taking so long to respond here - I've probably got 2 or 3
general replies to make on this thread, but basically, I truly intended
it as a RFC.

I think the best justification for the end goal of the process I was
thinking of starting is this:

        $ git clone -l git-linus git-example
        defaulting to local storage area
        0 blocks
        $ cd git-example
        $ git checkout
        $ ls | wc -l

I've been spending some time trying to think out what qualifies as a
"tool" and what is "core", etc.  I think it wouldn't be a bad idea to
think about restructuring things a bit so that all the little "helper"
scripts we keep adding don't fill up the top level directory.

I think I'm going to rethink this, a bit more.  I'm unhappy with how I
had to edit the sub-dir Makefiles to include directory names.  Sam, if
you happen to be reading this, feel free to help out!

I'm almost thinking that something like:

        PROGS := 
        SCRIPTS :=
        include x/Makefile.inc
        PROGRAMS += $(addprefix x/,$PROGS)
        ALL_SCRIPTS += $(addprefix x/,$SCRIPTS)

in the top-level Makefile might be the cleanest way to keep the
subdirectory ones simpler - but that's still somewhat distasteful, and
only fixes up one part of the problem.

Anyway, I'll come back to this later when I've got some of the follow-up
issues sorted out, like what to do with the directory structure.


Ryan Anderson
  sometimes Pug Majere
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to