login
Search
If somebody has time and inclination, please try updated PPC SHA-1 from linux@horizon.com that is in "pu" (say make check-sha1) and report impressions. The first line from ./test-sha1.sh is the time output to hash 100MB and there should be bunch of OK output to verify the code hashes things correctly for inputs of various sizes. -
"make check-sha1" passes. Before: [torvalds@g5 linux]$ /usr/bin/time git-fsck-objects --full 101.90user 4.66system 1:46.72elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1787158minor)pagefaults 0swaps After: [torvalds@g5 linux]$ /usr/bin/time ~/git/git-fsck-objects --full 101.16user 4.32system 1:45.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1787127minor)pagefaults 0swaps which doesn't seem to really imply anything seriously changed (in fact, rerunning it made the numbers even closer). This is on a G5 powerpc. Also, "pu" in general is totally unusable. It doesn't even compile. I think that "Git.xs" thing is fine for random hacks, but please please PLEASE don't make any central program depend on it. Linus -
Care to share problems with Pasky and I to take a look at, I agree. I got really disgusted when I tentatively pulled the current Git.xs into "next" and installed it for my own use to notice that it broke git-fmt-merge-msg hence git-pull workflow. Pasky, can we first iron out kinks in the build procedure and installation before converting existing programs further? The things I worry about currently are: - the SITELIBARCH gotcha I sent you a message about (and you responded to it already -- was that an Acked-by?); - RPM target -- we probably acquired a new build-dependency in which case the .spec file needs to be updated; - Make sure Git.xs builds and installed result works fine on all platforms we care about, including Cygwin and other non-Linux boxes. I'd even suggest we revert the changes to git-fmt-merge-msg to keep it working for now, until the above worries are resolved. Otherwise we cannot have it in "next" safely (and I REALLY _do_ want to have Git.pm infrastructure in "next" soonish). We can start using Git.xs and friends in some _new_ ancillary programs, once we solve building and installing problems for everybody. That way it would help us gain portability and confidence without disrupting existing users. -
Don't everybody see them? In file included from Git.xs:8: ../cache.h:6:10: error: #include expects "FILENAME" or <FILENAME> In file included from /usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE/perl.h:756, from Git.xs:15: /usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE/embed.h:4195:1: warning: "die" redefined Git.xs:11:1: warning: this is the location of the previous definition Git.xs: In function 'boot_Git': Git.xs:57: warning: passing argument 1 of 'set_error_routine' from incompatible pointer type Git.xs:58: warning: passing argument 1 of 'set_die_routine' makes qualified function pointer from unqualified make[1]: *** [Git.o] Error 1 make[1]: Leaving directory `/home/torvalds/git/perl' make: *** [all] Error 2 how does that compile for anybody else, when -DSHA1_HEADER isn't set correctly? The quotes have gone missing: -DSHA1_HEADER='ppc/sha1.h' don't ask me why. Linus -
That is, as usual, caused by careless shell quoting.
: gitster; PPC_SHA1=YesPlease Meta/Make perl/Makefile
GIT_VERSION = 1.4.1.rc1.g9adbe
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX="/home/junio/git-test" \
DEFINE="-O2 -Wall -Wdeclaration-after-statement
-g -fPIC -DSHA1_HEADER='"ppc/sha1.h"'
-DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
LIBS="libgit.a xdiff/lib.a -lz")
Unrecognized argument in LIBS ignored: 'libgit.a'
Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
Writing Makefile for Git
All options but to use OpenSSL SHA-1 implementation share the
same problem (Meta/Make is a thin "make" wrapper to give USE_PIC
and other C compilation flags):
: gitster; ARM_SHA1=YesPlease Meta/Make perl/Makefile
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX="/home/junio/git-test" \
DEFINE="-O2 -Wall -Wdeclaration-after-statement
-g -fPIC -DSHA1_HEADER='"arm/sha1.h"'
-DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
LIBS="libgit.a xdiff/lib.a -lz")
Unrecognized argument in LIBS ignored: 'libgit.a'
Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
Writing Makefile for Git
: gitster; MOZILLA_SHA1=YesPlease Meta/Make perl/Makefile
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX="/home/junio/git-test" \
DEFINE="-O2 -Wall -Wdeclaration-after-statement
-g -fPIC -DSHA1_HEADER='"mozilla-sha1/sha1.h"'
-DGIT_VERSION=\\\"1.4.1.rc1.g9adbe\\\"" \
LIBS="libgit.a xdiff/lib.a -lz")
Unrecognized argument in LIBS ignored: 'libgit.a'
Unrecognized argument in LIBS ignored: 'xdiff/lib.a'
Writing Makefile for Git
-
Dear diary, on Sun, Jun 25, 2006 at 01:59:16AM CEST, I got a letter Oops... ---- Git.pm build: Fix $DEFINE quoting and missing GIT-CFLAGS dependency Signed-off-by: Petr Baudis <pasky@suse.cz> diff --git a/Makefile b/Makefile index 9a59466..64375f6 100644 --- a/Makefile +++ b/Makefile @@ -608,10 +608,12 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS) -perl/Makefile: perl/Git.pm perl/Makefile.PL +PERL_DEFINES = $(ALL_CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"' +PERL_DEFINES_SQ = $(subst ','\'',$(PERL_DEFINES)) +perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS (cd perl && $(PERL_PATH) Makefile.PL \ PREFIX="$(prefix)" \ - DEFINE="$(ALL_CFLAGS) -DGIT_VERSION=\\\"$(GIT_VERSION)\\\"" \ + DEFINE='$(PERL_DEFINES_SQ)' \ LIBS="$(EXTLIBS)") doc: -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ A person is just about as big as the things that make them angry. -
Signed-off-by: Petr Baudis <pasky@suse.cz> --- This one should do a better job; if we quote, let's do it proper. :-) Makefile | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 9a59466..fb9ffad 100644 --- a/Makefile +++ b/Makefile @@ -608,11 +608,15 @@ XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS) -perl/Makefile: perl/Git.pm perl/Makefile.PL +PERL_DEFINE = $(ALL_CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"' +PERL_DEFINE_SQ = $(subst ','\'',$(PERL_DEFINE)) +PERL_LIBS = $(EXTLIBS) +PERL_LIBS_SQ = $(subst ','\'',$(PERL_LIBS)) +perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS (cd perl && $(PERL_PATH) Makefile.PL \ - PREFIX="$(prefix)" \ - DEFINE="$(ALL_CFLAGS) -DGIT_VERSION=\\\"$(GIT_VERSION)\\\"" \ - LIBS="$(EXTLIBS)") + PREFIX='$(prefix_SQ)' \ + DEFINE='$(PERL_DEFINE_SQ)' \ + LIBS='$(PERL_LIBS)') doc: $(MAKE) -C Documentation all -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ A person is just about as big as the things that make them angry. -
Yes let's ;-). You obviously meant PERL_LIBS_SQ on the last line.
During our a handful piecemeal patch exchange back-and-forth on
the list, most of the patches did not apply mechanically, so I
rolled them up and have pushed out the result in "pu" and it
will mirror out shortly. I am reasonably sure it is in much
better shape than 24 hours ago; could you double check the
result for me please?
And I earlier said...
Pasky, can we first iron out kinks in the build procedure and
installation before converting existing programs further? The
things I worry about currently are:
- the SITELIBARCH gotcha I sent you a message about (and you
responded to it already -- was that an Acked-by?);
- RPM target -- we probably acquired a new build-dependency in
which case the .spec file needs to be updated;
- Make sure Git.xs builds and installed result works fine on
all platforms we care about, including Cygwin and other
non-Linux boxes.
I'd even suggest we revert the changes to git-fmt-merge-msg to
keep it working for now, until the above worries are resolved.
Otherwise we cannot have it in "next" safely (and I REALLY _do_
want to have Git.pm infrastructure in "next" soonish).
We can start using Git.xs and friends in some _new_ ancillary
programs, once we solve building and installing problems for
everybody. That way it would help us gain portability and
confidence without disrupting existing users.
I think we have cleared SITELIBARCH, and Git.xs building is in
testable state for wider audience. The remaining hurdles are to
make sure the RPM target is still sensible, and fix the test
scheme.
Now, I am clueless about RPM, so help is very much appreciated.
About the testsuite, I think with the way git-fmt-merge-msg (and
other Perl scripts that will use Git.pm) is munged on the
initial line "#!/usr/bin/perl -I$(installedpath)", the test
scheme is seriously broken. To see how ...Dear diary, on Sun, Jun 25, 2006 at 05:03:24AM CEST, I got a letter It looks good; I don't like the makefile changes a lot but more on that below. Could you please also throw in these two? [PATCH 3/7] Git.pm: Swap hash_object() parameters [PATCH 4/7] Git.pm: Fix Git->repository("/somewhere/totally/elsewhere") Chris, could you help, please? Do we need to insert anything special Yes, -I is very broken. I have abandoned it in: Subject: Re: [PATCH 01/12] Introduce Git.pm (v4) Date: Sat, 24 Jun 2006 13:52:27 +0200 The advantage to your approach is that it works properly without Yes, that bit shall be Acked-by: Petr Baudis <pasky@suse.cz> -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ A person is just about as big as the things that make them angry. -
Dear diary, on Sat, Jun 24, 2006 at 10:21:30PM CEST, I got a letter Well, perl is currently not listed even as a runtime dependency, Well, I don't think it's very likely that Git.pm per se would be buggy on a certain specific platform - it should either work as well as everywhere else or not build at all, in which case you have disrupted the existing users anyway. :-) (But without disrupting anyone we won't get any bugreports and never get it fixed.) Perhaps other converted perl scripts can linger at least on the pu branch? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ A person is just about as big as the things that make them angry. -
Really? I think rpmbuild is getting anything that matches "^use " I don't either. That's why I would want to place something My preference is to keep your other conversion in "later" mailbox, not even in "pu", to keep them from distracting me. I'd like to have something low-impact (e.g. "git-mv" which I do not use and I do not think Linus uses) along with the perl/ directory and build procedure in "next" soonish to make sure at least things build and correctly install for everybody (compiling and linking alone would not count as "correctly install" while we have something like INSTALLSITEARCH gotcha). After we are reasonably confident about the whole .xs stuff we can revert the revert of git-fmt-merge-msg. -
Dear diary, on Sun, Jun 25, 2006 at 05:57:33AM CEST, I got a letter I had on my mind to depend only on modules that are part of the default Perl distribution, since installing them from CPAN is a bother if you are installing Git to your home directory. That is why we bundle Error. All the modules we depend on should come bundled with Perl since 5.8.1. Now, I'm not sure what our "cutoff" point is, and even if it is something like 5.6.0 whether we can just require users of Perl older than 5.8.1 (which should be only some rare and obscure systems anyway) to install the modules from CPAN. If not, we can just get rid of Scalar::Util and XSLoader and we should be clean; XSLoader should be easy, Scalar::Util somewhat more messy since we will have to get Error.pm own .xs as well. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ A person is just about as big as the things that make them angry. -
Hi, NO! It is _wrong_ to require users to upgrade, when a little more work on our side would fix it. Requiring users to upgrade is a proactive way to get rid of new users. And old ones. If you would require me to upgrade to Perl 5.8.1, I would rather stop upgrading git. Hell, something I really like about git: I just download the tar.gz, unpack it, and type make install. And usually that Just Works. (Except MinGW32, but I have already managed to see a nice "git-log -p" with it.) Ciao, Dscho -
Hi, Dear diary, on Sun, Jun 25, 2006 at 12:07:21PM CEST, I got a letter please read it again - I'm not requiring you to upgrade to Perl 5.8.1. I'm just saying that if you have Perl older than 5.8.1, you might need to install some extra modules from CPAN. Now, if that's not acceptable either that's fine by me and I can adapt, I just need to know at which point we _will_ require you to upgrade or install extra modules. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ A person is just about as big as the things that make them angry. -
I vaguely recall that last time we discussed the minimum Perl version requirement somebody perhaps Merlyn said 5.6 is old enough but in some corporate settings people may still be stuck with 5.004. Tentatively let's say our cut-off point is somewhere around 5.6. If we can get away without relying on extra from CPAN that would be great. Otherwise as long as the modules from CPAN we end up depending on are all compatible with the cut-off version of Perl that would be acceptable. We might even try to be nicer and carry a straight copy of what we require from CPAN in compat/ just like we have subprocess.py there (modulo licensing worries if any, of course). Johannes, Linus and the list, would that be a good enough guideline? -
Hi, I can live with it. Although I still think that it would be a good idea to convert (at least the most commonly used) scripts to C. Perl, Python and sometimes even bash are good for fast prototyping. But for serious work, such as profiling, they are not that good. And you can see different behaviour on different platforms (plus things like the SunCC requirement for XS on Solaris), which make the scripts less robust. Ciao, Dscho -
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: Johannes> Perl, Python and sometimes even bash are good for fast Johannes> prototyping. But for serious work, such as profiling, they are not Johannes> that good. Allow my to register my strong disagreement to that statement, but then I'll crawl back in my hole. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! -
Hi, Which statement do you mean? The "good for fast prototyping" one? ;-) Being our friendly local Perl wizard, who could code cvsserver as a Perl one-liner, you probably want to say that profiling Perl is easy. Can you enlighten me how to do memory _and_ timing profiling on, say, a per-line basis? Ciao, Dscho -
For the timing, have you tried using Devel::SmallProf? perl -d:SmallProf foo.pl -Peff -
I think this finally was cleared thanks to Pavel Roskin (and an
I am having trouble with this. I'd appreciate help from RPM
Help wanted from the list here. One thing to note is that I
understand Pasky is working on not using Devel::PPPort to make
the code work with 5.6, so if your build dies with problems in
I am still undecided about the reverting, since in the places I
personally care about the program works ;-).
I test-built the tip of "pu" 57628f0e; the RPM build log ends
like this:
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /bin/sh git-core = 1.4.1.rc2.g5762-1 tk >= 8.4
Processing files: git-debuginfo-1.4.1.rc2.g5762-1
Provides: Git.so.debug()(64bit)
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/git-1.4.1.rc2.g5762-1-root-junio
error: Installed (but unpackaged) file(s) found:
/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/perllocal.pod
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Error.pm
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/Git.pm
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/.packlist
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.bs
/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi/auto/Git/Git.so
make: *** [rpm] Error 1
-
I guess all this perl stuff should be in a separate module perl-Git to comply with Red Hat conventions. This would make git-core depend on perl-Git, but it's OK. Error.pm is already provided by perl-Error. If we require perl(Error) for building, it won't be installed. Actually, probing for Error.pm is incorrect, so I'm fixing it. Git.bs, .packlist and perllocal.pod should be removed - that's what other Perl packages do. Red Hat packages use INSTALLDIRS=vendor so that "site_perl" becomes "vendor_perl". While hacking that, I have wound that "--without doc" is broken in pu, so I'm fixing it as well. The patches will be sent shortly. -- Regards, Pavel Roskin -
Thanks. The kernel.org machine I am using for testing does not seem to have perl-Error installed, and I suspect Pasky arranged to ship our own Error.pm for people building git from source because the package is not so widely installed. I guess I should ask the admins there before I can build perl-Git RPMs for release. I am doing this preparation not for the upcoming 1.4.1 but later than that -- perhaps way later than that -- so there is no rush. -
It's better than to have conflicting packages (perl-Git and perl-Error). The build requirement can be relaxed if needed (either by finding and removing Error* after the install or by adding another flag to Makefile.PL), but I think it's logical to have it because perl-Error would be needed by git-core anyway. Another solution would be to arrange Error.pm to be installed and used as Git::Error, but that would be a case of code duplication. -- Regards, Pavel Roskin -
Hi, I'll try it (it's in pu, right?). Note that breaking git-fmt-merge-msg might be a good way to force somebody to rewrite it in C ;-) Note that on my iBook (where I reported the Devel::PPPort problem), I _do_ have perl modules compiled from source, using SWIG. So, there _should_ be no problem to get it to run (although I have problems with my eyes ever since I looked into the code generated by SWIG). Ciao, Dscho -
It would hopefully not come to that (and that is I am playing safe and keeping the series in "pu"), and even if it did, I am hoping that Perl is so ubiquitous that people would fix it up quickly. -
