From: Ryan Anderson <ryan@michonline.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC] "Recursive Make considered harmful"
Date: Fri, 29 Jul 2005 02:53:35 -0400 [thread overview]
Message-ID: <20050729065335.GA32263@mythryan2.michonline.com> (raw)
In-Reply-To: <7v4qafrk8w.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 27, 2005 at 02:50:55PM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> 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
154
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
next prev parent reply other threads:[~2005-07-29 6:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-27 8:39 [PATCH/RFC] "Recursive Make considered harmful" Ryan Anderson
2005-07-27 14:25 ` A Large Angry SCM
2005-07-27 14:37 ` Kirby C. Bohling
2005-07-27 15:32 ` A Large Angry SCM
2005-07-27 21:50 ` Junio C Hamano
2005-07-27 22:07 ` A Large Angry SCM
2005-07-28 7:51 ` Petr Baudis
2005-07-28 9:40 ` Matthias Urlichs
2005-07-28 7:04 ` Junio C Hamano
2005-07-28 7:45 ` Matthias Urlichs
2005-07-28 16:38 ` Junio C Hamano
2005-07-28 17:09 ` A Large Angry SCM
2005-07-29 6:53 ` Ryan Anderson [this message]
2005-07-29 7:31 ` Sam Ravnborg
2005-07-29 7:46 ` Petr Baudis
2005-07-29 9:12 ` Timo Hirvonen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050729065335.GA32263@mythryan2.michonline.com \
--to=ryan@michonline.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).