In general, checkinstall.
config.mak
:CC = gcc
CFLAGS = -std=c99
# override defective library module
LDFLAGS = -l :sigset.o
prefix = /mod
NO_ICONV = 1
NO_IPV6 = 1
NO_PERL = 1
NO_TCLTK = 1
NO_CROSS_DIRECTORY_HARDLINKS = 1
INSTALL_STRIP = -s
NO_GETTEXT = 1
NO_EXPAT = 1
HAVE_SYNC_FILE_RANGE =
/mod/include/gnu/lib-version.h
/* includer thinks it's GLIBC but it's not */
#ifdef __GLIBC__
#undef __GLIBC__
#endif
humax# pwd
/mod/src/git
humax# stat ./git
File: `./git'
Size: 7253005 Blocks: 14192 IO Block: 4096 regular file
Device: 801h/2049d Inode: 6938607 Links: 137
Access: (0700/-rwx------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-12-10 15:03:29.000000000 +0000
Modify: 2023-12-10 15:01:03.000000000 +0000
Change: 2023-12-10 15:01:15.000000000 +0000
Birth: -
humax# ./git --version
git version 2.43.0
humax# ./git status -uno
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit (use -u to show untracked files)
humax#
Executables are always bloated on the MIPS cpu. It's because it doesn't implement register score boarding, with that technique on other cpus if an instruction uses a register before a previous instruction has generated the result in that register the cpu stalls. On the MIPS it's up to the compiler to find other instructions to put there, or if it can't find any (as is usual) the compiler has to put NOPs in. This was meant to be an optimisation but it means a) bloated binaries and b) when a new cpu takes less cycles to do something the code has to be re-compiled with a different target cpu to take any advantage of the faster instruction cycle timings.Even after stripping the git executable is 6.5MB vs 4MB for x86 (this has been seen with other programs too). I wonder (again) if there's some build flag that would reduce the size.
-rwxr-xr-x 141 root root 5243816 Sun 10 Dec 2023 13:28:40 /mod/bin/gitEven after stripping the git executable is 6.5MB
See previous comment about -D__FORCE_NOGLIBCincluder thinks it's GLIBC but it's not
#!/bin/sh
ver=$(grep DEF_VER= GIT-VERSION-GEN |cut -dv -f2)
echo "$ver" >version
export CFLAGS="-D_FILE_OFFSET_BITS=64 -D__FORCE_NOGLIBC -std=gnu99 -I=$HOME/mod/include"
export LDFLAGS="-Wl,-R/mod/lib,-L$HOME/mod/lib,-rpath-link=$HOME/mod/lib"
./configure \
--prefix=/mod \
--host=mipsel-linux \
--without-tcltk \
--with-iconv=no \
--with-curl="$HOME/mod" \
--with-openssl="$HOME/mod/" \
ac_cv_fread_reads_directories=no \
ac_cv_snprintf_returns_bogus=no
make NO_CURL= CURL_LDFLAGS=-lcurl install
mipsel-linux-strip /mod/bin/* /mod/libexec/git-core/* 2>/dev/null
rsync -vrlptH /mod/* "humax:/mod/src/git_$ver""_mipsel/"
diff --git a/remote.c b/remote.c
index abb2482..065fb34 100644
--- a/remote.c
+++ b/remote.c
@@ -594,7 +594,7 @@ const char *pushremote_for_branch(struct branch *branch, int *explicit)
branch, explicit);
}
-static struct remote *remotes_remote_get(struct remote_state *remote_state,
+static inline struct remote *remotes_remote_get(struct remote_state *remote_state,
const char *name);
const char *remote_ref_for_branch(struct branch *branch, int for_push)
See previous comment about -D__FORCE_NOGLIBC
features.h
some builds break if __GLIBC__
isn't set (which that define forces) even if the interfaces expected from glibc are present. Apparently git isn't one.That's OK then. I was going for the specific rather than the general!According to thefeatures.h
some builds break if__GLIBC__
isn't set... Apparently git isn't one.
Anyone got any reasons not to promote this Git build to the main repository? It all works nicely for me.It's in the Beta repository now.
str1_str2_str3
I want to extract str3
str1_str2_str3_str4
I want to extract str3_str4
str1_str2_
from the start of the given string and leave whatever is left, regardless of whether it contains an underscore.str4
in the latter case. Struggling to ask big G the right question regarding lazy/greedy which I suspect might be the answer...$ echo "xyz a1_b2_c3_d4"|sed -n "s/\(.*\) .*_.*_\(.*\)/\2 \1/p"
d4 xyz
str1_str2_
, then ^([^_]+_){2}
matches that very thing, ie (start of string)(twice:(multiple non-_)_)
: $ echo "a1_b2_c3"|sed -rn "s/^([^_]+_){2}//;p"
c3
$ echo "a1_b2_c3_d4"|sed -rn "s/^([^_]+_){2}//;p"
c3_d4
$
-r
is needed for sed._
from the str parts.$ echo "xyz a1_b2_c3d4e5" |sed -rn "s/^([^ ]+) ([^_]+_){2}(.*)/\3 \1/p"
c3d4e5 xyz
$ echo "xyz a1_b2_c3_d4e5" |sed -rn "s/^([^ ]+) ([^_]+_){2}(.*)/\3 \1/p"
c3_d4e5 xyz
$ echo "xyz a1_b2_c3_d4_e5"|sed -rn "s/^([^ ]+) ([^_]+_){2}(.*)/\3 \1/p"
c3_d4_e5 xyz
You might be right but that's something I know nothing about and yet another world of pain.Might be a job for a one line Perl invocation.
[Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript.
Probably, but it doesn't matter anyway as any more will get absorbed into the start of the string with underscores which is getting disposed of.Will there always be exactly a single space between the not-space group and the underscore-group?
Strange. A colleague of mine referred to C as write once read never code (or something very similar). Maybe because he didn't document it. You can write bad code in any language! (And I have done!)If you do this you can have code that is as readable as C. If you don't you will likely have write-once-read-never code.
I find I need this to match just a dash:((?:[\s-]?\w[:;.,]?)+) # capture the test name
((?:[\s-]?[\w-][:;.,]?)+)
((?:[\s-]?\w[:;.,]?)+?) # capture the test result (non-greedy)
((?:[\s-]?\(?[\w-][:;.,)]?)+?)