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.
From: A Large Angry SCM <hidden> Date: 2016-06-15 22:42:02
Junio C Hamano wrote:
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...
For a project the size of Git, is there any real benefit to this change?
Besides pathing issues, you also have to aware that all identifiers in
the included makefile fragments will be global.
I don't object to the change but I see it as trading one maintenance
issue for another.
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:02
Dear diary, on Thu, Jul 28, 2005 at 12:07:07AM CEST, I got a letter
where A Large Angry SCM [off-list ref] told me that...
Junio C Hamano wrote:
quoted
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...
For a project the size of Git, is there any real benefit to this change?
Besides pathing issues, you also have to aware that all identifiers in
the included makefile fragments will be global.
I don't object to the change but I see it as trading one maintenance
issue for another.
I'd also argue that generally, larger files are inherently harder to
maintain, and having all the targets for all the subdirectories in a
single file sounds nightmarish. (OTOH, by now you probably know that I'm
a keep-it-as-local-as-possible junkie.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
having all the targets for all the subdirectories in a
single file sounds nightmarish
which is why you'd include Makefile[.inc] snippets from subdirectories
instead.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The only difference between a fool and a criminal who attacks a system is
that the fool attacks unpredictably and on a broader front.
-- Tom Gibb
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
From: Sam Ravnborg <hidden> Date: 2016-06-15 22:42:02
quoted
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...
If the goal is to speed up the build process the only sane way is to fix
the dependencies. In kbuild fixdep is used to parse the .c file and it
locates all references to .h files (recursive) and also detects any
usage of CONFIG_ symbols.
This part should be relative straightforward to include in git.
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)
That is doable for sure. But it hits you hard when you have to create
some special rules in a subdirectory - then you need to know in what
directory you are placed. You could assing sub := x before including
x/Makefile.inc.
On the other hand. The recursive make considered harmful is IMHO a bit
overaggregated. See the kernel where it is used extensively. And it
works with no hassle. For a small project like git it should be possible
to keep the dependencies in proper shape so there is no cross directory
boundaries to worry about - or at least only a few.
Sam
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:02
Dear diary, on Fri, Jul 29, 2005 at 09:31:34AM CEST, I got a letter
where Sam Ravnborg [off-list ref] told me that...
quoted
quoted
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...
If the goal is to speed up the build process the only sane way is to fix
the dependencies. In kbuild fixdep is used to parse the .c file and it
locates all references to .h files (recursive) and also detects any
usage of CONFIG_ symbols.
This part should be relative straightforward to include in git.