threads / rfc / 4812

RFC patchMove SCM interoperability tools into scm/

Subject: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

## tl;dr

11 messages between Jul 9, 2006 and Jul 10, 2006. Diffs are folded; open one to read it.

replies: 10people: 6as markdown or json

Ryan Anderson· Jul 9, 2006, 06:17 UTC · lore
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---

This is the first in a series to categorize the source tree a little bit more than it is currently.

I figured I'd start with something innocuous, like the SCM interoperability tools.

One thing I don't really like is that I had to duplicate the Perl build rule in the subdirectory Makefile, effectively, to restructure it and leave the built files in the root. If we can deprecate "run from the source tree", this can go away. (That requires fixing up a lot of tests, but it's straightforward, at least.)

So, flame away!
 Makefile                                           |   10 ++++++----
 scm/Makefile                                       |   20 ++++++++++++++++++++
 git-archimport.perl => scm/git-archimport.perl     |    0 
 .../git-cvsexportcommit.perl                       |    0 
 git-cvsimport.perl => scm/git-cvsimport.perl       |    0 
 git-cvsserver.perl => scm/git-cvsserver.perl       |    0 
 git-p4import.py => scm/git-p4import.py             |    0 
 git-send-email.perl => scm/git-send-email.perl     |    0 
 git-svnimport.perl => scm/git-svnimport.perl       |    0 
 9 files changed, 26 insertions(+), 4 deletions(-)
Show changes to 9 files +26 −4

Makefile, scm/Makefile, git-archimport.perl, git-cvsexportcommit.perl, git-cvsimport.perl, git-cvsserver.perl, git-p4import.py, git-send-email.perl, git-svnimport.perl

diff --git a/Makefile b/Makefile
index 202f261..e7f5b48 100644
--- a/Makefile
+++ b/Makefile
@@ -130,11 +130,10 @@ SCRIPT_SH = \
 	git-lost-found.sh git-quiltimport.sh
 
 SCRIPT_PERL = \
-	git-archimport.perl git-cvsimport.perl git-relink.perl \
+	git-relink.perl \
 	git-shortlog.perl git-rerere.perl \
-	git-annotate.perl git-cvsserver.perl \
-	git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
-	git-send-email.perl
+	git-annotate.perl \
+	git-mv.perl
 
 SCRIPT_PYTHON = \
 	git-merge-recursive.py
@@ -176,6 +175,9 @@ BUILT_INS = git-log$X git-whatchanged$X 
 	git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \
 	git-fmt-merge-msg$X
 
+
+include scm/Makefile
+
 # what 'all' will build and 'install' will install, in gitexecdir
 ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
 
diff --git a/scm/Makefile b/scm/Makefile
new file mode 100644
index 0000000..0ce205b
--- /dev/null
+++ b/scm/Makefile
@@ -0,0 +1,20 @@
+
+SCM_PERL_BASE = \
+	git-archimport.perl \
+	git-cvsimport.perl \
+	git-cvsexportcommit.perl \
+	git-cvsserver.perl \
+	git-svnimport.perl \
+	git-send-email.perl
+
+SCRIPTS+=$(patsubst %.perl,%,$(SCM_PERL_BASE))
+
+$(patsubst %.perl,%,$(SCM_PERL_BASE)) : % : scm/%.perl
+	rm -f $@ $@+
+	sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+	    $^ >$@+
+	chmod +x $@+
+	mv $@+ $@
+
+
diff --git a/git-archimport.perl b/scm/git-archimport.perl
similarity index 100%
rename from git-archimport.perl
rename to scm/git-archimport.perl
diff --git a/git-cvsexportcommit.perl b/scm/git-cvsexportcommit.perl
similarity index 100%
rename from git-cvsexportcommit.perl
rename to scm/git-cvsexportcommit.perl
diff --git a/git-cvsimport.perl b/scm/git-cvsimport.perl
similarity index 100%
rename from git-cvsimport.perl
rename to scm/git-cvsimport.perl
diff --git a/git-cvsserver.perl b/scm/git-cvsserver.perl
similarity index 100%
rename from git-cvsserver.perl
rename to scm/git-cvsserver.perl
diff --git a/git-p4import.py b/scm/git-p4import.py
similarity index 100%
rename from git-p4import.py
rename to scm/git-p4import.py
diff --git a/git-send-email.perl b/scm/git-send-email.perl
similarity index 100%
rename from git-send-email.perl
rename to scm/git-send-email.perl
diff --git a/git-svnimport.perl b/scm/git-svnimport.perl
similarity index 100%
rename from git-svnimport.perl
rename to scm/git-svnimport.perl
-- 
1.4.1.gc473b-dirty
Johannes Schindelin· Jul 9, 2006, 14:31 UTC · re: Ryan Anderson · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

Hi,
On Sun, 9 Jul 2006, Ryan Anderson wrote:
> If we can deprecate "run from the source tree", this can go away.  

You would make yours truly very sad. Besides, for the tests we need the functionality anyway.

Ciao, Dscho

Martin Langhoff· Jul 9, 2006, 21:26 UTC · re: Ryan Anderson · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

On 7/9/06, Ryan Anderson <ryan@michonline.com> wrote:
> This is the first in a series to categorize the source tree a little bit more
> than it is currently.

Given that you title it RFC, I guess it hasn't been discussed before. I personally don't see much benefit from the move/rename. The tree is not so large, the SCM import/export utilities are a single file each and their names are quite clear. Having /contrib is more an issue of marking utilities there as 'new, experimental, unsupported', and the assumption is that when something matures it moves out of /contrib.

So I have to ask... what are the expected benefits of the move?

In any case, use /interop instead. /scm in the tree of an SCM could be anything ;-)

martin
Petr Baudis· Jul 9, 2006, 22:13 UTC · re: Martin Langhoff · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter where Martin Langhoff <martin.langhoff@gmail.com> said that...

> So I have to ask... what are the expected benefits of the move?

I've been meaning to do something like this for some time already; my itch have been the builtins. The tree size _is_ getting out of hand and a little more categorization of the sources would certainly help. Although I'd take a different approach:

	libgit/
	builtin/
	standalone/
	scripts/
> In any case, use /interop instead. /scm in the tree of an SCM could be
> anything ;-)
I agree on this point.
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
Johannes Schindelin· Jul 9, 2006, 22:21 UTC · re: Petr Baudis · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

Hi,
On Mon, 10 Jul 2006, Petr Baudis wrote:
Show 7 quoted lines
> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> said that...
> > So I have to ask... what are the expected benefits of the move?
> 
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.

Funny. I thought the builtin-* prefix, and the *.sh and *.perl extensions were there for the sake of categorization.

And I disagree on the "out of hand" thing.

Ciao, Dscho

Ryan Anderson· Jul 9, 2006, 22:23 UTC · re: Petr Baudis · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

On Mon, Jul 10, 2006 at 12:13:26AM +0200, Petr Baudis wrote:
Show 7 quoted lines
> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> said that...
> > So I have to ask... what are the expected benefits of the move?
> 
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.

That's what I was thinking, as well, basically. I started with the "scm interop" tools because they should be the least controversial to move around.

Show 11 quoted lines
> Although I'd take a different approach:
> 
> 	libgit/
> 	builtin/
> 	standalone/
> 	scripts/
> 
> > In any case, use /interop instead. /scm in the tree of an SCM could be
> > anything ;-)
> 
> I agree on this point.
Very good point.
So these seem obvious to me:
	libgit/ (maybe just lib/?)
	builtin/
	interop/

I'm less sure of the rest, but I'll poke at doing the above for the moment, and worry about the rest later.

Comments on a way to make the Makefile less repetitive would be appreciated, though.

-- 
Ryan Anderson
  sometimes Pug Majere
Junio C Hamano· Jul 10, 2006, 00:39 UTC · re: Ryan Anderson · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

Ryan Anderson <ryan@michonline.com> writes:
> Comments on a way to make the Makefile less repetitive would be
> appreciated, though.

One obvious way would be not to have scm/Makefile but have the dependencies in the main Makefile to say (the moral equivalent of):

	git-archimport.perl: scm/git-archimport.perl
Ryan Anderson· Jul 10, 2006, 03:24 UTC · re: Junio C Hamano · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

Junio C Hamano wrote:
Show 13 quoted lines
> Ryan Anderson <ryan@michonline.com> writes:
>
>   
>> Comments on a way to make the Makefile less repetitive would be
>> appreciated, though.
>>     
>
> One obvious way would be not to have scm/Makefile but have the
> dependencies in the main Makefile to say (the moral equivalent
> of):
>
> 	git-archimport.perl: scm/git-archimport.perl
>   

I think that doing that means I still need to duplicate the actual build rules, which is what I was hoping to avoid, as they encode all the magic "path replacement" logic in multiple places.

On the other hand, I can fix *that*, if I break the ability to run in the build directory, which is bad in its own way. (Fixing the tests should be a matter of adapting the test library slightly, I think.)

For the time being, I'm going with ugly, but less disruptive, and I'm willing/planning on revisiting it when things shake out a bit more.

-- 
Ryan Anderson
  sometimes Pug Majere
Timo Hirvonen· Jul 9, 2006, 22:34 UTC · re: Petr Baudis · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

Petr Baudis <pasky@suse.cz> wrote:
Show 9 quoted lines
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.
> Although I'd take a different approach:
> 
> 	libgit/
> 	builtin/
> 	standalone/
> 	scripts/

Please don't. One directory is much easier to work with. At least don't split the Makefile. Also moving files makes "git log <file>" stop at the rename.

-- 
http://onion.dynserv.net/~timo/
Ryan Anderson· Jul 10, 2006, 00:20 UTC · re: Timo Hirvonen · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

Timo Hirvonen wrote:
Show 18 quoted lines
> Petr Baudis <pasky@suse.cz> wrote:
>
>   
>> I've been meaning to do something like this for some time already; my
>> itch have been the builtins. The tree size _is_ getting out of hand and
>> a little more categorization of the sources would certainly help.
>> Although I'd take a different approach:
>>
>> 	libgit/
>> 	builtin/
>> 	standalone/
>> 	scripts/
>>     
>
> Please don't.  One directory is much easier to work with.  At least
> don't split the Makefile.  Also moving files makes "git log <file>"
> stop at the rename.
>   
By "don't split the Makefile", do mean, "Don't use recursive make"?

I'm fine with that (and if you look at my patch, I "include scm/Makefile" to do just that), but if you mean "keep only a top-level Makefile", well, I think that continues the problem of "there is too much stuff going on here", but I can be persuaded otherwise.

-- 
Ryan Anderson
  sometimes Pug Majere
Timo Hirvonen· Jul 10, 2006, 09:45 UTC · re: Ryan Anderson · lore

Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/

Ryan Anderson <ryan@michonline.com> wrote:
Show 6 quoted lines
> By "don't split the Makefile", do mean, "Don't use recursive make"?
> 
> I'm fine with that (and if you look at my patch, I "include
> scm/Makefile" to do just that), but if you mean "keep only a top-level
> Makefile", well, I think that continues the problem of "there is too
> much stuff going on here", but I can be persuaded otherwise.

Recursive make is a horrible hack. Splitting Makefile to smaller chunks which would be included in the top level Makefile is almost as bad. You can't cd to subdirectory and run make there and you have to prefix all files with "subdir/".

If you really want to make Makefile shorter just move all the platform specific stuff to a configure script.

-- 
http://onion.dynserv.net/~timo/

← back to recent threads