From: Junio C Hamano <hidden> Date: 2016-06-15 22:50:38
Jeff King [off-list ref] writes:
On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:
quoted
quoted
Speaking of Makefiles, one downside to all of this directory
segmentation is that you can't run "make" from the subdirectories.
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. I am not thrilled at the prospect of more recursive make.
Likewise. Notice that I have consistently been unthrilled when people
started talking about splitting the source code tree?
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:50:38
On Wed, 23 Feb 2011, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:
quoted
quoted
Speaking of Makefiles, one downside to all of this directory
segmentation is that you can't run "make" from the subdirectories.
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. I am not thrilled at the prospect of more recursive make.
Likewise. Notice that I have consistently been unthrilled when people
started talking about splitting the source code tree?
Maybe that would be wiser to consider an initial set of patches as those
which were proposed to only do the simple file move first, then wait for
the dust to settle before doing more changes. Doing too much in one go
is inevitably going to bounce against the human tendency to resist any
kind of change, good or bad.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2011-02-23 at 12:18 -0500, Nicolas Pitre wrote:
On Wed, 23 Feb 2011, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:
quoted
quoted
Speaking of Makefiles, one downside to all of this directory
segmentation is that you can't run "make" from the subdirectories.
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. I am not thrilled at the prospect of more recursive make.
Likewise. Notice that I have consistently been unthrilled when people
started talking about splitting the source code tree?
Maybe that would be wiser to consider an initial set of patches as those
which were proposed to only do the simple file move first, then wait for
the dust to settle before doing more changes. Doing too much in one go
is inevitably going to bounce against the human tendency to resist any
kind of change, good or bad.
Nicolas
Nicolas,
They are doing it this way because change is not the objective. A
possible better way of managing the codebase is. Perhaps it isn't the
right way to go--and we won't know that until we've explored all of the
side-effects, advantages, disadvantages, etc.
Besides, if we move anything around into a deeper directory structure we
are inevitably going to have to deal with more recursive make problems.
We can't just commit to master a tree that has everything moved about
and get around to dealing with the Makefiles later.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:50:38
On Wed, 23 Feb 2011, Drew Northup wrote:
On Wed, 2011-02-23 at 12:18 -0500, Nicolas Pitre wrote:
quoted
On Wed, 23 Feb 2011, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:
quoted
quoted
Speaking of Makefiles, one downside to all of this directory
segmentation is that you can't run "make" from the subdirectories.
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. I am not thrilled at the prospect of more recursive make.
Likewise. Notice that I have consistently been unthrilled when people
started talking about splitting the source code tree?
Maybe that would be wiser to consider an initial set of patches as those
which were proposed to only do the simple file move first, then wait for
the dust to settle before doing more changes. Doing too much in one go
is inevitably going to bounce against the human tendency to resist any
kind of change, good or bad.
quoted
Nicolas
Nicolas,
They are doing it this way because change is not the objective. A
possible better way of managing the codebase is.
Incidentally I know that (guess whom this proposal came from initially). ;-)
Perhaps it isn't the
right way to go--and we won't know that until we've explored all of the
side-effects, advantages, disadvantages, etc.
Besides, if we move anything around into a deeper directory structure we
are inevitably going to have to deal with more recursive make problems.
We can't just commit to master a tree that has everything moved about
and get around to dealing with the Makefiles later.
The initial set of patches simply moved files into subdirectories and
made the corresponding renames within the Makefile.
Reorganizing the Makefile into a better Makefile or sub-makefiles can be
done subsequently. That's my point.
Nicolas
On Wed, 2011-02-23 at 19:14 -0500, Nicolas Pitre wrote:
On Wed, 23 Feb 2011, Drew Northup wrote:
quoted
On Wed, 2011-02-23 at 12:18 -0500, Nicolas Pitre wrote:
quoted
On Wed, 23 Feb 2011, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:
quoted
quoted
Speaking of Makefiles, one downside to all of this directory
segmentation is that you can't run "make" from the subdirectories.
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. I am not thrilled at the prospect of more recursive make.
Likewise. Notice that I have consistently been unthrilled when people
started talking about splitting the source code tree?
Maybe that would be wiser to consider an initial set of patches as those
which were proposed to only do the simple file move first, then wait for
the dust to settle before doing more changes. Doing too much in one go
is inevitably going to bounce against the human tendency to resist any
kind of change, good or bad.
quoted
Nicolas
Nicolas,
They are doing it this way because change is not the objective. A
possible better way of managing the codebase is.
Incidentally I know that (guess whom this proposal came from initially). ;-)
quoted
Perhaps it isn't the
right way to go--and we won't know that until we've explored all of the
side-effects, advantages, disadvantages, etc.
Besides, if we move anything around into a deeper directory structure we
are inevitably going to have to deal with more recursive make problems.
We can't just commit to master a tree that has everything moved about
and get around to dealing with the Makefiles later.
The initial set of patches simply moved files into subdirectories and
made the corresponding renames within the Makefile.
Reorganizing the Makefile into a better Makefile or sub-makefiles can be
done subsequently. That's my point.
It can be done as a separate patch, but it should all be done in the
public branch (pu?) as atomically as possible (one merge from Junio's
workspace). In other words, the public branch should never fail to build
because of this work. That's what I meant by "later" in my comment (as
it apparently wasn't obvious from context alone). This is especially
important for gaining the accession of the rest of the developer
community. Jeff (Peff) and Junio are both apparently quite well aware of
this--and I happen to agree with Jeff's way of approaching this type of
change.
As for making an authoritative publicly available branch containing this
reorganization work (due solely to the extreme effect it will have on
other development), I will leave it an open question as to whether this
belongs in pu while a 1.7.5 release is still a possibility. It looks
like a headache either way.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:50:39
On Thu, 24 Feb 2011, Drew Northup wrote:
On Wed, 2011-02-23 at 19:14 -0500, Nicolas Pitre wrote:
quoted
On Wed, 23 Feb 2011, Drew Northup wrote:
quoted
Besides, if we move anything around into a deeper directory structure we
are inevitably going to have to deal with more recursive make problems.
We can't just commit to master a tree that has everything moved about
and get around to dealing with the Makefiles later.
The initial set of patches simply moved files into subdirectories and
made the corresponding renames within the Makefile.
Reorganizing the Makefile into a better Makefile or sub-makefiles can be
done subsequently. That's my point.
It can be done as a separate patch, but it should all be done in the
public branch (pu?) as atomically as possible (one merge from Junio's
workspace). In other words, the public branch should never fail to build
because of this work.
Who said this would fail to compile?
If you move bar.c into the foo directory, then in the existing Makefile
you simply have to make a mechanical rename of bar.c to foo/bar.c.
Restructuring the Makefile can be done separately from the file move
without ever breaking the build (except for unintentional mistakes of
course).
As for making an authoritative publicly available branch containing this
reorganization work (due solely to the extreme effect it will have on
other development), I will leave it an open question as to whether this
belongs in pu while a 1.7.5 release is still a possibility. It looks
like a headache either way.
Oh sure. But if we the developers of Git can't deal with that ourselves
then it is a really good sign that our own tool is crappy in that area
and probably needs to be improved. Such a tree reorganization is
something that happens in other projects as well, so it is a good
opportunity to improve Git to cope well with such a situation if it
isn't up to it yet.
Nicolas
From: Jeff King <hidden> Date: 2016-06-15 22:50:39
On Thu, Feb 24, 2011 at 01:04:21PM -0500, Nicolas Pitre wrote:
quoted
It can be done as a separate patch, but it should all be done in the
public branch (pu?) as atomically as possible (one merge from Junio's
workspace). In other words, the public branch should never fail to build
because of this work.
Who said this would fail to compile?
If you move bar.c into the foo directory, then in the existing Makefile
you simply have to make a mechanical rename of bar.c to foo/bar.c.
Restructuring the Makefile can be done separately from the file move
without ever breaking the build (except for unintentional mistakes of
course).
Exactly. Maybe it wasn't clear in the previous bits of the thread, but
Makefile reorganization is a totally optional thing that can come on top
of file movement if we choose. I just brought it up with file movement
because having a bunch of subdirs is going to probably make us _want_ to
do something with Makefiles.
In the interim it may not work to run make from the "cmds" subdirectory,
but that is not a "fail to build" breakage. As long as we build via
"make" from the root, then there is no regression. Adding extra make
fluff on top of that is feature work, not a bug fix.
-Peff
On Thu, 2011-02-24 at 14:08 -0500, Jeff King wrote:
On Thu, Feb 24, 2011 at 01:04:21PM -0500, Nicolas Pitre wrote:
quoted
quoted
It can be done as a separate patch, but it should all be done in the
public branch (pu?) as atomically as possible (one merge from Junio's
workspace). In other words, the public branch should never fail to build
because of this work.
Who said this would fail to compile?
If you move bar.c into the foo directory, then in the existing Makefile
you simply have to make a mechanical rename of bar.c to foo/bar.c.
Restructuring the Makefile can be done separately from the file move
without ever breaking the build (except for unintentional mistakes of
course).
Exactly. Maybe it wasn't clear in the previous bits of the thread, but
Makefile reorganization is a totally optional thing that can come on top
of file movement if we choose. I just brought it up with file movement
because having a bunch of subdirs is going to probably make us _want_ to
do something with Makefiles.
In the interim it may not work to run make from the "cmds" subdirectory,
but that is not a "fail to build" breakage. As long as we build via
"make" from the root, then there is no regression. Adding extra make
fluff on top of that is feature work, not a bug fix.
-Peff
I am glad to hear that is the case here. Pretty much everything else
I've ever worked on absolutely breaks if files are moved around and
Makefiles are not updated to suit.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59