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

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

[Ryan Anderson]

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(-)

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

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

[Johannes Schindelin]

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

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

[Martin Langhoff]

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

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

[Petr Baudis]

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

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

[Johannes Schindelin]

Hi,

On Mon, 10 Jul 2006, Petr Baudis wrote:

> 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

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

[Ryan Anderson]

On Mon, Jul 10, 2006 at 12:13:26AM +0200, Petr Baudis wrote:
> 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.

> 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

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

[Timo Hirvonen]

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.

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

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

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

Timo Hirvonen wrote:
> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Junio C Hamano]

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

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

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

Junio C Hamano wrote:
> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Timo Hirvonen]

Ryan Anderson <ryan@michonline.com> wrote:

> 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/