From: Jeff King <peff@peff.net>
To: Mike Ralphson <mike.ralphson@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: obscure platform autobuilders
Date: Wed, 1 Oct 2008 11:37:03 -0400 [thread overview]
Message-ID: <20081001153703.GC4962@coredump.intra.peff.net> (raw)
In-Reply-To: <e2b179460810010346j23617764i8134c1f24b2746f0@mail.gmail.com>
On Wed, Oct 01, 2008 at 11:46:43AM +0100, Mike Ralphson wrote:
> My googling led me to think that INTERNAL_QSORT would be a good idea
> on at least some versions of Solaris... it may depend on the fs
> though.
I thought it was purely a performance enhancement. Should it affect the
test results?
> How about this - let me know if ok, and I'll push it.
It mostly looks good, though I would have split it into several distinct
commits for readability. A few comments below.
> - - 'branches', a list of branches, one per line, to build and test
> + - 'branches', a list of branches, one per line, to build and test.
> + Lines starting with # are treated as comments
Makes sense.
> - 'config.mak'; if this file exists, it will be used as the config.mak
> - file for building git
> + file for building git. If it is not present, but there is a
> + config.mak file in your project directory, it is copied here to
> + prevent it being removed by 'git clean'
I'm not sure I agree with this. My goal was to treat the project
directory as nothing more than a cache, with the gitbuild repo as the
master source driving the tests. So this works backwards to that.
One of the things I was (and am) considering is rather than doing
checkout/clean, to simply export each branch to a new directory and
build from there. Then the "project" repo could actually be bare.
How is this feature intended to be used? It looks like it would
basically be invoked one time, when running this script on an existing
gitbuild setup. So it saves one manual step of copying your config.mak
to the platform directory. But you still have to manually inspect, add,
and commit that config.mak file.
> + - 'catch', a shell script sourced by the build script if an error
> + occurs. It is passed the failing command-line in its arguments
> +
> + - 'finally', a shell script sourced by the build script at the end
> + of the process. It is passed the exit code of build.sh as its
> + argument
These look like sensible hooks.
> + - project; the path to the directory to build in. If not set, defaults
> + to ./project relative to the starting directory
> +
I am accomplishing the same thing with a symlink, but I think this is
probably cleaner.
> +if ! test -d $project; then
> + try mkdir $project
> + try cd $project
Quotes around $project? I'm not sure how robust the rest of the script
is to paths with spaces (which I personally consider insane).
> - for i in `cat "$root/branches"`; do
> + for i in `cat "$root/branches" | grep -v '^#'`; do
Useless use of cat. :)
grep -v ^# < "$root/branches"
-Peff
prev parent reply other threads:[~2008-10-01 15:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 15:46 A note from the interim Git maintainer Shawn O. Pearce
2008-09-26 13:24 ` Mike Ralphson
2008-09-26 22:54 ` Jeff King
2008-09-29 7:51 ` Mike Ralphson
2008-10-01 7:16 ` obscure platform autobuilders Jeff King
2008-10-01 10:46 ` Mike Ralphson
2008-10-01 15:37 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081001153703.GC4962@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=mike.ralphson@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).