This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Generic build script instructions
Op Tue, 15 Jun 2004 16:52:31 -0400 (EDT) schreef Igor Pechtchanski
<pechtcha at see es dot and why you dot ee dee you>
in <Pine.GSO.4.58.0406151634100.29972@slinky.cs.nyu.edu>:
: On Tue, 15 Jun 2004, Max Bowsher wrote:
[...]
: > This makes me wonder if it might be sensible for all package maintainers
: > to say a little about their packaging methods, maybe even leading to a
: > plan for a new standard cygwin package building system.
[...]
: I absolutely agree. If package maintainers could take some time to try to
: adapt the CVS HEAD of the GBS
: (<http://cygwin.com/cgi-bin/cvsweb.cgi/packaging/templates/generic-build-script?cvsroot=cygwin-apps&only_with_tag=HEAD>)
: to their packages and let me (and this list, I guess) know what changes
: needed to be made, we could try to extract common patterns and include
: them into the CVS version.
I am not a package maintainer, so EMBI.
Following are two patches, one (inline) for review (ignoring
changes in whitespace) and one (attached) for easy application
(``patch <gbs-loop-ispatch.patch'' in the src-directory.)
Each of them does:
*) Allow more than one argument at a time (e.g. do
``./boffo-1.0.36-1.sh prep conf build'').
*) An ``ispatch'' command, copying a fresh patch, to make the porting
process easier. (When you're done editing, do a
``./boffo-1.0.36-1 clean mkpatch ispatch finish all''
to get your new packages.) It backs up your old patch, to be on the
safe side.
: We could also try putting some more
: autodetection code into the GBS (e.g., get "make" to try both the "test"
: rule and the "check" rule -- the two most common names for running the
: testsuite -- and pick the one that exists).
I saw a trick that might be usable for this somewhere... i'll get back
to you on it...
: I'm willing to coordinate the effort on this, but please everyone feel
: free to send patches based on the above input. One major criterion for
: accepting those patches would be to make the overall amount of changes to
: the scripts smaller (with the secondary goal of making each individual set
: of changes smaller).
Should not the main objective be to make the needed effort (for
understanding, maintaining, using effectively) smallest? (NRN)
: Igor
: P.S. FWIW, another idea I had, akin to Max's python approach, was to
: actually append a (wrapped) GBS patch to the GBS instead of changing the
: script directly, and have the GBS detect that fact and apply the patch to
: itself, then running the resulting script (piping it to an exec'ed shell).
: Opinions?
Would not that create an entirely new build method (with a very
impractical structure)?
Isn't it more in style with method 2 to store a copy of the gbs,
before you made any mods to it, in CYGWIN-PATCHES? you can then
always (diff out any changes you made/merge in changes from the
latest cvs version).
Index: packaging/templates/generic-build-script
===================================================================
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.22
diff -u -b -p -r1.22 generic-build-script
--- packaging/templates/generic-build-script 31 Mar 2004 00:56:17 -0000 1.22
+++ packaging/templates/generic-build-script 17 Jun 2004 23:57:55 -0000
@@ -257,6 +257,9 @@ mkpatch() {
${srcinstdir}/${src_patch_name} ; \
rm -rf ${BASEPKG}-orig )
}
+ispatch() {
+ cp --backup=numbered ${srcinstdir}/${src_patch_name} ${topdir}
+}
spkg() {
(mkpatch && \
if [ "${SIG}" -eq 1 ] ; then \
@@ -312,7 +315,8 @@ checksig() {
echo "You need the gnupg package installed in order to check signatures." ; \
fi
}
-case $1 in
+while test -n "$1" ; do
+ case $1 in
prep) prep ; STATUS=$? ;;
mkdirs) mkdirs ; STATUS=$? ;;
conf) conf ; STATUS=$? ;;
@@ -330,6 +334,7 @@ case $1 in
package) pkg ; STATUS=$? ;;
pkg) pkg ; STATUS=$? ;;
mkpatch) mkpatch ; STATUS=$? ;;
+ ispatch) ispatch ; STATUS=$? ;;
src-package) spkg ; STATUS=$? ;;
spkg) spkg ; STATUS=$? ;;
finish) finish ; STATUS=$? ;;
@@ -339,6 +344,7 @@ case $1 in
strip && pkg && spkg && finish ; \
STATUS=$? ;;
*) echo "Error: bad arguments" ; exit 1 ;;
-esac
-exit ${STATUS}
-
+ esac
+ ( exit ${STATUS} ) || exit ${STATUS}
+ shift
+done
begin 644 gbs-loop-ispatch.patch
Index: packaging/templates/generic-build-script
===================================================================
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.22
diff -u -b -p -r1.22 generic-build-script
--- packaging/templates/generic-build-script 31 Mar 2004 00:56:17 -0000 1.22
+++ packaging/templates/generic-build-script 17 Jun 2004 23:57:55 -0000
@@ -257,6 +257,9 @@ mkpatch() {
${srcinstdir}/${src_patch_name} ; \
rm -rf ${BASEPKG}-orig )
}
+ispatch() {
+ cp --backup=numbered ${srcinstdir}/${src_patch_name} ${topdir}
+}
spkg() {
(mkpatch && \
if [ "${SIG}" -eq 1 ] ; then \
@@ -312,7 +315,8 @@ checksig() {
echo "You need the gnupg package installed in order to check signatures." ; \
fi
}
-case $1 in
+while test -n "$1" ; do
+ case $1 in
prep) prep ; STATUS=$? ;;
mkdirs) mkdirs ; STATUS=$? ;;
conf) conf ; STATUS=$? ;;
@@ -330,6 +334,7 @@ case $1 in
package) pkg ; STATUS=$? ;;
pkg) pkg ; STATUS=$? ;;
mkpatch) mkpatch ; STATUS=$? ;;
+ ispatch) ispatch ; STATUS=$? ;;
src-package) spkg ; STATUS=$? ;;
spkg) spkg ; STATUS=$? ;;
finish) finish ; STATUS=$? ;;
@@ -339,6 +344,7 @@ case $1 in
strip && pkg && spkg && finish ; \
STATUS=$? ;;
*) echo "Error: bad arguments" ; exit 1 ;;
-esac
-exit ${STATUS}
-
+ esac
+ ( exit ${STATUS} ) || exit ${STATUS}
+ shift
+done
end
ChangeLog entry:
2004-06-18 Bas van Gompel <g-b-s-patch.buzz@bavag.tmfweb.nl>
* templates/generic-build-script: Allow multiple arguments.
(ispatch) New function and argument.
Buzz.
BTW:
2004-02-18 Yaakov Selkowitz <yselk...
^
--
) | | ---/ ---/ Yes, this | This message consists of true | I do not
-- | | / / really is | and false bits entirely. | mail for
) | | / / a 72 by 4 +-------------------------------+ any1 but
-- \--| /--- /--- .sigfile. | |perl -pe "s.u(z)\1.as." | me. 4^re