RE: generic-build-script
Yeah. It was the virus scanner. Thank you for your advice! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dessent Sent: Mittwoch, 5. März 2008 00:02 To: cygwin-apps@cygwin.com Subject: Re: generic-build-script Gergely Budai wrote: mv: cannot move `p7zip-4.57' to `../p7zip-4.57-orig': Permission denied This is probably caused by a handle remaining open for some short period of time after tar has completed writing the files, such that mv starts before it closes. On a normal system, I don't think this should ever be the case, i.e. handles should be closed by the time tar terminates. Sometimes if you have on-demand virus scanning however, those hooks cause the file to remain open for a short period after tar has written them. I've also seen this with on-demand/real-time disk defragmentation (in my case, Diskeeper v11 I believe) software, which I had to disable. The fact that it is transient definitely indicates that it's a race, but I wouldn't go pinning it on dual core; although that may exacerbate it. Brian
generic-build-script
I am using the generic-build-script as a template for my package scripts and
I have noticed a strange thing when running it.
When I make a './foo-vendor-release.sh first' run, I get randomly the
following error :
.
p7zip-4.57/man1/7zr.1
p7zip-4.57/README
p7zip-4.57/TODO
mv: cannot move `p7zip-4.57' to `../p7zip-4.57-orig': Permission denied
p7zip-4.57-1.sh
p7zip-4.57.tar.bz2
$
I have traced it down to the following lines:
...
unpack ${src_orig_pkg} \
mv ${BASEPKG} ../${BASEPKG}-orig \
...
Just like I said, I get this error randomly. (approx. 3 out of 5 runs)
Have anyone else experienced this problem?
Could it be a dualcore problem?
Cheers,
Gergely Budai
Re: generic-build-script
Gergely Budai wrote: mv: cannot move `p7zip-4.57' to `../p7zip-4.57-orig': Permission denied This is probably caused by a handle remaining open for some short period of time after tar has completed writing the files, such that mv starts before it closes. On a normal system, I don't think this should ever be the case, i.e. handles should be closed by the time tar terminates. Sometimes if you have on-demand virus scanning however, those hooks cause the file to remain open for a short period after tar has written them. I've also seen this with on-demand/real-time disk defragmentation (in my case, Diskeeper v11 I believe) software, which I had to disable. The fact that it is transient definitely indicates that it's a race, but I wouldn't go pinning it on dual core; although that may exacerbate it. Brian
Re: generic-build-script
Brian Dessent wrote: Gergely Budai wrote: mv: cannot move `p7zip-4.57' to `../p7zip-4.57-orig': Permission denied FYI: http://cygwin.com/ml/cygwin-apps/2007-06/msg00046.html [ITP] p7zip ...with special support for NOT building the (GPL-incompatible) RAR stuff. Never got enough votes, so it was eventually withdrawn. -- Chuck
Bug in latest generic-build-script when running spkg
The latest generic-build-script fails in the spkg step: -- tar: Cannot update compressed archives Try `tar --help' or `tar --usage' for more information. Ciao Volker
some comments on the generic build script
I'd like some feedback on changes I made to the gbs for
fortune-1.99.1-2.
--- gbs.sh 2006-01-15 17:46:43.875859200 -0800
+++ fortune-1.99.1-2.sh 2006-01-15 22:26:48.129188800 -0800
@@ -66,6 +66,8 @@
fi
export src_orig_pkg=${topdir}/${src_orig_pkg_name}
+export debian_patch=fortune-mod_1.99.1-3.diff.gz
+export debian_patch_name=${topdir}/$debian_patch
# determine correct names for generated files
export src_pkg_name=${FULLPKG}-src.tar.bz2
@@ -179,7 +184,8 @@
# change this if the original package was not tarred
# or if it doesn't unpack to a correct directory
unpack() {
- tar xv${opt_decomp}f $1
+ tar xv${opt_decomp}f $1 \
+ zcat $debian_patch_name | patch -p0
}
mkdirs() {
@@ -349,6 +352,7 @@
if [ -e ${src_orig_pkg}.sig ] ; then \
cp ${src_orig_pkg}.sig ${srcinstdir}/ ; \
fi \
+ cp ${debian_patch_name} ${srcinstdir}/${debian_patch} \
cp $0 ${srcinstdir}/`basename $0` \
name=$0 text=SCRIPT sigfile \
if [ ${SIG} -eq 1 ] ; then \
@@ -195,7 +201,7 @@
unpack ${src_orig_pkg} \
cd ${topdir} \
if [ -f ${src_patch} ] ; then \
-patch -Z -p0 ${src_patch} ;\
+patch -p0 ${src_patch} ;\
fi \
mkdirs \
if [ -f ${topdir}/${log_pkg_name} ] ; then \
These hunks include what are basically upstream patches and keep/regenerate
my patches separately.
The last hunk was needed because the debian patch file has no
timestamps, so patch complained about the timestamp being not as
expected for files in both it and my patch.
Would it be worthwhile doing s/debian_/upstream_/ and folding the
other hunks in to the regular version, with the zcat|patch and cp
omitted if the variable isn't set?
@@ -127,6 +129,9 @@
THANKS \
TODO \
USAGE \
+ Offensive \
+ cookie-files \
+ debian \
export install_docs=`for i in ${install_docs}; do echo $i; done | sort -u`
export test_rule=check
These are added install_docs. debian includes
debian/{README.Debian,README.Debian.offensive,changelog,copyright}. At
first, I had debian/ \, because there seemed to be code to support
that, but it included two copies of the files in the binary tarball,
one under /usr/share/doc/fortune-1.99.1 and one under
/usr/share/doc/fortune-1.99.1/debian. This seemed a little odd.
Another minor issue was that install_docs has NOTES, which picked up
the Notes file (which I wanted), but stored it with the name all in
caps. Is there an easy way in bash to go through a list of filenames
and set the capitalization the way it actually is on disk?
@@ -203,16 +209,12 @@
tar xvjf ${topdir}/${log_pkg_name}
fi )
}
+# fortune isn't autoconfusticated, just make objdir - srcdir symlinks
conf() {
(cd ${objdir} \
- CFLAGS=${MY_CFLAGS} LDFLAGS=${MY_LDFLAGS} \
- ${srcdir}/configure \
- --srcdir=${srcdir} --prefix=${prefix} \
- --exec-prefix='${prefix}' --sysconfdir=${sysconfdir} \
- --libdir='${prefix}/lib' --includedir='${prefix}/include' \
- --mandir='${prefix}/share/man' --infodir='${prefix}/share/info' \
- --libexecdir='${sbindir}' --localstatedir=${localstatedir} \
- --datadir='${prefix}/share' 21 | tee ${configurelogfile} )
+ (cd ${srcdir} find * -type d) | xargs mkdir -p \
+ (for dir in `find`; do find ${srcdir}/$dir -maxdepth 1 -type f | xargs ln -s
-t $dir; done) \
+ touch ${configurelogfile} )
}
reconf() {
(cd ${topdir} \
No configure, so I just made symlinks under objdir for all the files
under srcdir (except toplevel directories starting with .).
Would it make sense to include something like that in the regular
version whenever there's no configure file?
@@ -222,7 +224,7 @@
}
build() {
(cd ${objdir} \
- make CFLAGS=${MY_CFLAGS} 21 | tee ${makelogfile} )
+ make 21 | tee ${makelogfile} )
}
check() {
(cd ${objdir} \
The Makefile set a lot of important stuff in CFLAGS= (including -O2)
which this overrode. Is this a common problem? Should I have patched
the Makefile to use a different variable name and include CFLAGS in it?
@@ -250,6 +252,7 @@
find ${instdir}${prefix}/share/info -name *.info | xargs -r gzip -q ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
+true breaks cause unstr.8 is symlink to strfile.8 || \
find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
-name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
-name *.7 -o -name *.8 | xargs -r gzip -q ; \
Took me a while to figure out why this was breaking things. I have
these:
-rw-r--r-- 1 sthoenna None 11485 Jan 15 22:27 ./man6/fortune.6
-rw-r--r-- 1 sthoenna None 7512 Jan 15 22:27 ./man8/strfile.8
lrwxrwxrwx 1 sthoenna None 9 Jan 15 22:27 ./man8/unstr.8 - strfile.8
and when gzip tried to compress unstr.8, strfile.8 was no longer there
(having become strfile.8.gz), causing the whole build process to stop.
Any easy fixes to suggest?
@@ -331,7 +334,7 @@
unpack ${src_orig_pkg} \
mv ${BASEPKG} ../${BASEPKG}-orig \
cd ${topdir} \
- diff -urN -x '.build' -x '.inst' -x
Re: some comments on the generic build script
On Mon, 16 Jan 2006, Yitzchak Scott-Thoennes wrote:
I'd like some feedback on changes I made to the gbs for
fortune-1.99.1-2.
Sure. FWICS, some of the changes below make sense as general improvements
to the g-b-s.
--- gbs.sh 2006-01-15 17:46:43.875859200 -0800
+++ fortune-1.99.1-2.sh 2006-01-15 22:26:48.129188800 -0800
@@ -66,6 +66,8 @@
fi
export src_orig_pkg=${topdir}/${src_orig_pkg_name}
+export debian_patch=fortune-mod_1.99.1-3.diff.gz
+export debian_patch_name=${topdir}/$debian_patch
These variables seem to reverse the naming convention used in the rest of
the script. See, for example, the definitions of src_pkg and
src_pkg_name...
# determine correct names for generated files
export src_pkg_name=${FULLPKG}-src.tar.bz2
@@ -179,7 +184,8 @@
# change this if the original package was not tarred
# or if it doesn't unpack to a correct directory
unpack() {
- tar xv${opt_decomp}f $1
+ tar xv${opt_decomp}f $1 \
+ zcat $debian_patch_name | patch -p0
}
This makes sense, except that it should test for the presence of
$debian_patch (using conventional naming). Also, I agree that
debian_patch could be renamed to upstream_patch.
mkdirs() {
@@ -349,6 +352,7 @@
if [ -e ${src_orig_pkg}.sig ] ; then \
cp ${src_orig_pkg}.sig ${srcinstdir}/ ; \
fi \
+ cp ${debian_patch_name} ${srcinstdir}/${debian_patch} \
cp $0 ${srcinstdir}/`basename $0` \
name=$0 text=SCRIPT sigfile \
if [ ${SIG} -eq 1 ] ; then \
Ditto on this hunk.
@@ -195,7 +201,7 @@
unpack ${src_orig_pkg} \
cd ${topdir} \
if [ -f ${src_patch} ] ; then \
-patch -Z -p0 ${src_patch} ;\
+patch -p0 ${src_patch} ;\
fi \
mkdirs \
if [ -f ${topdir}/${log_pkg_name} ] ; then \
These hunks include what are basically upstream patches and keep/regenerate
my patches separately.
The last hunk was needed because the debian patch file has no
timestamps, so patch complained about the timestamp being not as
expected for files in both it and my patch.
Umm, right. However, I'd rather try keeping the timestamps if possible.
Is there a way to detect whether the patch has valid timestamps, or to
make patch ignore the timestamps if invalid?
Would it be worthwhile doing s/debian_/upstream_/ and folding the
other hunks in to the regular version, with the zcat|patch and cp
omitted if the variable isn't set?
Yes, IMO.
@@ -127,6 +129,9 @@
THANKS \
TODO \
USAGE \
+ Offensive \
+ cookie-files \
+ debian \
export install_docs=`for i in ${install_docs}; do echo $i; done | sort -u`
export test_rule=check
These are added install_docs.
This looks like a patch that needs to be maintained locally.
debian includes
debian/{README.Debian,README.Debian.offensive,changelog,copyright}. At
first, I had debian/ \, because there seemed to be code to support
that, but it included two copies of the files in the binary tarball,
one under /usr/share/doc/fortune-1.99.1 and one under
/usr/share/doc/fortune-1.99.1/debian. This seemed a little odd.
Huh. Probably a bug. I'm surprised at the two copies, though -- the
current code will pass all the regular files directly to /usr/bin/install,
and, AFAIK, /usr/bin/install does not replicate directory structure...
There *is* a small bug in the directory handling code which the patch
below fixes (I'll check it in shortly), but it doesn't seem to be related
to this behavior. Let me know if it fixes the problem for you, though.
--
Index: generic-build-script
===
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.43
diff -u -p -r1.43 generic-build-script
--- generic-build-script18 Oct 2005 05:01:36 - 1.43
+++ generic-build-script17 Jan 2006 04:37:19 -
@@ -257,7 +257,7 @@ install() {
templist= \
for fp in ${install_docs} ; do \
case $fp in \
- */) templist=$templist `cd ${srcdir} find $fp -type f` ;;
+ */) templist=$templist `find ${srcdir}/$fp -type f` ;;
*) for f in ${srcdir}/$fp ; do \
if [ -f $f ] ; then \
templist=$templist $f; \
--
Another minor issue was that install_docs has NOTES, which picked up
the Notes file (which I wanted), but stored it with the name all in
caps.
Interesting. I usually have CYGWIN=check_case:strict, which would avoid
matching Notes with NOTES.
Is there an easy way in bash to go through a list of filenames and set
the capitalization the way it actually is on disk?
I think setting shopt -s nocaseglob and changing NOTES to [N]OTES
should do it.
@@ -203,16 +209,12 @@
tar xvjf ${topdir}/${log_pkg_name}
fi )
}
+# fortune isn't autoconfusticated, just make objdir - srcdir symlinks
conf
[Patch] g-b-s: New command: upgrade-self. (was: Re: generic-build-script extension to update version numbers in README)
Op Fri, 18 Nov 2005 23:20:25 -0500 schreef Charles Wilson
in 437EA809.30204atcwilson.fastmail.fm:
: Igor Pechtchanski wrote:
[new gbs features]
: Well, the problem is, logging is a decorator: it decorates the existing
: functions. Unless you want a whole new build-with-logging() function
: that has to be maintained in parallel with the regular build() function
: for package foo, I don't see how this particular feature can be moved
: out of the core gbs without getting REAL ugly: building cmd strings,
: possibly decorating _those_, and then eval'ing them. Sad, really.
How about:
build_with_logging() {
build 21 |tee logfilename
}
?
: Every new feature added to gbs makes it that much more difficult for
: maintainers to keep pace with gbs updates when they update their
: packages. Please think carefully before adding new stuff: is feature X
: *really* worth it?
So, I'm gonna suggest another feature. :-
: BTW, thanks for your comments, Chuck. I'm afraid I lost sight of the fact
: that many maintainers have private mods to the g-b-s, and that feature
: updates may cause them trouble. We should definitely rectify this.
: The problem comes in when trying to 'upgrade' our fork to the ongoing
: development in the 'trunk'. It really is a branch-and-merge-from type
: of operation. Maybe I should give that local cvs mirror idea some more
: thought...
I came up with the following, which should make upgrading easier in
the future. You'll still have to hand-merge this into your existing
scripts though, sorry, but from then on, non-conflicting updates to
g-b-s should be easily retrieved.
How it works: When invoked with the `upgrade-self' command, the script
attempts to get the HEAD-version from cvs, if it hasn't in the last
24 hours. This HEAD-version is invoked with the `version' command
to get it's CVS-revision. If it was just downloaded, the HEAD revision
is stored in /usr/share/gbs as generic-build-script-HEAD and
generic-build-script-HEAD-revision If the HEAD-revision doesn't
match this build-script's CVS-revision, the build-script's revision
is gotten from /usr/share/gbs if available, otherwise it is gotten
through CVS and stored in /usr/share/gbs. Than merging is done
on a copy of the build-script. If the merge has conflicts, one is
given the possibility to edit the script and the option to reject the
new script. Finally the new script is copied into place and executed
with the remaining parameters.
ChangeLog-entry: (Please fix the at.)
2005-11-21 Bas van Gompel g-b-s-patch.buzzatbavag.tmfweb.nl
* templates/generic-build-script Add upgrade-self to main switch.
(help): Add upgrade_self.
(upgrade_self): new function.
L8r,
Buzz.
--
) | | ---/ ---/ 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
Index: packaging/templates/generic-build-script
===
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.43
diff -u -p -r1.43 generic-build-script
--- packaging/templates/generic-build-script18 Oct 2005 05:01:36 -
1.43
+++ packaging/templates/generic-build-script20 Nov 2005 21:05:49 -
@@ -163,7 +163,7 @@ Actions are:
spkg, src-package Prepare the source package ${src_pkg_name}
finish Remove source directory ${srcdir}
checksig Validate GPG signatures (requires gpg)
+upgrade-self Merge changes from upstream generic-build-script.
first Full run for spkg (mkdirs, spkg, finish)
almostall Full run for bin pkg, except for finish
allFull run for bin pkg
@@ -402,6 +403,111 @@ checksig() {
echo You need the gnupg package installed in order to check signatures.
; \
fi
}
+upgrade_self() {
+ # make sure we have cvs and merge.
+ if ! which merge /dev/null || ! which cvs /dev/null; then
+echo $0 upgrade-self: I need merge and cvs!
+exit 1
+ fi
+ scriptname=`basename $0`
+ my_gbs_ver=$(version |sed -e 's/.* //')
+ gbs_cvs_repo=':pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps'
+ gbs_cvs_dir='packaging/templates/'
+ mkdir -p /usr/share/gbs
+ share_gbs_fresh=false
+ test -n $(find /usr/share/gbs -name generic-build-script-HEAD -mtime -1) \
+ share_gbs_fresh=true
+ # get HEAD
+ if ${share_gbs_fresh}; then
+cp /usr/share/gbs/generic-build-script-HEAD \
+ /tmp/generic-build-script-HEAD-$$-1.sh
+ else
+echo $0 upgrade-self will now connect to the Red Hat CVS-server.
+echo If you are prompted for a password, press 'Enter'.
+cvs -z3 -d ${gbs_cvs_repo} co -p ${gbs_cvs_dir}generic-build-script \
+ /tmp/generic-build-script-HEAD-$$-1.sh
+ fi
+ # fool version-check
Re: generic-build-script extension to update version numbers in README
Igor Pechtchanski wrote: [...] P.S. It'd be a different story if we were using an 'engine' with external overrides, like mingwports or cgf's netrel(?) -- then mods to the engine to provide new features would be distinct from the package-specific overrides. But gbs ain't like that. What's stopping us from trying to get there? Anything specific to the nature of the g-b-s? One way to address this may be defining more functions like unpack() to contain the pluggable/overridable behavior. What would you think about an autoconf-like approach generating a package-VER.sh script from some package.sh.in (yes, no version). Then fixes and new features will be added to only one generation tool (autogbs ?-)) which can be part of a standard Cygwin package managed by setup.exe. The generator can check the actual structure of the source tree to create a smaller build-script. New features can be opt'ed in by directives in the package.sh.in script if desired. Like with autoconf, it would be possibled to do special hacks by including shell code verbatim. The package-sh.in can be put in the CVS of maintainer or be part of projects sourcecode (e.g. as some Cygwin-build-script.sh.in) Christian
Re: generic-build-script extension to update version numbers in README
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Franke wrote:
What would you think about an autoconf-like approach generating a
package-VER.sh script from some package.sh.in (yes, no version).
Then fixes and new features will be added to only one generation tool
(autogbs ?-)) which can be part of a standard Cygwin package managed by
setup.exe.
The generator can check the actual structure of the source tree to
create a smaller build-script.
New features can be opt'ed in by directives in the package.sh.in script
if desired.
Like with autoconf, it would be possibled to do special hacks by
including shell code verbatim.
It is a good idea, but I would avoid .in naming, since I think we will
want to go beyond simple autoconf-style variable substitution.
I'm already doing programmatic editing of the g-b-s for my own packages.
Attached is 'gbsmunge.py', which reads a control file, and the
generic-build-script source, and outputs a build script munged according
to instructions in the control file.
For illustrative purposes, here is the control file for my neon package:
===
ConfigureArg --enable-shared
ConfigureArg --disable-static
ConfigureArg --with-ssl
SubPackage libneon24-$VER-$REL.tar.bz2 usr/bin/cygneon-24.dll
===
Max.
P.S.: The control file for the (much more complex) apache2 package:
==
ConfigureArg --enable-shared
ConfigureArg --disable-static
ConfigureArg --with-apr=/usr
ConfigureArg --with-apr-util=/usr
ConfigureArg --with-neon=/usr
ConfigureArg --with-swig=/usr/bin/swig
ConfigureArg --with-apxs=/usr/sbin/apxs2
SubPackage subversion-devel-$VER-$REL.tar.bz2 usr/include
usr/lib/libsvn_[a-rt-z]* usr/lib/libsvn_subr*
SubPackage subversion-python-$VER-$REL.tar.bz2 usr/lib/python*
usr/bin/cygsvn_swig_py* usr/lib/libsvn_swig_py*
SubPackage subversion-perl-$VER-$REL.tar.bz2 usr/lib/perl5
usr/bin/cygsvn_swig_perl* usr/lib/libsvn_swig_perl*
SubPackage subversion-apache2-$VER-$REL.tar.bz2 usr/lib/apache2
SubPackage subversion-book-$VER-$REL.tar.bz2
usr/share/doc/subversion-*/svn-book.html
usr/share/doc/subversion-*/images
AutoreconfCmd ./autogen.sh
AutoreconfCmd find . -name autom4te.cache | xargs rm -rf
AutoreconfCmd sed -e 's/relink_command=\\$relink_command\\//'
ac-helpers/ltmain.sh gbs.$$.tmp
mv gbs.$$.tmp ac-helpers/ltmain.sh
MakeTarget
MakeTarget swig-py swig_pydir=/usr/lib/python2.4/site-packages/libsvn
swig_pydir_extra=/usr/lib/python2.4/site-packages/svn
MakeTarget swig-pl
MakeInstallTarget install
MakeInstallTarget install-swig-py
swig_pydir=/usr/lib/python2.4/site-packages/libsvn
swig_pydir_extra=/usr/lib/python2.4/site-packages/svn
MakeInstallTarget install-swig-pl
InstallExtraCmd mkdir -p ${instdir}/usr/share/doc/${BASEPKG}
InstallExtraCmd cp ${srcdir}/doc/book/svn-book.html
${instdir}/usr/share/doc/${BASEPKG}/svn-book.html
InstallExtraCmd cp -r ${srcdir}/doc/book/images
${instdir}/usr/share/doc/${BASEPKG}/images
# Kill perllocal.pod and containing dirs
InstallExtraCmd rm ${instdir}/usr/lib/perl5/5.8/cygwin/perllocal.pod
InstallExtraCmd rmdir ${instdir}/usr/lib/perl5/5.8/cygwin
InstallExtraCmd rmdir ${instdir}/usr/lib/perl5/5.8
UnpackExclude */apr
UnpackExclude */apr-util
UnpackExclude */neon
DiffExclude configure
DiffExclude build-outputs.mk
==
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDf3HnfFNSmcDyxYARAkCXAKDcA+n68ib+7RoGPB5KA5PKh+z82wCbBL6Z
LcCrLFQDRtSn07pjb2GYMFE=
=Qa9j
-END PGP SIGNATURE-
#!/usr/bin/python
# A script to customize the generic-build-script based on a set of rules
# Rules are expressed by a simple configuration file
# Last updated for revision 1.38
#
# Syntax: gbsmunge.py -F configfile [file-to-filter]
import sys, os, fileinput, getopt
class PkgConfig:
I_DEFAULT, = range(1)
info = {
ConfigureArg: ([], ),
TestMakeRule: (, ),
PrepCmd:([], ),
MakeTarget: ([], ),
MakeInstallTarget: ([], ),
InstallExtraCmd:([], ),
PreConfigureCmd:([], ),
AutoreconfCmd: ([], ),
UnpackExclude: ([], ),
DiffExclude:(['*.orig', '*.rej'], ),
ExtraDocFile: ([], ),
NoDefaultConfigureArgs: (False, ),
BuildInSourceDir: (False, ),
NoDiffNewFiles: (False, ),
AlternateTarballStem: (, ),
AlternateShareDocDir: (, ),
VersionLimit: (, ),
SubPackage: ({}, ),
ExtraFile: ({}, ),
}
def __init__(self):
for directive, info in self.info.items():
setattr(self, directive, info[self.I_DEFAULT])
def register_option(self, optstr):
Parse and store a single configuration statement
directive_and_arg = optstr.split( , 1)
directive = directive_and_arg[0]
try:
arg = directive_and_arg[1]
except IndexError:
arg = None
try:
info = self.info[directive]
except KeyError:
sys.exit(Invalid directive '%s' % directive)
if type(info[self.I_DEFAULT]) == list
Re: generic-build-script extension to update version numbers in README
Charles Wilson wrote: I'd like to make a request: gbs is getting out of control with this feature and that feature added. Some of these tasks are NEVER going to be performed by anyone other than the primary maintainer: has anyone actually used 'foo.sh list' or 'foo.sh depends'? I use these two functions often, to create the README ;) However, I agree with your opinion, I use several years old scripts for some of my packages, IIRC these are hacked versions of Charles' original build script. It still works and I don't see the point to upgrade. However, every maintainer is free to add as many features as needed to get her packages out of the door. Gerrit
generic-build-script extension to update version numbers in README
[Resummited to cygwin-apps on request of Igor]
Hi,
the build-script of the smartmontools package creates the
Cygwin/package-*.README file from
srcdir/CYGWIN-PATCHES/package.README.in by replacing VER/REL with the
current version/release numbers.
This might be useful for other packages to avoid extra editing of README
on each minor release.
A patch for generic-build-script 1.43 is attached.
Christian
--- generic-build-script.orig Sat Nov 12 15:21:55 2005
+++ generic-build-scriptFri Nov 18 10:54:58 2005
@@ -220,9 +220,16 @@
mkdir -p ${objdir} \
conf )
}
+buildreadme() {
+ sed s/VER/${VER}/g;s/REL/${REL}/g
+}
build() {
(cd ${objdir} \
- make CFLAGS=${MY_CFLAGS} 21 | tee ${makelogfile} )
+ make CFLAGS=${MY_CFLAGS} 21 | tee ${makelogfile} \
+ if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README.in ]; then \
+buildreadme ${srcdir}/CYGWIN-PATCHES/${PKG}.README.in \
+ ${objdir}/${FULLPKG}.README; \
+ fi )
}
check() {
(cd ${objdir} \
@@ -230,7 +237,8 @@
}
clean() {
(cd ${objdir} \
- make clean )
+ make clean \
+ rm -f ${objdir}/${FULLPKG}.README )
}
install() {
(cd ${objdir} \
@@ -269,8 +277,11 @@
/usr/bin/install -m 644 $templist \
${instdir}${prefix}/share/doc/${SHORTPKG} ; \
fi \
- if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README ]; then \
-/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/${PKG}.README \
+ if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README.in ]; then \
+/usr/bin/install -m 644 ${objdir}/${FULLPKG}.README \
+ ${instdir}${prefix}/share/doc/Cygwin/${SHORTPKG}.README ; \
+ elif [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README ]; then \
+/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/${PKG}.README ] \
${instdir}${prefix}/share/doc/Cygwin/${SHORTPKG}.README ; \
elif [ -f ${srcdir}/CYGWIN-PATCHES/README ] ; then \
/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/README \
Re: generic-build-script extension to update version numbers in README
Christian Franke wrote: the build-script of the smartmontools package creates the Cygwin/package-*.README file from srcdir/CYGWIN-PATCHES/package.README.in by replacing VER/REL with the current version/release numbers. This might be useful for other packages to avoid extra editing of README on each minor release. Christian, please don't take offense; the following semi-rant is not aimed at you, but is a product of my frustration with gbs. It's become an issue for me in that the difficulty of trying to track changes in the gbs is a significant portion of my effort when releasing a new version of an existing package. I'd like to make a request: gbs is getting out of control with this feature and that feature added. Some of these tasks are NEVER going to be performed by anyone other than the primary maintainer: has anyone actually used 'foo.sh list' or 'foo.sh depends'? It's a nice feature, but how useful is it, really? Ditto this maintainer-only 'muck with the README' script. Could these added features be simply refactored into ancillary scripts instead of integrated into the main gbs? E.g. ./foo.sh externaltool /path/to/update-readme where the gbs's externaltool function would simply source the update-readme fragment -- and the update-readme fragment would inherit all of the variable settings from the top of the gbs. I'd figure that 'update-readme' would NOT be shipped with cygwin packages, but could be downloaded from the sourceware cvs by a maintainer who wanted to use it on her machine when maintaining her package foo. Thus, I don't see exploding out a bunch of 'build.frag' and 'prep.frag' and 'mkpatch.frag' fragments; the current intrinsic functions in the gbs should stay there. The reason I bring this up is that recently I re-packaged cvs (and am also working on updating gettext and libiconv) and decided to take the latest-and-greatest gbs and merge in my package-specific mods. It was quite a bit more difficult than it should have been given all the thrash in the main gbs. Basically, EVERY package is a fork... I eventually decided to NOT use the latest-and-greatest, but instead used the version just before LOGGING support was added. And honestly, I don't think I'll ever bother to up-merge again. That version of gbs does everything I want and I see no need for auto-edit README or LOGGING support. If I want a log, I'll tee the output of configure or make myself. Logs are for me, the maintainer... Every new feature added to gbs makes it that much more difficult for maintainers to keep pace with gbs updates when they update their packages. Please think carefully before adding new stuff: is feature X *really* worth it? -- Chuck P.S. It'd be a different story if we were using an 'engine' with external overrides, like mingwports or cgf's netrel(?) -- then mods to the engine to provide new features would be distinct from the package-specific overrides. But gbs ain't like that.
Re: generic-build-script extension to update version numbers in README
On Fri, 18 Nov 2005, Charles Wilson wrote: Christian Franke wrote: the build-script of the smartmontools package creates the Cygwin/package-*.README file from srcdir/CYGWIN-PATCHES/package.README.in by replacing VER/REL with the current version/release numbers. This might be useful for other packages to avoid extra editing of README on each minor release. Christian, please don't take offense; the following semi-rant is not aimed at you, but is a product of my frustration with gbs. It's become an issue for me in that the difficulty of trying to track changes in the gbs is a significant portion of my effort when releasing a new version of an existing package. I'd like to make a request: gbs is getting out of control with this feature and that feature added. Some of these tasks are NEVER going to be performed by anyone other than the primary maintainer: has anyone actually used 'foo.sh list' or 'foo.sh depends'? At the time I've thought long and hard about integrating more features. The original argument for including them was to allow the maintainers to release packages with minor modifications of the g-b-s (mostly to set parameters). And this worked for most *new* packages (though I agree that the maintainer-only features are getting clunky). It probably won't work for any package that has a more sophisticated build procedure. Perhaps it's time to rethink this. It's a nice feature, but how useful is it, really? Ditto this maintainer-only 'muck with the README' script. BTW, the muck with the README idea isn't new -- I still have a link to an unapplied patch from last February that does essentially that (and more). That patch was dubbed too complex, and the original submitter never followed up. Could these added features be simply refactored into ancillary scripts instead of integrated into the main gbs? E.g. ./foo.sh externaltool /path/to/update-readme where the gbs's externaltool function would simply source the update-readme fragment -- and the update-readme fragment would inherit all of the variable settings from the top of the gbs. I'd figure that 'update-readme' would NOT be shipped with cygwin packages, but could be downloaded from the sourceware cvs by a maintainer who wanted to use it on her machine when maintaining her package foo. FWIW, I like this idea. A lot. Maybe we should have only *one* ancillary script that contains all maintainer-only features. That way, ./foo.sh maintainer-action update-readme would do what you said (say, use the 'update-readme' function from a local 'maintainer.sh', or pass the 'update-readme' option to some function that would properly dispatch it, or even fetch the proper 'maintainer.sh' version from CVS on sourceware.org and eval it). That way, the package maintainers would have less to worry about, since the core g-b-s would not change all that often. Thus, I don't see exploding out a bunch of 'build.frag' and 'prep.frag' and 'mkpatch.frag' fragments; the current intrinsic functions in the gbs should stay there. The reason I bring this up is that recently I re-packaged cvs (and am also working on updating gettext and libiconv) and decided to take the latest-and-greatest gbs and merge in my package-specific mods. It was quite a bit more difficult than it should have been given all the thrash in the main gbs. Basically, EVERY package is a fork... Yes, but there's the question of the extent to which it has diverged. If all you do is change parameters, it ought to be easy. It would help if you outlined the difficulties you had (feel free to email me privately, though I think a public summary might produce more patches). I eventually decided to NOT use the latest-and-greatest, but instead used the version just before LOGGING support was added. And honestly, I don't think I'll ever bother to up-merge again. That version of gbs does everything I want and I see no need for auto-edit README or LOGGING support. If I want a log, I'll tee the output of configure or make myself. Logs are for me, the maintainer... Heh, the argument for including the logs (which I, after having installed some package source tarballs, think aren't such a hot idea anymore) was that when users build the packages on their machines, they can see if they get a different configuration from what the maintainer had. And it may be a useful feature to run the build with logging turned on (though I don't think it should be the default). Perhaps another job for an external maintainer.sh script. Every new feature added to gbs makes it that much more difficult for maintainers to keep pace with gbs updates when they update their packages. Please think carefully before adding new stuff: is feature X *really* worth it? True enough, though this is the first official complaint from an active package maintainer about the new features. Let me try to find some time (probably in a couple of weeks) to extract the non-core
RE: [PATCH] generic-build-script
[snip] Gary, Do you use the g-b-s for mutt? Yep. For the last two or three releases. If so, would you care to submit the changes that factor out config variables *you* needed? If possible, please leave the default, rather than mutt-specific, values in the patch, but I'd rather tweak the patch to restore the default values than have no patch at all. Sure, I'll see if I can do that tonight. IIRC I had it set up in a fairly generic way, should I have ever gotten around to submitting it. -- Gary R. Van Sickle
RE: [PATCH] generic-build-script
On Tue, 21 Jun 2005, Gary R. Van Sickle wrote: [snip] It's perhaps worth mentioning that I don't maintain any per-package customizations to the g-b-s directly, but instead have written myself a Python script which modifies the basic g-b-s according to a per-package rules file. For example, here are my rules for neon: ConfigureArg --enable-shared ConfigureArg --disable-static ConfigureArg --with-ssl SubPackage libneon24-$VER-$REL.tar.bz2 usr/bin/cygneon-24.dll The script is attached. Thanks, I'll take a better look at the script later, but at the very least the configure args can be factored out into a variable. FWIW, I don't have any ideas on how to handle subpackages properly, but perhaps your script contains some hints on that as well. Igor I've had to do the same thing with config vars with mutt, and I'm sure pretty much every package that uses it needs to. Gary, Do you use the g-b-s for mutt? If so, would you care to submit the changes that factor out config variables *you* needed? If possible, please leave the default, rather than mutt-specific, values in the patch, but I'd rather tweak the patch to restore the default values than have no patch at all. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: [PATCH] generic-build-script
On Tue, 21 Jun 2005, Max Bowsher wrote:
Two generic build script patches.
Number 1:
In doing the httpd-apache2 thing recently mentioned, I found that g-b-s
could use some tweaks to support this better. ${BASEPKG} is currently
used by the script in two different ways:
1): name-version of the base upstream package
2): name-version of the cygwin package
Of course, normally these are the same, but in my case they are not.
Therefore, the following patch changes all occurrences where ${BASEPKG}
is used in the second sense to ${PKG}-${VER}, so that ${BASEPKG} may be
redefined in my case.
[patch snipped]
Number 2:
Use xargs --no-run-if-empty. I don't recall for what package I needed
this, but I've had it locally for some time. In any case, it is good
bulletproofing.
[patch snipped]
The first patch looks good. I was about to apply it, but realized that
it's missing a ChangeLog entry. Care to post one?
About the second patch: I usually prefer to use the short option (-r).
There were a few other places that didn't use it. I've made the
appropriate modifications and committed the change.
Thanks for the patches,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: [PATCH] generic-build-script
Max Bowsher wrote:
[...]
Of course, normally these are the same, but in my case they are not.
Therefore, the following patch changes all occurrences where ${BASEPKG}
is used in the second sense to ${PKG}-${VER}, so that ${BASEPKG} may be
redefined in my case.
[...]
Max,
My two cents:
Stick a comment above the definition for BASEPKG to explain the scenario
where BASEPKG and PKG-VER will be different... otherwise you'll get
dorks like me thinking that a patch reversing your patch would be
useful, and such a thing must just slip in by accident. Of course, the
comment would also help maintainers figure out that this feature is
present and that they can use it.
Since I've not written three times more words that would be in such a
comment, I might as well give it a go:
# NOTE: BASEPKG is name-version of the upstream package. Usually this
# is equal to ${PKG}-${VER}, except in the case where the Cygwin package
# name is different than the upstream package name (e.g. upstream:
# foo-1.0 BASEPKG=foo-1.0, Cygwin package: bar-1.0 PKG=bar VER=1.0).
Feel free to reword that.
Harold
Re: [PATCH] generic-build-script
s/Since I've not/Since I've now/ Harold Harold L Hunt II wrote: Since I've not written three times more words that would be in such a comment, I might as well give it a go:
Re: [PATCH] generic-build-script
On Tue, 21 Jun 2005, Harold L Hunt II wrote:
Max Bowsher wrote:
[...]
Of course, normally these are the same, but in my case they are not.
Therefore, the following patch changes all occurrences where ${BASEPKG} is
used in the second sense to ${PKG}-${VER}, so that ${BASEPKG} may be
redefined in my case.
[...]
Max,
My two cents:
Stick a comment above the definition for BASEPKG to explain the scenario
where BASEPKG and PKG-VER will be different... otherwise you'll get
dorks like me thinking that a patch reversing your patch would be
useful, and such a thing must just slip in by accident. Of course, the
comment would also help maintainers figure out that this feature is
present and that they can use it.
Since I've not written three times more words that would be in such a
comment, I might as well give it a go:
# NOTE: BASEPKG is name-version of the upstream package. Usually this
# is equal to ${PKG}-${VER}, except in the case where the Cygwin package
# name is different than the upstream package name (e.g. upstream:
# foo-1.0 BASEPKG=foo-1.0, Cygwin package: bar-1.0 PKG=bar VER=1.0).
Feel free to reword that.
Good point, Harold. In fact, looking at the ChangeLog, I was one of
those dorks. :-)
The easiest solution would probably be to define two variables, BASEPKG
and ORIGPKG, and set them to the same value initially. We'd still need a
comment describing why there are two variables, and what ORIGPKG is useful
for.
If BASEPKG seems better for the upstream package name, I'm open to
suggestions for the name of the variable containing the ${PKG}-${REL}
combo.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: [PATCH] generic-build-script
Igor Pechtchanski wrote:
On Tue, 21 Jun 2005, Max Bowsher wrote:
Two generic build script patches.
Number 1:
In doing the httpd-apache2 thing recently mentioned, I found that g-b-s
could use some tweaks to support this better. ${BASEPKG} is currently
used by the script in two different ways:
1): name-version of the base upstream package
2): name-version of the cygwin package
Of course, normally these are the same, but in my case they are not.
Therefore, the following patch changes all occurrences where ${BASEPKG}
is used in the second sense to ${PKG}-${VER}, so that ${BASEPKG} may be
redefined in my case.
[patch snipped]
The first patch looks good. I was about to apply it, but realized that
it's missing a ChangeLog entry. Care to post one?
2005-06-21 Max Bowsher [EMAIL PROTECTED]
* generic-build-script (file scope, install): Use ${BASEPKG} only to
refer to the upstream base package. Use ${PKG}-${VER} explicitly when
referring to the Cygwin package with the release number omitted.
Max.
Re: [PATCH] generic-build-script
On Tue, 21 Jun 2005, Max Bowsher wrote:
Igor Pechtchanski wrote:
On Tue, 21 Jun 2005, Harold L Hunt II wrote:
Max Bowsher wrote:
[...]
Of course, normally these are the same, but in my case they are not.
Therefore, the following patch changes all occurrences where ${BASEPKG}
is
used in the second sense to ${PKG}-${VER}, so that ${BASEPKG} may be
redefined in my case.
[...]
Max,
My two cents:
Stick a comment above the definition for BASEPKG to explain the scenario
where BASEPKG and PKG-VER will be different... otherwise you'll get
dorks like me thinking that a patch reversing your patch would be
useful, and such a thing must just slip in by accident. Of course, the
comment would also help maintainers figure out that this feature is
present and that they can use it.
Since I've not written three times more words that would be in such a
comment, I might as well give it a go:
# NOTE: BASEPKG is name-version of the upstream package. Usually this
# is equal to ${PKG}-${VER}, except in the case where the Cygwin package
# name is different than the upstream package name (e.g. upstream:
# foo-1.0 BASEPKG=foo-1.0, Cygwin package: bar-1.0 PKG=bar VER=1.0).
Feel free to reword that.
Good point, Harold. In fact, looking at the ChangeLog, I was one of
those dorks. :-)
The easiest solution would probably be to define two variables, BASEPKG
and ORIGPKG, and set them to the same value initially. We'd still need a
comment describing why there are two variables, and what ORIGPKG is useful
for.
If BASEPKG seems better for the upstream package name, I'm open to
suggestions for the name of the variable containing the ${PKG}-${REL}
combo.
Hmm. It seemed sort-of elegant to me to just use ${PKG}-${VER}, rather than
defining another variable.
I'd go with just a comment.
Fair enough. Want to resubmit the patch with the comment?
If not, how about names:
BASEPKG
CYGPKG_NV
CYGPKG_NVR
or
BASEPKG
SHORTPKG
FULLPKG
?
I like the latter, FWIW. But we could go with ${PKG}-${VER} for now, and
factor it out into a variable later if it becomes a nuisance.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: [PATCH] generic-build-script
Igor Pechtchanski wrote:
On Tue, 21 Jun 2005, Max Bowsher wrote:
Hmm. It seemed sort-of elegant to me to just use ${PKG}-${VER}, rather than
defining another variable.
I'd go with just a comment.
Fair enough. Want to resubmit the patch with the comment?
If not, how about names:
BASEPKG
CYGPKG_NV
CYGPKG_NVR
or
BASEPKG
SHORTPKG
FULLPKG
?
I like the latter, FWIW. But we could go with ${PKG}-${VER} for now, and
factor it out into a variable later if it becomes a nuisance.
As I considered the comment, I realized it was easier to explain if both had a
name. So, I went with SHORTPKG.
2005-06-21 Max Bowsher [EMAIL PROTECTED]
* generic-build-script (SHORTPKG): New variable.
(install): Use ${SHORTPKG} instead of ${BASEPKG} when referring to the
Cygwin package with the release number omitted, rather than the
upstream base package.
Index: generic-build-script
===
RCS file:
/home/mirror/cvsmirror/cygwin-apps-cvs/packaging/templates/generic-build-script,v
retrieving revision 1.32
diff -u -p -r1.32 generic-build-script
--- generic-build-script21 Jun 2005 22:08:41 - 1.32
+++ generic-build-script21 Jun 2005 23:35:22 -
@@ -34,8 +34,14 @@ tscriptname=`basename $0 .sh`
export PKG=`echo $tscriptname | sed -e 's/\-[^\-]*\-[^\-]*$//'`
export VER=`echo $tscriptname | sed -e s/${PKG}\-// -e 's/\-[^\-]*$//'`
export REL=`echo $tscriptname | sed -e s/${PKG}\-${VER}\-//`
+# BASEPKG refers to the upstream base package
+# SHORTPKG refers to the Cygwin package
+# Normally, these are identical, but if the Cygwin package name is different
+# from the upstream package name, you will want to redefine BASEPKG.
+# Example: For Apache 2, BASEPKG=httpd-2.x.xx but SHORTPKG=apache2-2.x.xx
export BASEPKG=${PKG}-${VER}
-export FULLPKG=${BASEPKG}-${REL}
+export SHORTPKG=${PKG}-${VER}
+export FULLPKG=${PKG}-${VER}-${REL}
# determine correct decompression option and tarball filename
export src_orig_pkg_name=
@@ -178,7 +184,7 @@ install() {
rm -f ${instdir}${f} ; \
fi ;\
done \
- for d in ${prefix}/share/doc/${BASEPKG} ${prefix}/share/doc/Cygwin ; do \
+ for d in ${prefix}/share/doc/${SHORTPKG} ${prefix}/share/doc/Cygwin ; do \
if [ ! -d ${instdir}${d} ] ; then \
mkdir -p ${instdir}${d} ;\
fi ;\
@@ -204,14 +210,14 @@ install() {
done \
if [ ! x$templist = x ]; then \
/usr/bin/install -m 644 $templist \
- ${instdir}${prefix}/share/doc/${BASEPKG} ; \
+ ${instdir}${prefix}/share/doc/${SHORTPKG} ; \
fi \
if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README ]; then \
/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/${PKG}.README \
- ${instdir}${prefix}/share/doc/Cygwin/${BASEPKG}.README ; \
+ ${instdir}${prefix}/share/doc/Cygwin/${SHORTPKG}.README ; \
elif [ -f ${srcdir}/CYGWIN-PATCHES/README ] ; then \
/usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/README \
- ${instdir}${prefix}/share/doc/Cygwin/${BASEPKG}.README ; \
+ ${instdir}${prefix}/share/doc/Cygwin/${SHORTPKG}.README ; \
fi \
if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.sh ] ; then \
if [ ! -d ${instdir}${sysconfdir}/postinstall ]; then \
RE: [PATCH] generic-build-script
If BASEPKG seems better for the upstream package name,
What about just ${UPSTREAM_PACKAGE_NAME}?
--
Gary R. Van Sickle
Re: [PATCH] generic-build-script
On Wed, 22 Jun 2005, Max Bowsher wrote:
Igor Pechtchanski wrote:
On Tue, 21 Jun 2005, Max Bowsher wrote:
Hmm. It seemed sort-of elegant to me to just use ${PKG}-${VER},
rather than defining another variable.
I'd go with just a comment.
Fair enough. Want to resubmit the patch with the comment?
If not, how about names:
BASEPKG
CYGPKG_NV
CYGPKG_NVR
or
BASEPKG
SHORTPKG
FULLPKG
?
I like the latter, FWIW. But we could go with ${PKG}-${VER} for now, and
factor it out into a variable later if it becomes a nuisance.
As I considered the comment, I realized it was easier to explain if both
had a name. So, I went with SHORTPKG.
2005-06-21 Max Bowsher maxbatukf.net
* generic-build-script (SHORTPKG): New variable.
(install): Use ${SHORTPKG} instead of ${BASEPKG} when referring to the
Cygwin package with the release number omitted, rather than the
upstream base package.
Thanks. Applied with one tiny change:
export BASEPKG=${PKG}-${VER}
-export FULLPKG=${BASEPKG}-${REL}
+export SHORTPKG=${PKG}-${VER}
+export FULLPKG=${PKG}-${VER}-${REL}
+export FULLPKG=${SHORTPKG}-${REL}
I still think that it makes sense to define FULLPKG in terms of SHORTPKG.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
RE: [PATCH] generic-build-script
On Tue, 21 Jun 2005, Gary R. Van Sickle wrote:
If BASEPKG seems better for the upstream package name,
What about just ${UPSTREAM_PACKAGE_NAME}?
You know, the thought did cross my mind. But the above is just unwieldy
enough to remove it from consideration.
OTOH, it would be nice if all of the configuration variables in the GBS
(i.e., those that may be changed by the maintainers) were collected in one
place, with comments like the one Harold suggested (and Max added).
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: [PATCH] generic-build-script
On Wed, 22 Jun 2005, Max Bowsher wrote:
Igor Pechtchanski wrote:
On Tue, 21 Jun 2005, Gary R. Van Sickle wrote:
If BASEPKG seems better for the upstream package name,
What about just ${UPSTREAM_PACKAGE_NAME}?
You know, the thought did cross my mind. But the above is just unwieldy
enough to remove it from consideration.
OTOH, it would be nice if all of the configuration variables in the GBS
(i.e., those that may be changed by the maintainers) were collected in one
place, with comments like the one Harold suggested (and Max added).
Problem is, it's not just variables.
Any moderately complex package can require all sorts of tweaks.
Yes, true. Particularly the unpack() function, which only handles
.tar.* files for now, and needs to be redefined for other packaging
methods.
It's perhaps worth mentioning that I don't maintain any per-package
customizations to the g-b-s directly, but instead have written myself a
Python script which modifies the basic g-b-s according to a per-package
rules file.
For example, here are my rules for neon:
ConfigureArg --enable-shared
ConfigureArg --disable-static
ConfigureArg --with-ssl
SubPackage libneon24-$VER-$REL.tar.bz2 usr/bin/cygneon-24.dll
The script is attached.
Thanks, I'll take a better look at the script later, but at the very least
the configure args can be factored out into a variable. FWIW, I don't
have any ideas on how to handle subpackages properly, but perhaps your
script contains some hints on that as well.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ [EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-'Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
RE: [PATCH] generic-build-script
[snip] It's perhaps worth mentioning that I don't maintain any per-package customizations to the g-b-s directly, but instead have written myself a Python script which modifies the basic g-b-s according to a per-package rules file. For example, here are my rules for neon: ConfigureArg --enable-shared ConfigureArg --disable-static ConfigureArg --with-ssl SubPackage libneon24-$VER-$REL.tar.bz2 usr/bin/cygneon-24.dll The script is attached. Thanks, I'll take a better look at the script later, but at the very least the configure args can be factored out into a variable. FWIW, I don't have any ideas on how to handle subpackages properly, but perhaps your script contains some hints on that as well. Igor I've had to do the same thing with config vars with mutt, and I'm sure pretty much every package that uses it needs to. -- Gary R. Van Sickle
RE: Possible bug with generic build script.
On Wed, 13 Oct 2004, Charles Wilson wrote:
Igor Pechtchanski wrote:
You're right, it *is* broken. It was never intended to be used with
subdirectories, so I never tested it. I'll try to come up with a way
of accomodating subdirs shortly.
In fact, it shouldn't've worked with wildcards either, the way it was
written... Oops. The new patch should fix it, though -- still waiting on
the confirmation.
The patch fixes my specific wild card case.
I use tar when I need to do that, in my locally-modified gbs's.
Something like this:
(cd theDocDirInSrcTree; tar cf aSubDir |\
tar -C ${instdir}${prefix}/share/doc/${PKG}-${VER} -xvf -)
repeat as needed, or use a filelist of some kind instead of aSubDir.
Hey, neat. This won't be needed if the filename is a wildcard, but if
it's just a directory name, this could be useful. I'm wondering whether
to require people to explicitly specify wildcards (which will make the
code clearer anyway), or to allow the use of directory names... IOW,
'aSubDir/*' vs. 'aSubDir'... I suppose if the tree at aSubDir is more
than one level deep...
In cyrus-sasl there was two cases I wanted, one where the copying of files
in a wildcard/specified fashion occurred in a way which the resultant
directory structure matched the source and the other where the resultant
directory structure was flattened. The current patch works for wildcards
aiming into a single target directory.
Regards,
Gareth Pearce
RE: Possible bug with generic build script.
On Fri, 15 Oct 2004, Gareth Pearce wrote:
On Wed, 13 Oct 2004, Charles Wilson wrote:
Igor Pechtchanski wrote:
You're right, it *is* broken. It was never intended to be used with
subdirectories, so I never tested it. I'll try to come up with a way
of accomodating subdirs shortly.
In fact, it shouldn't've worked with wildcards either, the way it was
written... Oops. The new patch should fix it, though -- still waiting on
the confirmation.
The patch fixes my specific wild card case.
Good to hear this. I've commited this change.
I use tar when I need to do that, in my locally-modified gbs's.
Something like this:
(cd theDocDirInSrcTree; tar cf aSubDir |\
tar -C ${instdir}${prefix}/share/doc/${PKG}-${VER} -xvf -)
repeat as needed, or use a filelist of some kind instead of aSubDir.
Hey, neat. This won't be needed if the filename is a wildcard, but if
it's just a directory name, this could be useful. I'm wondering whether
to require people to explicitly specify wildcards (which will make the
code clearer anyway), or to allow the use of directory names... IOW,
'aSubDir/*' vs. 'aSubDir'... I suppose if the tree at aSubDir is more
than one level deep...
In cyrus-sasl there was two cases I wanted, one where the copying of files
in a wildcard/specified fashion occurred in a way which the resultant
directory structure matched the source and the other where the resultant
directory structure was flattened. The current patch works for wildcards
aiming into a single target directory.
Even simpler -- it works for wildcards aiming from a single target
directory to a single source directory, i.e., it won't magically flatten a
directory tree for you, you'll have to use find for that...
If you need to copy directory structures using the install_docs mechanism,
I suppose it could be done with something like the patch below -- give it
a shot. You will have to put a / after each directory that you want
copied as a tree. The flattening is a bit harder, but still doable.
HTH,
Igor
Index: generic-build-script
===
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.29
diff -u -p -r1.29 generic-build-script
--- generic-build-script14 Oct 2004 22:55:26 - 1.29
+++ generic-build-script14 Oct 2004 23:00:30 -
@@ -193,11 +193,14 @@ install() {
fi \
templist= \
for fp in ${install_docs} ; do \
-for f in ${srcdir}/$fp ; do \
- if [ -f $f ] ; then \
-templist=$templist $f; \
- fi ; \
-done ; \
+case $fp in \
+ */) templist=$templist `find $fp -type f` ;;
+ *) for f in ${srcdir}/$fp ; do \
+if [ -f $f ] ; then \
+ templist=$templist $f; \
+fi ; \
+ done ;; \
+esac ; \
done \
if [ ! x$templist = x ]; then \
/usr/bin/install -m 644 $templist \
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
RE: generic build script 'help' patch
Igor wrote: On Mon, 11 Oct 2004, Hannu E K Nevalainen wrote: Igor: I hacked around some, and ended up short of my intentions; in hope it helps some I've *EDITED down* my changes to the attached patch. Feel free to do with it whatever you like. (Non copyrighted material, cgf BEWARE! ;-) Ok, thanks, I'll take a look, but why did this move to the main list from cygwin-apps? I'm redirecting this back to cygwin-apps. Igor Bah! :-7 - The redirect was unintentional. The patch: Mostly make places for manual changes more obvious, and display a more informative message at failure. /Hannu E K Nevalainen, B.Sc. EE Microcomputer systems--72-- ** mailing list preference; please keep replies on list ** -- printf(LocalTime: UTC+%02d\n,(DST)? 2:1); -- --END OF MESSAGE--
RE: generic build script 'help' patch
There is one problem IMO; the script (with the patch) won't allow
displaying help unless there is a matching
generic-build.{tar,tar.bz,tar.gz} (or some such, you get the
picture I
hope) file in the same dir.
I thought about this, but decided it wasn't important for end-users.
For anyone who downloads and unpacks a Cygwin package source archive,
the upstream source tarball will be present in the same directory as the
build script.
The people this might help is Cygwin packagers. But I decided they
probably already have read the writeup on cygwin.com, so it wasn't very
important for them. But I guess there's no harm in making the help text
available even if there's no source archive.
Re: PATCH: generic-build-script: Make output of depend function unique
On Thu, 30 Sep 2004, Igor Pechtchanski wrote:
On Fri, 1 Oct 2004, Lapo Luchini wrote:
Dr. Volker Zell wrote:
(cd ${instdir} \
find ${instdir} -name *.exe -o -name *.dll | xargs cygcheck | \
sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | xargs -n1 cygpath -u \
- | xargs cygcheck -f | sed 's%^% %' ; \
+ | xargs cygcheck -f | sed 's%^% %' | uniq ; \
true )
}
Wouldn't the last uniq better be a sort -u instead?
Files are sorted after the first sed, that's true: but they get sorted
by file name, while in the following passage we extract package name
which contains those files: who assures us that the package list is
already sorted?
I guess this is true in most of the cases (where the package name is
the same as the file name), or is there an implied sort that I didn't
catch?
Lapo
Yeah, I was thinking the same thing. Technically, cygcheck -f *will*
sort the packages for all files specified on the command line, but just in
case xargs decides to split the file list across multiple command lines, a
sort -u would definitely be safer.
Igor
Ok, I've committed this with a sort -u instead of uniq. Thanks,
Volker.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
RE: generic build script 'help' patch
On Mon, 11 Oct 2004, Hannu E K Nevalainen wrote:
you wrote:
Feel free to improve the particulars of my help text. The main thing
is that I think some help text is needed.
Andrew.
There is one problem IMO; the script (with the patch) won't allow
displaying help unless there is a matching
generic-build.{tar,tar.bz,tar.gz} (or some such, you get the picture I
hope) file in the same dir.
Igor: I hacked around some, and ended up short of my intentions; in hope
it helps some I've *EDITED down* my changes to the attached patch.
Feel free to do with it whatever you like. (Non copyrighted material,
cgf BEWARE! ;-)
Ok, thanks, I'll take a look, but why did this move to the main list from
cygwin-apps? I'm redirecting this back to cygwin-apps.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
Re: Pending patches for generic build script
Whatever happened to the idea of getting rid of all the extraneous \
crap in gbs? Was the idea rejected, or forgotten?
--
Chuck
Charles Wilson wrote:
Igor Pechtchanski wrote:
false || true
As a bonus, this construct documents that this particular line can
return a false value.
I see. Well, this does look reasonably readable... Another problem with
set +e that I vaguely recall reading about is that it may not always be
propagated into functions... If you're willing to test this and make
sure
it always works properly, and if nobody else protests, I'll consider
patching the generic-build-script.
Yes, I've never liked the silly looking ' \' syntax in the gbs. If
propagation of 'set +e' into functions is a problem, then just have each
function re-do it...
mkdirs() {(
set +e
cd ${topdir}
rm -fr ${objdir} ${instdir} ${srcinstdir} || true
mkdir -p ${objdir}
mkdir -p ${instdir}
mkdir -p ${srcinstdir}
)}
Plus, if the shell is changed from #!/bin/sh to #!/bin/bash, then you
don't need the subshell -- because 'pushd' is available. (Yes, I know
you could do, even in sh, CWD=`pwd`; cd ${topdir} ; ; cd ${CWD}
but there's another reason...)
I've noticed lately that sometimes, when launching configure from an
environment where SHELL is /bin/sh (==ash), I get weird,
non-deterministic errors:
error: invalid feature name: shared
when --enable-shared IS a valid feature for the package; but the error
doesn't show up ALL the time. This issue is what's made me have to run
(portions) of the libtool test suite over and over before releasing it,
because many of the tests which fail will EVENTUALLY succeed. Or, I
just configure with bash as my shell...the problem never seems to appear
when using bash.
So, you could do:
#!/bin/bash
set +e
...
mkdirs() {
set +e
cd ${topdir}
rm -fr ${objdir} ${instdir} ${srcinstdir} || true
mkdir -p ${objdir}
mkdir -p ${instdir}
mkdir -p ${srcinstdir}
}
--
Chuck
generic build script 'help' patch
Here is a patch that adds some 'help' or 'usage' text to the generic
build script. This seems to me to be a useful thing for someone who has
downloaded and unpacked a package source archive; sees the package source,
patch, and build script; and wonders what to do next. As a guess, they try
running './package-ver.sh --help' or similar, and now instead of getting back
'Error: bad arguments', they get some description of the script's purpose and
available options, as well as a pointer to the build script discussion on
cygwin.com. I also find the usage summary useful as a reminder to myself of
what some of my available operations are, and exactly what 'all' does.
Feel free to improve the particulars of my help text. The main thing is that
I think some help text is needed.
Andrew.
--- generic-build-script.orig 2004-10-08 22:48:07.0 -0400
+++ generic-build-script 2004-10-10 23:58:23.0 -0400
@@ -30,6 +30,7 @@
fi
fi
+scriptname=`basename $0`
tscriptname=`basename $0 .sh`
export PKG=`echo $tscriptname | sed -e 's/\-[^\-]*\-[^\-]*$//'`
export VER=`echo $tscriptname | sed -e s/${PKG}\-// -e 's/\-[^\-]*$//'`
@@ -320,6 +321,47 @@
echo You need the gnupg package installed in order to check
signatures. ; \
fi
}
+usage() {
+ echo Build script for the Cygwin ${PKG} package.
+Adapted from the Cygwin generic-build-script; see
+http://cygwin.com/setup.html#srcpackage_contents for detailed usage
instructions.
+Usage: ${scriptname} operation...
+build operations:
+ all build source and binary packages
+ (same as: prep conf build check install strip pkg spkg)
+ buildrun 'make' on patched source
+ conf run ./configure
+ configurerun ./configure
+ checkrun test suite
+ make run 'make' on patched source
+ prep unpack and patch package source; run mkdirs
+ stripstrip built executables
+ test run test suite
+packaging operations:
+ firstbuild source package first time, from existing patched
+ source directory (same as: mkdirs spkg finish)
+ install install package into installation staging subdir
+ package build binary package
+ pkg build binary package
+ spkg build source package
+ src-package build source package
+information:
+ depend list packages on which the binary package depends
+ help display this message
+ list list files in the binary package
+ usagedisplay this message
+minor operations:
+ acceptpatch accept Cygwin source patch
+ checksig check package, patch, and script signatures
+ cleanrun 'make clean'
+ finish remove source directory
+ mkdirs create package staging directories
+ mkpatch create Cygwin source patch
+ reconf remove build staging dir and rerun ./configure
+
+}
+
+test -n $1 || set usage
while test -n $1 ; do
case $1 in
prep) prep ; STATUS=$? ;;
@@ -348,7 +390,10 @@
all) checksig prep conf build install \
strip pkg spkg finish ; \
STATUS=$? ;;
-*) echo Error: bad arguments ; exit 1 ;;
+help|-help|--help|usage) usage ; STATUS=$? ;;
+*) echo ${scriptname}: error: unknown argument \$1\ ;
+ echo ${scriptname}: run \${scriptname} help\ to get a usage
summary ;
+ exit 1 ;;
esac
( exit ${STATUS} ) || exit ${STATUS}
shift
RE: generic build script 'help' patch
Here is a patch that adds some 'help' or 'usage' text to the
generic build script. This seems to me to be a useful thing
for someone who has downloaded and unpacked a package source
archive; sees the package source, patch, and build script;
and wonders what to do next. As a guess, they try running
'./package-ver.sh --help' or similar, and now instead of getting back
'Error: bad arguments', they get some description of the
script's purpose and available options, as well as a pointer
to the build script discussion on cygwin.com. I also find
the usage summary useful as a reminder to myself of what some
of my available operations are, and exactly what 'all' does.
Feel free to improve the particulars of my help text. The
main thing is that I think some help text is needed.
Andrew.
Hear hear.
--
Gary R. Van Sickle
--- generic-build-script.orig 2004-10-08 22:48:07.0 -0400
+++ generic-build-script 2004-10-10 23:58:23.0 -0400
@@ -30,6 +30,7 @@
fi
fi
+scriptname=`basename $0`
tscriptname=`basename $0 .sh`
export PKG=`echo $tscriptname | sed -e
's/\-[^\-]*\-[^\-]*$//'` export VER=`echo $tscriptname | sed
-e s/${PKG}\-// -e 's/\-[^\-]*$//'` @@ -320,6 +321,47 @@
echo You need the gnupg package installed in order to
check signatures. ; \
fi
}
+usage() {
+ echo Build script for the Cygwin ${PKG} package.
+Adapted from the Cygwin generic-build-script; see
+http://cygwin.com/setup.html#srcpackage_contents for detailed usage
instructions.
+Usage: ${scriptname} operation...
+build operations:
+ all build source and binary packages
+ (same as: prep conf build check install strip
pkg spkg)
+ buildrun 'make' on patched source
+ conf run ./configure
+ configurerun ./configure
+ checkrun test suite
+ make run 'make' on patched source
+ prep unpack and patch package source; run mkdirs
+ stripstrip built executables
+ test run test suite
+packaging operations:
+ firstbuild source package first time, from
existing patched
+ source directory (same as: mkdirs spkg finish)
+ install install package into installation staging subdir
+ package build binary package
+ pkg build binary package
+ spkg build source package
+ src-package build source package
+information:
+ depend list packages on which the binary package depends
+ help display this message
+ list list files in the binary package
+ usagedisplay this message
+minor operations:
+ acceptpatch accept Cygwin source patch
+ checksig check package, patch, and script signatures
+ cleanrun 'make clean'
+ finish remove source directory
+ mkdirs create package staging directories
+ mkpatch create Cygwin source patch
+ reconf remove build staging dir and rerun ./configure
+
+}
+
+test -n $1 || set usage
while test -n $1 ; do
case $1 in
prep) prep ; STATUS=$? ;;
@@ -348,7 +390,10 @@
all) checksig prep conf build install \
strip pkg spkg finish ; \
STATUS=$? ;;
-*) echo Error: bad arguments ; exit 1 ;;
+help|-help|--help|usage) usage ; STATUS=$? ;;
+*) echo ${scriptname}: error: unknown argument \$1\ ;
+ echo ${scriptname}: run \${scriptname} help\ to get a usage
summary ;
+ exit 1 ;;
esac
( exit ${STATUS} ) || exit ${STATUS}
shift
PATCH: generic-build-script: Make output of depend function unique
Hi
2004-09-30 Dr. Volker Zell [EMAIL PROTECTED]
* generic-build-script: Make output of depend function unique
diff -u -p /usr/local/src/generic-build-script.orig /usr/local/src/generic-build-script
--- /usr/local/src/generic-build-script.orig2004-09-30 19:09:20.639184000 +0200
+++ /usr/local/src/generic-build-script 2004-09-30 19:09:20.989688000 +0200
@@ -243,7 +243,7 @@ depend() {
(cd ${instdir} \
find ${instdir} -name *.exe -o -name *.dll | xargs cygcheck | \
sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | xargs -n1 cygpath -u \
- | xargs cygcheck -f | sed 's%^% %' ; \
+ | xargs cygcheck -f | sed 's%^% %' | uniq ; \
true )
}
pkg() {
Re: PATCH: generic-build-script: Make output of depend function unique
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dr. Volker Zell wrote:
(cd ${instdir} \
find ${instdir} -name *.exe -o -name *.dll | xargs cygcheck | \
sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | xargs -n1 cygpath -u \
- | xargs cygcheck -f | sed 's%^% %' ; \
+ | xargs cygcheck -f | sed 's%^% %' | uniq ; \
true )
}
Wouldn't the last uniq better be a sort -u instead?
Files are sorted after the first sed, that's true: but they get sorted
by file name, while in the following passage we extract package name
which contains those files: who assures us that the package list is
already sorted?
I guess this is true in most of the cases (where the package name is
the same as the file name), or is there an implied sort that I didn't
catch?
Lapo
- --
L a p o L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iEYEARECAAYFAkFchpEACgkQaJiCLMjyUvtoLgCeJoQGJoqYTffXVrdQ223U5HNn
pbIAoJcaSo9xQIGgzMFpCLq3emBMlWbJ
=C1F8
-END PGP SIGNATURE-
Re: PATCH: generic-build-script: Make output of depend function unique
On Fri, 1 Oct 2004, Lapo Luchini wrote:
Dr. Volker Zell wrote:
(cd ${instdir} \
find ${instdir} -name *.exe -o -name *.dll | xargs cygcheck | \
sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | xargs -n1 cygpath -u \
- | xargs cygcheck -f | sed 's%^% %' ; \
+ | xargs cygcheck -f | sed 's%^% %' | uniq ; \
true )
}
Wouldn't the last uniq better be a sort -u instead?
Files are sorted after the first sed, that's true: but they get sorted
by file name, while in the following passage we extract package name
which contains those files: who assures us that the package list is
already sorted?
I guess this is true in most of the cases (where the package name is
the same as the file name), or is there an implied sort that I didn't
catch?
Lapo
Yeah, I was thinking the same thing. Technically, cygcheck -f *will*
sort the packages for all files specified on the command line, but just in
case xargs decides to split the file list across multiple command lines, a
sort -u would definitely be safer.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
Re: Generic build script instructions
Op Sun, 20 Jun 2004 10:38:57 -0400 (EDT) schreef Igor Pechtchanski
in [EMAIL PROTECTED]:
: On Sun, 20 Jun 2004, Bas van Gompel wrote:
[...]
: ChangeLog entry:
:
: 2004-06-20 Bas van Gompel [EMAIL PROTECTED]
:
: * templates/generic-build-script (acceptpatch): New function to copy
: a fresh patch from ${srcinstdir} to ${topdir}.
:
: Looks good. Any objections from people to me checking this in?
Don't you think you waited long enough for objections?
L8r,
Buzz.
--
) | | ---/ ---/ 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
Re: Generic build script instructions
On Thu, 23 Sep 2004, Bas van Gompel wrote:
Op Sun, 20 Jun 2004 10:38:57 -0400 (EDT) schreef Igor Pechtchanski:
: On Sun, 20 Jun 2004, Bas van Gompel wrote:
[...]
: ChangeLog entry:
:
: 2004-06-20 Bas van Gompel g-b-s-patch.buzzatbavag.tmfweb.nl
:
: * templates/generic-build-script (acceptpatch): New function to copy
: a fresh patch from ${srcinstdir} to ${topdir}.
:
: Looks good. Any objections from people to me checking this in?
Don't you think you waited long enough for objections?
Umm, yes, quite. Applied with an added note that this is maintainer-only
functionality. Thanks.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
Re: Patch for generic-build-script
On Thu, Aug 12, 2004 at 11:41:03PM -0400, Robb, Sam wrote: It was actually right there on the xargs man page... ;-) Ok, so it's settled -- I'll change your patch to do that instead of the -exec option. Just curious - is there a reason to prefer xargs vs. -exec? I know that xargs can be used to avoid shell command line length limits, but are there other advantages? Speed -- xargs minimizes the number of fork/exec calls. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Re: Patch for generic-build-script
On Fri, 13 Aug 2004, Gerrit P. Haase wrote:
Hello Igor,
On 12. August 2004, Igor wrote:
On Thu, 12 Aug 2004, Robb, Sam wrote:
[...]
- When compressing info files as part of an install, uses the
-exec option of find rather than xargs.
Packages that already compress info files on install will create
an info dir, but there will not be any *.info files under that
directory. Find fails, and xargs attempts to call gzip without
any input. As a result, you get the error:
gzip: compressed data not written to a terminal. Use -f to force compression.
For help, type: gzip -h
... and the install fails. Using the -exec option of find ensures
that gzip is only executed when an info file is found.
Good catch. I'd rather add the '-r' ('--no-run-if-empty') flag to the
all of the xargs invocations, though.
We already discussed this and IIRC the best option would be to use
`-type f` instead of `-name *.info` for the find options.
Yes, but passing -r to xargs is orthogonal to this issue, and is generally
a good idea. In fact, I should actually go through all of the xargs
invocations and add -r to all of them... I'll do it in a bit.
- When compressing files using gzip as part of an install, adds
the -f flag to the gzip arguments to force compression.
-Samrobb
Why? Is it just to force compression of files that wouldn't benefit from
it? Frankly, I'm not clear on why this is useful...
OTOH it is annoying that the script produces an error if there are
already compressed files and there is nothing to do.
Hmm, true. But maybe ignoring the gzip error code is a better way to get
the script to continue? Alternatively, something like
find ${instdir}${prefix}/share/info -type f -name *.info* \
\( -exec test -e {}.gz \; -o -print \) | xargs -r gzip -q ; \
could also work (even though it'll do multiple invocations of test).
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
Patch for generic-build-script
Attached is a suggested patch for the generic-builf-script. I'm
not as familiar with xargs as I should be, so there may be better
ways of implementing some of these changes...
Areas it affects:
- Adds a couple of names to the list of files to be considered
documentation (COPYRIGHT, CHANGELOG, RELEASE_NOTES)
- When compressing info files as part of an install, uses the
-exec option of find rather than xargs.
Packages that already compress info files on install will create
an info dir, but there will not be any *.info files under that
directory. Find fails, and xargs attempts to call gzip without
any input. As a result, you get the error:
gzip: compressed data not written to a terminal. Use -f to force compression.
For help, type: gzip -h
... and the install fails. Using the -exec option of find ensures
that gzip is only executed when an info file is found.
- When compressing files using gzip as part of an install, adds
the -f flag to the gzip arguments to force compression.
-Samrobb
--- generic-build-script.orig 2004-08-12 12:46:42.923790400 -0400
+++ generic-build-script2004-08-12 12:46:42.733516800 -0400
@@ -1,4 +1,4 @@
-#!/bin/sh
+b#!/in/sh
#
# Generic package build script
#
@@ -92,7 +92,9 @@
CHANGES \
CONTRIBUTORS \
COPYING \
+ COPYRIGHT \
CREDITS \
+ CHANGELOG \
ChangeLog* \
FAQ \
HOW-TO-CONTRIBUTE \
@@ -104,6 +106,7 @@
NOTES \
PROGLIST \
README \
+ RELEASE_NOTES \
THANKS \
TODO \
@@ -181,12 +184,12 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name *.info -exec gzip -f -q '{}' \; ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
-name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
- -name *.7 -o -name *.8 | xargs gzip -q ; \
+ -name *.7 -o -name *.8 | xargs gzip -f -q ; \
fi \
templist= \
for f in ${install_docs} ; do \
Re: Patch for generic-build-script
On Thu, 12 Aug 2004, Robb, Sam wrote:
Attached is a suggested patch for the generic-builf-script. I'm
not as familiar with xargs as I should be, so there may be better
ways of implementing some of these changes...
Thanks for the patch. Some comments below.
Areas it affects:
- Adds a couple of names to the list of files to be considered
documentation (COPYRIGHT, CHANGELOG, RELEASE_NOTES)
Ok.
- When compressing info files as part of an install, uses the
-exec option of find rather than xargs.
Packages that already compress info files on install will create
an info dir, but there will not be any *.info files under that
directory. Find fails, and xargs attempts to call gzip without
any input. As a result, you get the error:
gzip: compressed data not written to a terminal. Use -f to force compression.
For help, type: gzip -h
... and the install fails. Using the -exec option of find ensures
that gzip is only executed when an info file is found.
Good catch. I'd rather add the '-r' ('--no-run-if-empty') flag to the
all of the xargs invocations, though.
- When compressing files using gzip as part of an install, adds
the -f flag to the gzip arguments to force compression.
-Samrobb
Why? Is it just to force compression of files that wouldn't benefit from
it? Frankly, I'm not clear on why this is useful...
--- generic-build-script.orig 2004-08-12 12:46:42.923790400 -0400
+++ generic-build-script 2004-08-12 12:46:42.733516800 -0400
@@ -1,4 +1,4 @@
-#!/bin/sh
+b#!/in/sh
This doesn't look very promising, either... ];-
I'll commit a modified version of the patch for now, and wait for the
explanation on the -f flag to gzip.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
RE: Patch for generic-build-script
Good catch. I'd rather add the '-r' ('--no-run-if-empty') flag to the
all of the xargs invocations, though.
Told you I wasn't familiar with xargs :-) I really need to spend some
time and get more comfortable with it.
- When compressing files using gzip as part of an install, adds
the -f flag to the gzip arguments to force compression.
-Samrobb
Why? Is it just to force compression of files that wouldn't
benefit from
it? Frankly, I'm not clear on why this is useful...
I ran into this becuase gzip was complining that a file had too
many links to compress. It also forces compression when the
resulting output file already exists. I was running into the
first problem - e2fsprogs installs some man pages, then creates
hard link to some of the man pages under a different name.
I'll be honest in that I'm not positive this is the right thing
to do in these situations (). If I understnad things correctly,
the warning is there to let you know that you're breaking a hard
link; but I'm not sure that's really an issue, aside from creating
a slightly larger binary package.
-Samrobb
RE: Patch for generic-build-script
On Thu, 12 Aug 2004, Robb, Sam wrote:
Good catch. I'd rather add the '-r' ('--no-run-if-empty') flag to the
all of the xargs invocations, though.
Told you I wasn't familiar with xargs :-) I really need to spend some
time and get more comfortable with it.
It was actually right there on the xargs man page... ;-) Ok, so it's
settled -- I'll change your patch to do that instead of the -exec option.
- When compressing files using gzip as part of an install, adds
the -f flag to the gzip arguments to force compression.
-Samrobb
Why? Is it just to force compression of files that wouldn't benefit
from it? Frankly, I'm not clear on why this is useful...
I ran into this becuase gzip was complining that a file had too
many links to compress. It also forces compression when the
resulting output file already exists. I was running into the
first problem - e2fsprogs installs some man pages, then creates
hard link to some of the man pages under a different name.
Ah, I see now.
I'll be honest in that I'm not positive this is the right thing
to do in these situations ().
Yeah, I'm also not sure that the sledgehammer approach of gzip -f is
appropriate here... In other words, the complaint *is* legitimate in both
cases -- you really don't want to compress something if it's already been
compressed by the upstream build, and breaking upstream hard links may not
be a good idea.
If I understnad things correctly, the warning is there to let you know
that you're breaking a hard link; but I'm not sure that's really an
issue, aside from creating a slightly larger binary package.
Well, the thing about the generic build script is that it's really a
template, and you can change it locally to correspond to your particular
package. Only changes that are generic enough or are harmless (i.e.,
won't break other builds) should go into the common script. I'm not
convinced that this particular change (i.e., adding -f to gzip) is
generally harmless... If you still want to do this for your package,
though, please feel free.
I'll apply the rest of the patch now.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing. -- Dr. Jubal Harshaw
RE: Patch for generic-build-script
It was actually right there on the xargs man page... ;-) Ok, so it's settled -- I'll change your patch to do that instead of the -exec option. Just curious - is there a reason to prefer xargs vs. -exec? I know that xargs can be used to avoid shell command line length limits, but are there other advantages? Only changes that are generic enough or are harmless (i.e., won't break other builds) should go into the common script. I'm not convinced that this particular change (i.e., adding -f to gzip) is generally harmless... If you still want to do this for your package, though, please feel free. Understood. I'll go back and take a closer look at what's going on, just to be sure I understand what's happening. BTW - once I understood how the gbs is intended to work, it was really helpful. I'm planning on using it for a couple of other packages as well. Thanks for making my life a whole lot easier :-) -Samrobb
Re: Patch for generic-build-script
Hello Igor,
On 12. August 2004, Igor wrote:
On Thu, 12 Aug 2004, Robb, Sam wrote:
[...]
- When compressing info files as part of an install, uses the
-exec option of find rather than xargs.
Packages that already compress info files on install will create
an info dir, but there will not be any *.info files under that
directory. Find fails, and xargs attempts to call gzip without
any input. As a result, you get the error:
gzip: compressed data not written to a terminal. Use -f to force compression.
For help, type: gzip -h
... and the install fails. Using the -exec option of find ensures
that gzip is only executed when an info file is found.
Good catch. I'd rather add the '-r' ('--no-run-if-empty') flag to the
all of the xargs invocations, though.
We already discussed this and IIRC the best option would be to use
`-type f` instead of `-name *.info` for the find options.
- When compressing files using gzip as part of an install, adds
the -f flag to the gzip arguments to force compression.
-Samrobb
Why? Is it just to force compression of files that wouldn't benefit from
it? Frankly, I'm not clear on why this is useful...
OTOH it is annoying that the script produces an error if there are
already compressed files and there is nothing to do.
Gerrit
--
=^..^=
Re: Typo in generic-build-script
On Thu, 15 Jul 2004, Harold L Hunt II wrote: There is the following in the gbs: if [ -z $MY_CFLAGS ]; then MY_CFLAGS=-O2 fi if [ -z $MY_CFLAGS ]; then MY_LDFLAGS= fi It appears that the second if should be testing '$MY_LDFLAGS', not '$MY_CFLAGS'. Harold Thanks, Harold. Fixed. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Typo in generic-build-script
There is the following in the gbs: if [ -z $MY_CFLAGS ]; then MY_CFLAGS=-O2 fi if [ -z $MY_CFLAGS ]; then MY_LDFLAGS= fi It appears that the second if should be testing '$MY_LDFLAGS', not '$MY_CFLAGS'. Harold
Re: Generic build script instructions
Op Sun, 20 Jun 2004 10:38:57 -0400 (EDT) schreef Igor Pechtchanski in [EMAIL PROTECTED]: : On Sun, 20 Jun 2004, Bas van Gompel wrote: : : Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski: [submitting locally maintained packages?] : : Oh. Well, if nothing else, it's a valuable experience for you... : : What is? Are you suggesting I ITP s-lang? : : It = keeping a local copy. I'm very much against pressuring anyone into : ITP'ing anything... :-) Ok, I'll consider it. ;-p : [ispatch is not the best name] [accept ``acceptpatch'' patch] : Looks good. Any objections from people to me checking this in? Well? (Huff huff.) [...] L8r, Buzz. -- ) | | ---/ ---/ 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
Re: Generic build script instructions
Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski
in [EMAIL PROTECTED]:
: On Sat, 19 Jun 2004, Bas van Gompel wrote:
:
: Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski:
...Snipped some stuff that was going OT, enjoyable though it was...
[reason for not submitting packages?]
: One, (s-lang) is rather complex and I expect I could not really
: support it. It also builds OOTB (sort of). (I'll consider votes an
: incentive to start cleaning up my patches :- ). The other is just
: waiting for the announced maintainer to publish his work. (core-utils)
:
: Oh. Well, if nothing else, it's a valuable experience for you...
What is? Are you suggesting I ITP s-lang?
[why not 2 patches]
: is moot.
Right. ;)
[ispatch is not the best name]
[savepatch, ``acceptpatch'')
:
: As I said, these were suggestions. acceptpatch sounds fine to me.
: Unless anyone objects, we can go with that.
I'm attaching the patch.
ChangeLog entry:
2004-06-20 Bas van Gompel [EMAIL PROTECTED]
* templates/generic-build-script (acceptpatch): New function to copy
a fresh patch from ${srcinstdir} to ${topdir}.
[autodetect testsuite rule]
: Found it. it uses ``-f Makefile -f -'' to get the value of
: a Makefile-variable, and is of no use to us here. ``make -n''
: is probably the WTG.
:
: Okay, we'll see what can be done.
Yes, we will. :)
: [snip]
[Igor: append a (wrapped) GBS patch to the GBS]
[Buzz: store gbs, before mods to CYGWIN-PATCHES]
[Igor: gbs patching self in place]
[Buzz: confused]
: Umm, on reviewing it in light of morning (it was late night when I wrote
: the above yesterday), it does look nonsensical. I probably meant
: something like
:
: (echo --- generic-build-script
: +++ $0; cat END-OF-PATCH
: @@ -1,100 +1,100 @@
: - patch goes here
: + patch goes here
: END-OF-PATCH
: ) | patch -o tmp.$$.sh exec tmp.$$.sh
:
: instead. This certainly makes more sense...
I still wonder why you'd would want to do this. If you must have the
``state'' stored in the same file, why not store the diff in a copy
of the _modified_ gbs, not the original. You would then not have to
patch the script for every run. (You'd _still_ have to jump through
several burning hoops to edit the resulting build-script, while
keeping the diff current, though.)
: : Hope this clears up the confusion,
:
: I think storing the diff in CYGWIN-PATCHES (and having it automatically
: be included in foo-x.y-z.patch) is cleanest/clearest.
I'm not sure about this anymore. Probably storing the orig gbs /is/
easier/less error-prone.
: This, IMO, creates a chicken-and-egg problem, as the patched directory
: won't be available until the script is run...
Not really. Just keep a copy of the unedited gbs in topdir until you
round off your changes and get ready to do a ``spkg''. At that time
store the diff (or gbs-orig) into C-P. (Just remember to recreate the
original gbs before later editing the modified one, if storing the
diff.)
:Also, foo-x.y-z.patch
: usually stores the diff between the original source and the Cygwin package
: source, and the original won't have contained the unpatched gbs...
The original source won't have contained a generic-readme either...
There is a reason the directory is called CYGWIN-PATCHES, isn't there?
L8r,
Index: packaging/templates/generic-build-script
===
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.24
diff -u -p -r1.24 generic-build-script
--- packaging/templates/generic-build-script19 Jun 2004 19:23:09 - 1.24
+++ packaging/templates/generic-build-script20 Jun 2004 02:26:30 -
@@ -258,6 +258,9 @@ mkpatch() {
${srcinstdir}/${src_patch_name} ; \
rm -rf ${BASEPKG}-orig )
}
+acceptpatch() {
+ cp --backup=numbered ${srcinstdir}/${src_patch_name} ${topdir}
+}
spkg() {
(mkpatch \
if [ ${SIG} -eq 1 ] ; then \
@@ -332,6 +335,7 @@ while test -n $1 ; do
package) pkg ; STATUS=$? ;;
pkg) pkg ; STATUS=$? ;;
mkpatch) mkpatch ; STATUS=$? ;;
+acceptpatch) acceptpatch ; STATUS=$? ;;
src-package) spkg ; STATUS=$? ;;
spkg) spkg ; STATUS=$? ;;
finish)finish ; STATUS=$? ;;
Buzz.
--
) | | ---/ ---/ Yes, this | This message consists of true | I do not
-- | | // really is | and false bits entirely.| post for
) | | //a 72 by 4 +---+ any1 but
-- \--| /--- /--- .sigfile. | |perl -pe s.u(z)\1.as.| me. 4^re
Re: Generic build script instructions
Op Sat, 19 Jun 2004 15:24:06 -0400 (EDT) schreef Igor Pechtchanski in [EMAIL PROTECTED]: : On Sat, 19 Jun 2004, Bas van Gompel wrote: [...] : * templates/generic-build-script: Allow multiple arguments. : Committed, thanks. SHTDI, KUTGW, Buzz. -- ) | | ---/ ---/ 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
Re: Generic build script instructions
Op Sun, 20 Jun 2004 08:00:03 +0200 (MET DST) schreef ik in [EMAIL PROTECTED]: [...] : Not really. Just keep a copy of the unedited gbs in topdir until you : round off your changes and get ready to do a ``spkg''. At that time : store the diff (or gbs-orig) into C-P. (Just remember to recreate the : original gbs before later editing the modified one, if storing the : diff.) s/spkg/mkpatch/ above. In fact anytime after ``prep'' will do. L8r, Buzz. -- ) | | ---/ ---/ 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
Re: Generic build script instructions
On Sun, 20 Jun 2004, Bas van Gompel wrote:
Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski:
: On Sat, 19 Jun 2004, Bas van Gompel wrote:
:
: Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski:
[reason for not submitting packages?]
: One, (s-lang) is rather complex and I expect I could not really
: support it. It also builds OOTB (sort of). (I'll consider votes an
: incentive to start cleaning up my patches :- ). The other is just
: waiting for the announced maintainer to publish his work. (core-utils)
:
: Oh. Well, if nothing else, it's a valuable experience for you...
What is? Are you suggesting I ITP s-lang?
It = keeping a local copy. I'm very much against pressuring anyone into
ITP'ing anything... :-)
[ispatch is not the best name]
[savepatch, ``acceptpatch'')
:
: As I said, these were suggestions. acceptpatch sounds fine to me.
: Unless anyone objects, we can go with that.
I'm attaching the patch.
ChangeLog entry:
2004-06-20 Bas van Gompel [EMAIL PROTECTED]
* templates/generic-build-script (acceptpatch): New function to copy
a fresh patch from ${srcinstdir} to ${topdir}.
Looks good. Any objections from people to me checking this in?
[Igor: append a (wrapped) GBS patch to the GBS]
[Buzz: store gbs, before mods to CYGWIN-PATCHES]
[Igor: gbs patching self in place]
[Buzz: confused]
: Umm, on reviewing it in light of morning (it was late night when I wrote
: the above yesterday), it does look nonsensical. I probably meant
: something like
:
: (echo --- generic-build-script
: +++ $0; cat END-OF-PATCH
: @@ -1,100 +1,100 @@
: - patch goes here
: + patch goes here
: END-OF-PATCH
: ) | patch -o tmp.$$.sh exec tmp.$$.sh
:
: instead. This certainly makes more sense...
I still wonder why you'd would want to do this. If you must have the
``state'' stored in the same file, why not store the diff in a copy
of the _modified_ gbs, not the original. You would then not have to
patch the script for every run. (You'd _still_ have to jump through
several burning hoops to edit the resulting build-script, while
keeping the diff current, though.)
The rationale for doing it the way I suggested is that forward-porting the
changes will usually involve simply copying the patch part into the new
gbs version, where it might apply with some fuzz. However, this will not
always work, and will only postpone the inevitable... Come to think of
it, it might just be easier to do an equivalent of cvs diff -rBASE
-rHEAD, and apply that (after suitable modification) to the package build
script. Oh, well...
: : Hope this clears up the confusion,
:
: I think storing the diff in CYGWIN-PATCHES (and having it automatically
: be included in foo-x.y-z.patch) is cleanest/clearest.
I'm not sure about this anymore. Probably storing the orig gbs /is/
easier/less error-prone.
: This, IMO, creates a chicken-and-egg problem, as the patched directory
: won't be available until the script is run...
Not really. Just keep a copy of the unedited gbs in topdir until you
round off your changes and get ready to do a ``spkg''. At that time
store the diff (or gbs-orig) into C-P. (Just remember to recreate the
original gbs before later editing the modified one, if storing the
diff.)
:Also, foo-x.y-z.patch
: usually stores the diff between the original source and the Cygwin package
: source, and the original won't have contained the unpatched gbs...
The original source won't have contained a generic-readme either...
There is a reason the directory is called CYGWIN-PATCHES, isn't there?
Yep, you got a point. What I meant, however, is that since the original
will have contained neither the gbs nor the generic-readme, they will have
to be *added* to CYGWIN-PATCHES, which will make any package-specific
changes in them to not appear in the patch...
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: Generic build script instructions
Igor Pechtchanski schrieb:
On Sat, 19 Jun 2004, Bas van Gompel wrote:
: 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.
:
: I'm not clear on what the second part does. Could you please elaborate on
: the purpose of ispatch()?
Ok. Let me try to make this clear...
You install the upstream package and a new gbs. you do a
``./boffo-x.y-1.sh prep'', cd into boffo-x.y and edit some files.
You now do a ``./boffo-x.y-1.sh conf build'' and discover the
build succeeds. A ``./boffo-x.y-1.sh check'' reveals it passes it's
testsuite. You do a ``./boffo-x.y-1.sh clean mkpatch'' and
look at the generated patch. It looks OK. You can then do
`./boffo-x.y-1.sh ispatch'' to make sure you don't lose your
edits when you remove the boffo-x.y-directory (e.g. by doing
`./boffo-x.y-1.sh finish all'').
In other words: ``ispatch'' copies the patch generated by ``mkpatch''
from .sinst to ${topdir}, so it can be used now, not just get included
by ``spkg''.
I see. That's not quite the way I use the gbs (I never edit the patched
directory, but keep the original edited version separately). Perhaps
ispatch is not the best name for it? Looks like savepatch might be
better... As I never intend to use this feature, the above is just a
suggestion.
I'd also vastly prefer savepatch over ispatch. ispatch sounds
boolean, something to check.
(I'm coming from a lisp background, but we are not only bound to the
patchp notation :)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Re: Generic build script instructions
Op Fri, 18 Jun 2004 22:49:11 -0400 (EDT) schreef Igor Pechtchanski
in [EMAIL PROTECTED]:
[ask for two separate patches?]
: I think I'd prefer the multiple parameters patch first, with its own
: ChangeLog. That part looks good enough to check in, actually.
Attached.
ChangeLog entry:
2004-06-19 Bas van Gompel [EMAIL PROTECTED]
* templates/generic-build-script: Allow multiple arguments.
:As for the
: ispatch part, let's discuss the name and the possible functionality (you
: mentioned adding extra), and then it can be an add-on on top of the first
: patch. Frankly, I have reservations about the build script mucking with
: anything outside of the build directory...
See other mail. About the extras I'm not sure what you mean... the
backing up is already implemented (by using ``cp --backup=numbered'').
: Thanks for contributing,
: Igor
hth,
--
) | | ---/ ---/ 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
Index: packaging/templates/generic-build-script
===
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.22
diff -u -p -r1.22 generic-build-script
--- packaging/templates/generic-build-script31 Mar 2004 00:56:17 - 1.22
+++ packaging/templates/generic-build-script19 Jun 2004 00:32:57 -
@@ -312,33 +312,35 @@ checksig() {
echo You need the gnupg package installed in order to check signatures. ; \
fi
}
-case $1 in
- prep)prep ; STATUS=$? ;;
- mkdirs) mkdirs ; STATUS=$? ;;
- conf)conf ; STATUS=$? ;;
- configure) conf ; STATUS=$? ;;
- reconf) reconf ; STATUS=$? ;;
- build) build ; STATUS=$? ;;
- make)build ; STATUS=$? ;;
- check) check ; STATUS=$? ;;
- test)check ; STATUS=$? ;;
- clean) clean ; STATUS=$? ;;
- install) install ; STATUS=$? ;;
- list)list ; STATUS=$? ;;
- depend) depend ; STATUS=$? ;;
- strip) strip ; STATUS=$? ;;
- package) pkg ; STATUS=$? ;;
- pkg) pkg ; STATUS=$? ;;
- mkpatch) mkpatch ; STATUS=$? ;;
- src-package) spkg ; STATUS=$? ;;
- spkg)spkg ; STATUS=$? ;;
- finish) finish ; STATUS=$? ;;
- checksig)checksig ; STATUS=$? ;;
- first) mkdirs spkg finish ; STATUS=$? ;;
- all) checksig prep conf build install \
+while test -n $1 ; do
+ case $1 in
+prep) prep ; STATUS=$? ;;
+mkdirs)mkdirs ; STATUS=$? ;;
+conf) conf ; STATUS=$? ;;
+configure) conf ; STATUS=$? ;;
+reconf)reconf ; STATUS=$? ;;
+build) build ; STATUS=$? ;;
+make) build ; STATUS=$? ;;
+check) check ; STATUS=$? ;;
+test) check ; STATUS=$? ;;
+clean) clean ; STATUS=$? ;;
+install) install ; STATUS=$? ;;
+list) list ; STATUS=$? ;;
+depend)depend ; STATUS=$? ;;
+strip) strip ; STATUS=$? ;;
+package) pkg ; STATUS=$? ;;
+pkg) pkg ; STATUS=$? ;;
+mkpatch) mkpatch ; STATUS=$? ;;
+src-package) spkg ; STATUS=$? ;;
+spkg) spkg ; STATUS=$? ;;
+finish)finish ; STATUS=$? ;;
+checksig) checksig ; STATUS=$? ;;
+first) mkdirs spkg finish ; STATUS=$? ;;
+all) checksig prep conf build install \
strip pkg spkg finish ; \
STATUS=$? ;;
- *) echo Error: bad arguments ; exit 1 ;;
-esac
-exit ${STATUS}
-
+*) echo Error: bad arguments ; exit 1 ;;
+ esac
+ ( exit ${STATUS} ) || exit ${STATUS}
+ shift
+done
Re: Generic build script instructions
Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski
in [EMAIL PROTECTED]:
: On Sat, 19 Jun 2004, Bas van Gompel wrote:
:
: Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski:
: : On Fri, 18 Jun 2004, Bas van Gompel wrote:
[pechtcha at see es dot and why you dot ee dee you]
: : Cute, very cute...
: Ehh... Thanks, I think.
:
: Yeah, I just never saw this particular obfuscation before, is all. :-)
I did it by hand. (I know, I should get a job.)
[EMBI]
: Excuse My Butting In.
:
: Ok, this one's on its way to the OLOCA. :-D
g
[package maintainers]
: I keep some packages locally, following changes are in them...
:
: Then, as far as I'm concerned, you're a maintainer. Any particular reason
: for not submitting those packages, though? License issues, perhaps?
One, (s-lang) is rather complex and I expect I could not really
support it. It also builds OOTB (sort of). (I'll consider votes an
incentive to start cleaning up my patches :- ). The other is just
waiting for the announced maintainer to publish his work. (core-utils)
[...]
: The change in indentation makes the ``ispatch()'' call hard to spot,
: hence the (botched) copy.
:
: Why not submit two separate patches, then? ;-)
The change in indentation would still affect many lines which are not
functionally changed. (I would thus want to add a 3rd patch.)
[the purpose of ispatch()]
: In other words: ``ispatch'' copies the patch generated by ``mkpatch''
: from .sinst to ${topdir}, so it can be used now, not just get included
: by ``spkg''.
:
: I see. That's not quite the way I use the gbs (I never edit the patched
: directory, but keep the original edited version separately).
? I'm talking about when you first port the app, or when you are
changing to a new upstream version.
:Perhaps
: ispatch is not the best name for it?
Could be. You use it when you determine this _is_ the correct patch.
:Looks like savepatch might be
: better... As I never intend to use this feature, the above is just a
: suggestion.
I would expect that --``savepatch''-- to do st else (like store the
patch from ${topdir} someplace). But if you insist I'll change it to
that. I would prefer st different, though. (``acceptpatch'' maybe?)
: : : 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 think we could use something like make -n and check the return code...
: : But as I don't have the time to implement it properly now, I'll look at
: : whatever methods people choose to provide in their patches.
:
: It was something using a ``make -f -'' IIRC... (l8r)
:
: Hmm, make -f - will actually not be useful, FWICS. We want to check
: whether the Makefile contains either a test or a check rule, whereas
: make -f - will bypass the Makefile altogether. But if I'm wrong, it
: won't be the first time.
Found it. it uses ``-f Makefile -f -'' to get the value of
a Makefile-variable, and is of no use to us here. ``make -n''
is probably the WTG.
[patch-size vs. functionality]
: Oh, I see the confusion. I didn't mean the size of the patches that are
: incorporated into the gbs itself -- those can be arbitrarily large. I
: meant the size of the patches that the packagers have to maintain
: separately from the gbs, i.e., the things in the package build that don't
: fit into the gbs defaults. I think it's pretty obvious that *those*
: should be small.
slap target=face subject=self/
Now I get it. Ofcourse. You're correct.
: [append a (wrapped) GBS patch to the GBS]
[store gbs, before mods to CYGWIN-PATCHES]
: Oh. Well, again, I never store the build script into CYGWIN-PATCHES, but
: it doesn't mean that nobody else should... Everyone has his own methods.
I'm not saying anybody _should_, just that it will make upgrading the
specific-build-script easier.
: Or maybe just store the diff? One could then recreate the original gbs
: to merge against.
:
: That's more or less what I'm proposing. Take the (default) gbs, add a
: section to it that does something like
:
: (echo --- generic-build-script
: +++ $0; cat END-OF-PATCH
: @@ -1,100 +1,100 @@
: - patch goes here
: + patch goes here
: END-OF-PATCH
: ) | patch exec $0
:
: and let the maintainers put their patches between the cat and
: END-OF-PATCH. At least, that's what I had in mind. Then the set of
: changes to the gbs can be easily extracted (and moved) to the new version.
Let me get this straight. First you take a copy of gbs. you edit it.
You make a diff against the orig gbs. you paste that diff into yet
another copy of the gbs. you then run the last one, which will then
recreate the file you had before, by editing itself inplace
Re: Generic build script instructions
On Sat, 19 Jun 2004, Bas van Gompel wrote: Op Fri, 18 Jun 2004 22:49:11 -0400 (EDT) schreef Igor Pechtchanski: [ask for two separate patches?] : I think I'd prefer the multiple parameters patch first, with its own : ChangeLog. That part looks good enough to check in, actually. Attached. ChangeLog entry: 2004-06-19 Bas van Gompel [EMAIL PROTECTED] * templates/generic-build-script: Allow multiple arguments. Committed, thanks. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Generic build script instructions
On Sat, 19 Jun 2004, Bas van Gompel wrote:
Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski:
: On Sat, 19 Jun 2004, Bas van Gompel wrote:
:
: Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski:
: : On Fri, 18 Jun 2004, Bas van Gompel wrote:
[pechtcha at see es dot and why you dot ee dee you]
: : Cute, very cute...
: Ehh... Thanks, I think.
:
: Yeah, I just never saw this particular obfuscation before, is all. :-)
I did it by hand. (I know, I should get a job.)
...hey, it was funny... :-)
[EMBI]
: Excuse My Butting In.
:
: Ok, this one's on its way to the OLOCA. :-D
g
FWIW, it just got there.
[package maintainers]
: I keep some packages locally, following changes are in them...
:
: Then, as far as I'm concerned, you're a maintainer. Any particular reason
: for not submitting those packages, though? License issues, perhaps?
One, (s-lang) is rather complex and I expect I could not really
support it. It also builds OOTB (sort of). (I'll consider votes an
incentive to start cleaning up my patches :- ). The other is just
waiting for the announced maintainer to publish his work. (core-utils)
Oh. Well, if nothing else, it's a valuable experience for you...
[...]
: The change in indentation makes the ``ispatch()'' call hard to spot,
: hence the (botched) copy.
:
: Why not submit two separate patches, then? ;-)
The change in indentation would still affect many lines which are not
functionally changed. (I would thus want to add a 3rd patch.)
Umm, that's fine, you expect an indentation change when adding a while
loop. I just didn't want to have another independent change sneak in
there unnoticed. The multiple args patch has been committed, so the issue
is moot.
[the purpose of ispatch()]
: In other words: ``ispatch'' copies the patch generated by ``mkpatch''
: from .sinst to ${topdir}, so it can be used now, not just get included
: by ``spkg''.
:
: I see. That's not quite the way I use the gbs (I never edit the patched
: directory, but keep the original edited version separately).
? I'm talking about when you first port the app, or when you are
changing to a new upstream version.
:Perhaps
: ispatch is not the best name for it?
Could be. You use it when you determine this _is_ the correct patch.
:Looks like savepatch might be
: better... As I never intend to use this feature, the above is just a
: suggestion.
I would expect that --``savepatch''-- to do st else (like store the
patch from ${topdir} someplace). But if you insist I'll change it to
that. I would prefer st different, though. (``acceptpatch'' maybe?)
As I said, these were suggestions. acceptpatch sounds fine to me.
Unless anyone objects, we can go with that.
: : : 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 think we could use something like make -n and check the return code...
: : But as I don't have the time to implement it properly now, I'll look at
: : whatever methods people choose to provide in their patches.
:
: It was something using a ``make -f -'' IIRC... (l8r)
:
: Hmm, make -f - will actually not be useful, FWICS. We want to check
: whether the Makefile contains either a test or a check rule, whereas
: make -f - will bypass the Makefile altogether. But if I'm wrong, it
: won't be the first time.
Found it. it uses ``-f Makefile -f -'' to get the value of
a Makefile-variable, and is of no use to us here. ``make -n''
is probably the WTG.
Okay, we'll see what can be done.
[snip]
: [append a (wrapped) GBS patch to the GBS]
[store gbs, before mods to CYGWIN-PATCHES]
: Oh. Well, again, I never store the build script into CYGWIN-PATCHES, but
: it doesn't mean that nobody else should... Everyone has his own methods.
I'm not saying anybody _should_, just that it will make upgrading the
specific-build-script easier.
: Or maybe just store the diff? One could then recreate the original gbs
: to merge against.
:
: That's more or less what I'm proposing. Take the (default) gbs, add a
: section to it that does something like
:
: (echo --- generic-build-script
: +++ $0; cat END-OF-PATCH
: @@ -1,100 +1,100 @@
: - patch goes here
: + patch goes here
: END-OF-PATCH
: ) | patch exec $0
:
: and let the maintainers put their patches between the cat and
: END-OF-PATCH. At least, that's what I had in mind. Then the set of
: changes to the gbs can be easily extracted (and moved) to the new version.
Let me get this straight. First you take a copy of gbs. you edit it.
You make a diff against the orig gbs. you paste that diff into yet
Re: Generic build script instructions
On Fri, 18 Jun 2004, Bas van Gompel wrote: 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: Cute, very cute... : 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-appsonly_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. I'm not familiar with the acronym. What I meant by package maintainers take time to adapt the CVS head of the GBS was that most packages now use an older version of the GBS, and don't keep the CVS Id, so that makes it very hard to determine the exact set of changes that everyone had to make. This doesn't mean that I won't be considering patches from non-maintainers. 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.) FWIW, I can review attached patches just as easily as the inline ones -- no need to duplicate the information. 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. I'm not clear on what the second part does. Could you please elaborate on the purpose of ispatch()? : 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 think we could use something like make -n and check the return code... But as I don't have the time to implement it properly now, I'll look at whatever methods people choose to provide in their patches. : 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) Well, not quite. The main objective, as far as I understood Chuck Wilson's comments, was to be able to get a *new* package off the ground fast. The GBS embodies several of the policies (e.g., the FHS, the default configure arguments, the tarball filenames) which would otherwise need to be taken care of. The more packages can be built with a minimal (preferably empty) set of changes, the better. Understandability is certainly an issue. Judging the needed effort, however, is very subjective, so I'd prefer using the size of the necessary patch to quantify it. : 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). Huh? No, the GBS just gets edited -- I don't think it should go into CYGWIN-PATCHES... [snip] BTW: 2004-02-18 Yaakov Selkowitz yselk... Thanks, fixed. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Generic build script instructions
Bas,
Oh, and one more comment:
On Fri, 18 Jun 2004, Bas van Gompel wrote:
[snip]
@@ -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
Do we really need a subshell here? Isn't an if test enough (and more
efficient)?
Igor
P.S. I'm wondering whether I should ask for two separate patches, as they
are independent and it's a bit hard to see the addition of ispatch()
with the indentation adjustment...
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: Generic build script instructions
Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski in
[EMAIL PROTECTED]:
: On Fri, 18 Jun 2004, Bas van Gompel wrote:
:
: 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:
:
: Cute, very cute...
Ehh... Thanks, I think.
[...package maintainers could take...adapt the CVS HEAD of the GBS...]
: I am not a package maintainer, so EMBI.
:
: I'm not familiar with the acronym.
Excuse My Butting In.
: What I meant by package maintainers
: take time to adapt the CVS head of the GBS was that most packages now use
: an older version of the GBS, and don't keep the CVS Id, so that makes it
: very hard to determine the exact set of changes that everyone had to make.
I keep some packages locally, following changes are in them...
: This doesn't mean that I won't be considering patches from
: non-maintainers.
Pfew!
: 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.)
:
: FWIW, I can review attached patches just as easily as the inline ones --
: no need to duplicate the information.
The change in indentation makes the ``ispatch()'' call hard to spot,
hence the (botched) copy.
: 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.
:
: I'm not clear on what the second part does. Could you please elaborate on
: the purpose of ispatch()?
Ok. Let me try to make this clear...
You install the upstream package and a new gbs. you do a
``./boffo-x.y-1.sh prep'', cd into boffo-x.y and edit some files.
You now do a ``./boffo-x.y-1.sh conf build'' and discover the
build succeeds. A ``./boffo-x.y-1.sh check'' reveals it passes it's
testsuite. You do a ``./boffo-x.y-1.sh clean mkpatch'' and
look at the generated patch. It looks OK. You can then do
`./boffo-x.y-1.sh ispatch'' to make sure you don't lose your
edits when you remove the boffo-x.y-directory (e.g. by doing
`./boffo-x.y-1.sh finish all'').
In other words: ``ispatch'' copies the patch generated by ``mkpatch''
from .sinst to ${topdir}, so it can be used now, not just get included
by ``spkg''.
: : 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 think we could use something like make -n and check the return code...
: But as I don't have the time to implement it properly now, I'll look at
: whatever methods people choose to provide in their patches.
It was something using a ``make -f -'' IIRC... (l8r)
: : 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)
:
: Well, not quite. The main objective, as far as I understood Chuck
: Wilson's comments, was to be able to get a *new* package off the ground
: fast. The GBS embodies several of the policies (e.g., the FHS, the
: default configure arguments, the tarball filenames) which would otherwise
: need to be taken care of. The more packages can be built with a minimal
: (preferably empty) set of changes, the better. Understandability is
: certainly an issue. Judging the needed effort, however, is very
: subjective, so I'd prefer using the size of the necessary patch to
: quantify it.
Fair enough. Ny point was: Allowing multiple arguments, or auto-
detecting various aspects, makes the patches bigger, but the gbs
more useful.
[append a (wrapped) GBS patch to the GBS]
: 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).
:
: Huh? No, the GBS just gets edited -- I don't think it should go into
: CYGWIN-PATCHES...
It improves maintainability e.g.
``diff -u boffo-x.y/CYGWIN-PATCHES/gbs-orig boffo-x.y-1.sh''
and
``merge boffo-x.y-1.sh boffo-x.y/CYGWIN-PATCHES/gbs-orig
Re: Generic build script instructions
Op Fri, 18 Jun 2004 09:04:42 -0400 (EDT) schreef Igor Pechtchanski
in [EMAIL PROTECTED]:
[...]
: + ( exit ${STATUS} ) || exit ${STATUS}
: ^^
: + shift
: +done
:
: Do we really need a subshell here? Isn't an if test enough (and more
: efficient)?
Some thoughts. I did not do any testing on this.
*) ``if test ${STATUS} -ne 0 ; then exit ${STATUS} fi'' does fork
a ``test'', doesn't it?
*) ISTR ``autoconf'' generated ``configure''-s use a similar method.
*) Most of the gbs-functions use a subshell ``(cd ${srcdir}...'';
*) Relative to a configure, make or check this overhead should be
neglible.
: P.S. I'm wondering whether I should ask for two separate patches, as they
: are independent and it's a bit hard to see the addition of ispatch()
: with the indentation adjustment...
Hence the ``diff -b'' copy of the patch... If you decide I need to split
this up, please let me know if you prefer any order of the patches, or
should they be independant (from a common ancestor, for you to merge).
l8r,
Buzz.
--
) | | ---/ ---/ 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
Re: Generic build script instructions
Op Mon, 14 Jun 2004 23:58:25 -0400 schreef Robb, Sam
in [EMAIL PROTECTED]:
[Instructions for using the generic build script]
:Right now, it looks like it's something like:
:
:1) Get source tarball (ex, foo-0.1.tar.gz)
:2) Rename GBS as appropriate (ex, foo-0.1-1.sh)
: (hereafter refered to as gbs for brevity)
(I think that's a bad idea, as this is getting archived and may well
get quoted out of context... (no offense, I hope.))
:3) Use gbs to set up work area (./gbs prep)
:4) Configure (./gbs configure)
:5) Build (./gbs make)
No ``./foo-0.1-1.sh check''?
:6) Install (./gbs install)
:7) Package (./gbs package)
:8) Repeat (4) - (7) as needed
:9) Generate a patch (./gbs mkpatch)
: 10) Clean (./gbs mkpatch)
``./foo-0.1-1.sh clean'' (BYKT), and do the ``clean'' first, then the
``mkpatch''.
: 11) Generate a source package (./gbs src-package)
: 12) Generate a binary package (./gbs package)
: 13) If everything looks right, take a deep breath
: and run ./gbs package all
You already did a ``./foo-0.1-1.sh package''
If you try a ``./foo-0.1-1.sh all'' you will destroy your changes, as
the only places the new patch exists, is in the .sinst-directory and
the newly built source-tarball. ``all'' will cause the original source
to be re-extracted, a new patch (without any changes) to be created
and a new source-tarball (including the new, useless patch) to be built.
:Am I missing something?
Yes. Copy the newly generated patch from the .sinst-directory
to ${topdir} before doing ``./foo-0.1-1.sh all''[1][2][3].
hth,
Buzz.
1) Doing ``./foo-0.1-1.sh all'' should not really be necessary, as you
already did all steps in it (except ``finish'')
2) It was suggested somewhere to use the generated source-tarball in
another location to test it: ``
tar -C /tmp -jxf foo-0.1-1-src.tar.bz2
cd /tmp ./foo-0.1-1.sh all
''.
3) Maybe the gbs will be doing this for you, shortly, using
``./foo-0.1-1.sh ispatch'', if my patch gets considered thoughtfully. :]
--
) | | ---/ ---/ 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
Re: Generic build script instructions
is : certainly an issue. Judging the needed effort, however, is very : subjective, so I'd prefer using the size of the necessary patch to : quantify it. Fair enough. Ny point was: Allowing multiple arguments, or auto- detecting various aspects, makes the patches bigger, but the gbs more useful. Oh, I see the confusion. I didn't mean the size of the patches that are incorporated into the gbs itself -- those can be arbitrarily large. I meant the size of the patches that the packagers have to maintain separately from the gbs, i.e., the things in the package build that don't fit into the gbs defaults. I think it's pretty obvious that *those* should be small. [append a (wrapped) GBS patch to the GBS] : 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). : : Huh? No, the GBS just gets edited -- I don't think it should go into : CYGWIN-PATCHES... It improves maintainability e.g. ``diff -u boffo-x.y/CYGWIN-PATCHES/gbs-orig boffo-x.y-1.sh'' and ``merge boffo-x.y-1.sh boffo-x.y/CYGWIN-PATCHES/gbs-orig cvsdir/gbs-new cp cvsdir/gbs-new boffo-x.y/CYGWIN-PATCHES/gbs-orig'' Oh. Well, again, I never store the build script into CYGWIN-PATCHES, but it doesn't mean that nobody else should... Everyone has his own methods. Or maybe just store the diff? One could then recreate the original gbs to merge against. That's more or less what I'm proposing. Take the (default) gbs, add a section to it that does something like (echo --- generic-build-script +++ $0; cat END-OF-PATCH @@ -1,100 +1,100 @@ - patch goes here + patch goes here END-OF-PATCH ) | patch exec $0 and let the maintainers put their patches between the cat and END-OF-PATCH. At least, that's what I had in mind. Then the set of changes to the gbs can be easily extracted (and moved) to the new version. Hope this clears up the confusion, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
RE: Generic build script instructions
: I think we could use something like make -n and check the return code... : But as I don't have the time to implement it properly now, I'll look at : whatever methods people choose to provide in their patches. It was something using a ``make -f -'' IIRC... (l8r) Hmm, make -f - will actually not be useful, FWICS. We want to check whether the Makefile contains either a test or a check rule, whereas make -f - will bypass the Makefile altogether. But if I'm wrong, it won't be the first time. ... but not this time, at least :-) Assuming that there's nothing else wrong with the makefile, make -n target will return != 0 if target does not exist (assuming that there isn't an explicit call to $(error) or similar). -Samrobb
Re: Generic build script instructions
On Sat, 19 Jun 2004, Bas van Gompel wrote:
Op Fri, 18 Jun 2004 09:04:42 -0400 (EDT) schreef Igor Pechtchanski:
[...]
: + ( exit ${STATUS} ) || exit ${STATUS}
: ^^
: + shift
: +done
:
: Do we really need a subshell here? Isn't an if test enough (and more
: efficient)?
Some thoughts. I did not do any testing on this.
*) ``if test ${STATUS} -ne 0 ; then exit ${STATUS} fi'' does fork
a ``test'', doesn't it?
*) ISTR ``autoconf'' generated ``configure''-s use a similar method.
*) Most of the gbs-functions use a subshell ``(cd ${srcdir}...'';
*) Relative to a configure, make or check this overhead should be
neglible.
Fair enough. I realized after I sent it that one extra subshell won't
matter. Never mind.
: P.S. I'm wondering whether I should ask for two separate patches, as they
: are independent and it's a bit hard to see the addition of ispatch()
: with the indentation adjustment...
Hence the ``diff -b'' copy of the patch... If you decide I need to split
this up, please let me know if you prefer any order of the patches, or
should they be independant (from a common ancestor, for you to merge).
l8r,
Buzz.
I think I'd prefer the multiple parameters patch first, with its own
ChangeLog. That part looks good enough to check in, actually. As for the
ispatch part, let's discuss the name and the possible functionality (you
mentioned adding extra), and then it can be an add-on on top of the first
patch. Frankly, I have reservations about the build script mucking with
anything outside of the build directory...
Thanks for contributing,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: Generic build script instructions
Igor Pechtchanski wrote: 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? I don't really like this -- it's moving more to a standard tool + external configury model, like imake (or even rpm/deb). While that's not a BAD model, as obviously so many tools use it, it's not what gbs was originally intended to do. Now, a change in direction is fine, if you're SURE that you want to go in that direction. But consider, if you really want a standard tool + external configury model, if gbs is really the proper framework. I'd think that cgf's netrel (or several other build helpers mentioned on this list) would be a better fit for that model. The extreme genericization(?) of gbs is only making the package more and more complicated -- and more daunting to a new porter just easing into cygwin maintainership. It's no longer a simple, quick-n-dirty tool for making cygwin packages. Even dpkg/rpm + an unroller that turns the .rpm/.deb into a .tar.gz, and pulls the trigger-scripts out and puts them into /etc/*/ appropriately, would be a better fit for the standard tool + external configury model than gbs, IMO. -- Chuck
RE: Generic build script instructions
Well, yes, I agree that if you really anticipate having to maintain
multiple packages from the outset, and want to keep more or less the same
build procedure for each of them (helps if they are related), you should
probably start already with something more sophisticated than the gbs.
I don't know. The gbs seems to be pretty good at accomplishing
it's goals without introducing a whole lot of extra overhead;
the main problem would seem to be that there's really no way
to customize the script without altering it.
So, to answer that question, why not something like this:
# --- BEGIN_DEFS ---
if [ -f ${FULLPKG}.defs ]; then
. ${FULLPKG}.defs
fi
# --- END_DEFS ---
So, if my source package name is foo.tar.Z, then I can put the
following in my defs file:
# Maintainer defs file for package foo
src_orig_pkg_name=foo.tar.Z
opt_decomp=z
This would allow a package maintainer to put specializatons/
definitions within a defs file for each package, making for
easier maintentance (except in cases of siginificantly unusual
packages).
Next, modify the gbs so that the version of the gbs that
gets included as part of the source package is result of
merging the defs file and the canonical gbs. In the above
example, when the maintainer built the source package,
everything in between the BEGIN_DEFS and the END_DEFS lines
would be replaced with the actual contents of the maintainer's
def file for the package, so that the packaged gbs would
actually look like the following:
# --- BEGIN_DEFS ---
src_orig_pkg_name=foo.tar.Z
opt_decomp=z
# --- END_DEFS ---
For this to really be effective, you'd have to have the ability
to override more than just the source package name and the
decompression flags :-/
You could probably get fancy, and do things like allow the defs
file to override individual functions (ie, unpack() checks to
see if defs_unpack() is defined; if it is, it calls defs_unpack(),
otherwise it calls std_unpack(), etc.)
-Samrobb
RE: Generic build script instructions
So, to answer that question, why not something like this:
# --- BEGIN_DEFS ---
if [ -f ${FULLPKG}.defs ]; then
. ${FULLPKG}.defs
fi
# --- END_DEFS ---
So, if my source package name is foo.tar.Z, then I can put the
[snip]
following in my defs file:
# Maintainer defs file for package foo
src_orig_pkg_name=foo.tar.Z
opt_decomp=z
This would allow a package maintainer to put specializatons/
definitions within a defs file for each package, making for
easier maintentance (except in cases of siginificantly unusual
packages).
That's the first thing that came to my mind when I switched over to using
gbs for packaging mutt. I'd put an else clause in though and croak if
there's no defs file.
--
Gary R. Van Sickle
RE: Generic build script instructions
9) Generate a patch (./gbs mkpatch) 10) Clean (./gbs mkpatch) should these both be mkpatch? ;) Hmm. Perhaps that's my problem :-) The question still remains: assuming that I'm entering the proper commands (instead of trying to clean using mkpatch :-), is this more or less the way the gbs is intended to be used? -Samrobb
Re: Generic build script instructions
Robb, Sam wrote: 9) Generate a patch (./gbs mkpatch) 10) Clean (./gbs mkpatch) should these both be mkpatch? ;) Hmm. Perhaps that's my problem :-) The question still remains: assuming that I'm entering the proper commands (instead of trying to clean using mkpatch :-), is this more or less the way the gbs is intended to be used? I'm not really sure how gbs is supposed to be used from a packager's POV. (The user's POV is obvious - ./gbs all) I've found that its usually necessary to modify the gbs for each particular package. To try to maintain reasonable organization of these modifications, I'm piping the upstream gbs through a (fairly inelegant) python script, using per-package config files to specify certain sets of customizations. 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. Max.
Generic build script instructions
Igor et. al., Are there any instructions for using the generic build script, aside from what's documented in the gdb itself? I'm looking at using the gbs for a couple of packages, and I'm trying to understand how it was intended to be used. Right now, it looks like it's something like: 1) Get source tarball (ex, foo-0.1.tar.gz) 2) Rename GBS as appropriate (ex, foo-0.1-1.sh) (hereafter refered to as gbs for brevity) 3) Use gbs to set up work area (./gbs prep) 4) Configure (./gbs configure) 5) Build (./gbs make) 6) Install (./gbs install) 7) Package (./gbs package) 8) Repeat (4) - (7) as needed 9) Generate a patch (./gbs mkpatch) 10) Clean (./gbs mkpatch) 11) Generate a source package (./gbs src-package) 12) Generate a binary package (./gbs package) 13) If everything looks right, take a deep breath and run ./gbs package all Am I missing something? I'm having trouble figuring out where I should put the README file and setup.hint - that should still go into the CYGWIN-PATCHES directory in the main srcdir, from the looks of things. Is there anythign I've missed? -Samrobb
[PATCH] generic-build-script
* generic-build-script (install): Do not invoke gzip with no arguments, and
consequently die with will not write compressed data to a terminal
if a package creates usr/share/man or usr/share/info, but does not
install any man/info pages under it.
Index: generic-build-script
===
RCS file:
/home/mirror/cvsmirror/cygwin-apps-cvs/packaging/templates/generic-build-scr
ipt,v
retrieving revision 1.22
diff -u -p -r1.22 generic-build-script
--- generic-build-script 31 Mar 2004 00:56:17 - 1.22
+++ generic-build-script 8 Jun 2004 12:16:18 -
@@ -180,12 +180,13 @@ install() {
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name *.info | \
+ xargs --no-run-if-empty gzip -q ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
-name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
- -name *.7 -o -name *.8 | xargs gzip -q ; \
+ -name *.7 -o -name *.8 | xargs --no-run-if-empty gzip -q ; \
fi \
templist= \
for f in ${install_docs} ; do \
Re: [PATCH] generic-build-script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Bowsher wrote: | * generic-build-script (install): Do not invoke gzip with no arguments, and | consequently die with will not write compressed data to a terminal | if a package creates usr/share/man or usr/share/info, but does not | install any man/info pages under it. Actually, I still have a submitted patch pending, from 19 May, which already includes this. Which remindes me, Igor, are you still working on the g-b-s? Whatever happened with that thread? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAxc9+piWmPGlmQSMRAmSKAKDJjUUGaxnfEHFVPa3d0z10nF+LCwCgtASv FKRH1zwrVA9H0Y7tEovfQnY= =mvVy -END PGP SIGNATURE-
[PATCH] generic build script
Hello Igor,
found it useful (I want to build LibJasper which is only available as
zipped archive):
--- gbs~2004-06-08 16:56:20.215388800 +0200
+++ gbs 2004-06-08 16:42:53.791884800 +0200
@@ -53,6 +53,9 @@
elif [ -e ${BASEPKG}.tar ] ; then
export opt_decomp=
export src_orig_pkg_name=${BASEPKG}.tar
+elif [ -e ${BASEPKG}.zip ] ; then
+ export opt_decomp=zip
+ export src_orig_pkg_name=${BASEPKG}.zip
else
echo Cannot find original package.
exit 1
@@ -116,7 +119,11 @@
# change this if the original package was not tarred
# or if it doesn't unpack to a correct directory
unpack() {
- tar xv${opt_decomp}f $1
+ if [ x$opt_decomp = xzip ] ; then \
+unzip $1 ; \
+ else \
+tar xv${opt_decomp}f $1 ; \
+ fi
}
mkdirs() {
Gerrit
--
=^..^=
Re: [PATCH] generic-build-script
On Tue, 1 Jun 2004, Yaakov Selkowitz wrote: Yaakov Selkowitz wrote: | If so, let me propose the attached patch instead. Ping?? Pong. Sorry for the delay. I just reviewed the whole thread, and couldn't find the corresponding ChangeLog, either yours or Gerritt's. I also couldn't find a consensus that the patch will do what it's supposed to. Frankly, I still don't see why you'd need anything more general than '-name *.info*', but I'm willing to accept it if nobody else objects. On Tue, 8 Jun 2004, Yaakov Selkowitz wrote: Max Bowsher wrote: | * generic-build-script (install): Do not invoke gzip with no arguments, and | consequently die with will not write compressed data to a terminal | if a package creates usr/share/man or usr/share/info, but does not | install any man/info pages under it. Actually, I still have a submitted patch pending, from 19 May, which already includes this. Which remindes me, Igor, are you still working on the g-b-s? Whatever happened with that thread? Yaakov Yaakov's patch subsumes Max's. Once I have the ChangeLog, I'll commit it. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: [PATCH] generic build script
On Tue, 8 Jun 2004, Gerrit P. Haase wrote:
Hello Igor,
found it useful (I want to build LibJasper which is only available as
zipped archive):
--- gbs~2004-06-08 16:56:20.215388800 +0200
+++ gbs 2004-06-08 16:42:53.791884800 +0200
@@ -53,6 +53,9 @@
elif [ -e ${BASEPKG}.tar ] ; then
export opt_decomp=
export src_orig_pkg_name=${BASEPKG}.tar
+elif [ -e ${BASEPKG}.zip ] ; then
+ export opt_decomp=zip
+ export src_orig_pkg_name=${BASEPKG}.zip
else
echo Cannot find original package.
exit 1
@@ -116,7 +119,11 @@
# change this if the original package was not tarred
# or if it doesn't unpack to a correct directory
unpack() {
- tar xv${opt_decomp}f $1
+ if [ x$opt_decomp = xzip ] ; then \
+unzip $1 ; \
+ else \
+tar xv${opt_decomp}f $1 ; \
+ fi
}
mkdirs() {
Gerrit
Gerrit,
As one of the packages I maintain is only available as a compressed shar
archive, I have already included a method into the GBS for easily dealing
with this. Simply edit the line to set src_orig_pkg_name to
LibJasper.zip, and then edit the definition of unpack() to invoke
unzip instead of tar. This kind of change is easy to maintain as a local
patch, which should apply with a minimum of fuzz in the future versions of
GBS. I'm a bit reluctant at this point to include any changes that are
only needed for one package... Maybe later we could look at restructuring
the unpack() function and augmenting the archive type detection code.
Igor
P.S. BTW, your patch won't apply as-is, since the file is named
generic-build-script, and not gbs. It also lacks a ChangeLog.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: [PATCH] for generic-build-script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yaakov Selkowitz wrote: | If so, let me propose the attached patch instead. Ping?? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAvPeZpiWmPGlmQSMRArU+AKDPSCb2DZvaQcFgnPlHK+Nmc3tPlwCgjQIJ +8JQbBKBHC3aPKl6OjRruqo= =Cxl5 -END PGP SIGNATURE-
Re: for generic-build-script
Yaakov schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
|and not pages that were already compressed (I've built a couple
|of programs that would gzip the man pages themselves on install).
|
| gzip takes care of it.
More correctly, gzip -q won't complain about it. But without the -q
flag, you get:
$ gzip test.tar.gz
gzip: test.tar.gz already has .gz suffix -- unchanged
So I think it's not optimal to be (trying) to gzip *.gz files, even if
the -q flag keeps gzip from complaining.
And -f overwrites the existing .gz files if there are any.
|But I see now with the info pages that it's more complicated than *.info
|in the cases when there are multiple info page files for one program,
|such as gcc, gdb, make, emacs, etc. Is that what your intention is?
|
| Exact. The *.info does not match on *.info-1.
That's what I thought, but you didn't explain yourself before.
| Yes, looks better (not tested yet), but why not go the easy way? Look
| what I do for GCC:
|
|( cd ${PKG1}${prefix}/share/info ; rm -f dir ; gzip -fq9 * ) \
|( cd ${PKG1}${prefix}/share/man gzip -fq9 */* ) \
This may work for gcc, but remember this is a *generic* build-script.
Some packages contain foreign-language man pages, which are stored as
/usr/share/man/de/man1, for example, and the above would not work in
such a case.
Point for you!
There are a few such package in the distro already (I noticed dpkg,
man, and WindowMaker), and I have built other such packages myself.
Hence, I think using find is the only way to correctly do this.
Alright, I agree.
Gerrit
--
=^..^=
Re: for generic-build-script
Hi Yaakov, | Exact. The *.info does not match on *.info-1. That's what I thought, but you didn't explain yourself before. Another point, recent version of texinfo and e.g. also groff are installing their info files as `texinfo` or `groff` without any suffix! So I think a generic rule for matching all the files as I suggested at first would be the most useful. Gerrit -- =^..^=
Re: for generic-build-script
Hallo Yaakov,
Am Mittwoch, 19. Mai 2004 um 19:34 schriebst du:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
| Hallo cygwin-apps,
|
| --- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
| +++ generic-build-script2004-05-19 15:49:41.196923200 +0200
| @@ -180,7 +180,7 @@
| fi ;\
|done \
|if [ -d ${instdir}${prefix}/share/info ] ; then \
| -find ${instdir}${prefix}/share/info -name *.info | xargs gzip
- -q ; \
| +find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
|fi \
|if [ -d ${instdir}${prefix}/share/man ] ; then \
| find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
|
| # END OF ANNOUNCEMENT
Gerrit,
Could you explain your reasoning behind this patch? Since I contributed
this part of the g-b-s, let me explain this. Basically, I wanted to
make sure that we were gzipping just the man and info pages, not
subdirs,
add `-type f`
and not pages that were already compressed (I've built a couple
of programs that would gzip the man pages themselves on install).
gzip takes care of it.
But I see now with the info pages that it's more complicated than *.info
in the cases when there are multiple info page files for one program,
such as gcc, gdb, make, emacs, etc. Is that what your intention is?
Exact. The *.info does not match on *.info-1.
If so, let me propose the attached patch instead. These changes should
make sure that:
1) all pages are being compressed, no matter how they are named;
2) only files are being compressed;
3) pages already compressed won't be compressed again;
4) if no qualifying pages are found, gzip won't complain (xargs -r).
Yes, looks better (not tested yet), but why not go the easy way? Look
what I do for GCC:
( cd ${PKG1}${prefix}/share/info ; rm -f dir ; gzip -fq9 * ) \
( cd ${PKG1}${prefix}/share/man gzip -fq9 */* ) \
As said above, files already compressed will not be touched by gzip.
Gerrit
--
=^..^=
Re: for generic-build-script
Hallo Igor,
Am Mittwoch, 19. Mai 2004 um 19:47 schriebst du:
On Wed, 19 May 2004, Christopher Faylor wrote:
On Wed, May 19, 2004 at 03:52:04PM +0200, Gerrit P. Haase wrote:
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
-name * is a no-op. You can just remove it.
Yep. I think what was intended here was -type f.
Yes, of course.
[...]
Gerrit, how about a resubmit, with or without the quoting, but with a
ChangeLog?
Lets wait for Yaakov, I suggested to clean it up like I do for the GCC
package. He already submitted an update to my patch.
--- g-b-s.orig2004-05-16 11:01:13.760731200 +0200
+++ g-b-s 2004-05-20 11:08:26.311102400 +0200
@@ -181,12 +181,10 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
+( cd ${instdir}${prefix}/share/info ; rm -f dir ; gzip -fq9 * ) ;\
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
-find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
- -name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
- -name *.7 -o -name *.8 | xargs gzip -q ; \
+( cd ${instdir}${prefix}/share/man gzip -fq9 */* ) ;\
fi \
templist= \
for f in ${install_docs} ; do \
Gerrit
--
=^..^=
Re: [PATCH] for generic-build-script
On Thu, 20 May 2004, Gerrit P. Haase wrote:
Hallo Igor,
Am Mittwoch, 19. Mai 2004 um 19:47 schriebst du:
On Wed, 19 May 2004, Christopher Faylor wrote:
On Wed, May 19, 2004 at 03:52:04PM +0200, Gerrit P. Haase wrote:
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
-name * is a no-op. You can just remove it.
Yep. I think what was intended here was -type f.
Yes, of course.
Actually, given your explanation in the previous message, why wouldn't
'-name *.info*' suffice? Also, come to think of it, '-name *' is
*not* a no-op, it'll filter out hidden files (.*).
[...]
Gerrit, how about a resubmit, with or without the quoting, but with a
ChangeLog?
Lets wait for Yaakov, I suggested to clean it up like I do for the GCC
package. He already submitted an update to my patch.
--- g-b-s.orig2004-05-16 11:01:13.760731200 +0200
+++ g-b-s 2004-05-20 11:08:26.311102400 +0200
@@ -181,12 +181,10 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
+( cd ${instdir}${prefix}/share/info ; rm -f dir ; gzip -fq9 * ) ;\
This will omit hidden files (not a problem, I think, just a note).
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
-find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
- -name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
- -name *.7 -o -name *.8 | xargs gzip -q ; \
+( cd ${instdir}${prefix}/share/man gzip -fq9 */* ) ;\
Are you sure gzip will handle subdirectories correctly? I have to look at
gzip's manpage and info pages carefully...
fi \
templist= \
for f in ${install_docs} ; do \
Gerrit
One more thing: shouldn't the separators in the commands be '' instead
of ';'?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: for generic-build-script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
|and not pages that were already compressed (I've built a couple
|of programs that would gzip the man pages themselves on install).
|
| gzip takes care of it.
More correctly, gzip -q won't complain about it. But without the -q
flag, you get:
$ gzip test.tar.gz
gzip: test.tar.gz already has .gz suffix -- unchanged
So I think it's not optimal to be (trying) to gzip *.gz files, even if
the -q flag keeps gzip from complaining.
|But I see now with the info pages that it's more complicated than *.info
|in the cases when there are multiple info page files for one program,
|such as gcc, gdb, make, emacs, etc. Is that what your intention is?
|
| Exact. The *.info does not match on *.info-1.
That's what I thought, but you didn't explain yourself before.
| Yes, looks better (not tested yet), but why not go the easy way? Look
| what I do for GCC:
|
|( cd ${PKG1}${prefix}/share/info ; rm -f dir ; gzip -fq9 * ) \
|( cd ${PKG1}${prefix}/share/man gzip -fq9 */* ) \
This may work for gcc, but remember this is a *generic* build-script.
Some packages contain foreign-language man pages, which are stored as
/usr/share/man/de/man1, for example, and the above would not work in
such a case. There are a few such package in the distro already (I
noticed dpkg, man, and WindowMaker), and I have built other such
packages myself. Hence, I think using find is the only way to correctly
do this.
Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFArRNEpiWmPGlmQSMRAsSWAJ91Pc7xS9f4nNM8x0I5FWesetPzUACfZ8xk
NPAZMzl/7y2fxXq3LqL+lM8=
=/Gdl
-END PGP SIGNATURE-
Re: for generic-build-script
Hello Igor,
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
-name * is a no-op. You can just remove it.
Yep. I think what was intended here was -type f.
Yes, of course.
Actually, given your explanation in the previous message, why wouldn't
'-name *.info*' suffice?
Yes, that would do it too.
[...]
+( cd ${instdir}${prefix}/share/man gzip -fq9 */* ) ;\
Are you sure gzip will handle subdirectories correctly? I have to look at
gzip's manpage and info pages carefully...
It works for me(tm).
fi \
templist= \
for f in ${install_docs} ; do \
One more thing: shouldn't the separators in the commands be '' instead
of ';'?
I have not tested it, but it is included in
if ; then
...
fi
I guessed that ; at the end of the 'then' part is correct , and
actually I only changed the 'find ... gzip ...' part between 'then'
and the semikolon.
Gerrit
--
=^..^=
[PATCH] for generic-build-script
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
# END OF ANNOUNCEMENT
Gerrit
--
=^..^=
Re: [PATCH] for generic-build-script
On Wed, May 19, 2004 at 03:52:04PM +0200, Gerrit P. Haase wrote:
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
-name * is a no-op. You can just remove it.
Also, shouldn't all of these directories be quoted, i.e:
find ${instdir}${prefix}/share/info -print0 | xargs -0 gzip -q
cgf
Re: [PATCH] for generic-build-script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
| Hallo cygwin-apps,
|
| --- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
| +++ generic-build-script2004-05-19 15:49:41.196923200 +0200
| @@ -180,7 +180,7 @@
| fi ;\
|done \
|if [ -d ${instdir}${prefix}/share/info ] ; then \
| -find ${instdir}${prefix}/share/info -name *.info | xargs gzip
- -q ; \
| +find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
|fi \
|if [ -d ${instdir}${prefix}/share/man ] ; then \
| find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
|
| # END OF ANNOUNCEMENT
Gerrit,
Could you explain your reasoning behind this patch? Since I contributed
this part of the g-b-s, let me explain this. Basically, I wanted to
make sure that we were gzipping just the man and info pages, not
subdirs, and not pages that were already compressed (I've built a couple
of programs that would gzip the man pages themselves on install).
But I see now with the info pages that it's more complicated than *.info
in the cases when there are multiple info page files for one program,
such as gcc, gdb, make, emacs, etc. Is that what your intention is?
If so, let me propose the attached patch instead. These changes should
make sure that:
1) all pages are being compressed, no matter how they are named;
2) only files are being compressed;
3) pages already compressed won't be compressed again;
4) if no qualifying pages are found, gzip won't complain (xargs -r).
Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAq5qJpiWmPGlmQSMRAlQVAJ4vTbWKY0glYWmolz9QQhyoFEGYRACgrsPv
mJ9kH/pEDur2oHxLup+vFzI=
=vmxV
-END PGP SIGNATURE-
--- generic-build-script-orig 2004-05-19 13:08:39.923334400 -0400
+++ generic-build-script2004-05-19 13:18:17.343624000 -0400
@@ -180,12 +180,12 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -type f ! -name *.gz \
+ | xargs -r gzip -q ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
-find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
- -name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
- -name *.7 -o -name *.8 | xargs gzip -q ; \
+find ${instdir}${prefix}/share/man -type f ! -name *.gz \
+ | xargs -r gzip -q ; \
fi \
templist= \
for f in ${install_docs} ; do \
Re: [PATCH] for generic-build-script
On Wed, 19 May 2004, Christopher Faylor wrote:
On Wed, May 19, 2004 at 03:52:04PM +0200, Gerrit P. Haase wrote:
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
-name * is a no-op. You can just remove it.
Yep. I think what was intended here was -type f.
Also, shouldn't all of these directories be quoted, i.e:
find ${instdir}${prefix}/share/info -print0 | xargs -0 gzip -q
cgf
True, but, AFAICS, the whole GBS suffers from this. I should make a pass
and fix all of them in one sweep.
Gerrit, how about a resubmit, with or without the quoting, but with a
ChangeLog?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: Busted generic build script?
Igor Pechtchanski wrote: On Thu, 18 Mar 2004, Harold L Hunt II wrote: [snip] Oops. Mea culpa. I've verified that it worked in bash, and ran the script through sh -n (which turns out to not be enough). Harold, could you please try the attached patch and see if it fixes things for you? If yes, I'll commit it to CVS. Igor Yes, the patch fixes the problem. Thanks, Harold
Re: Busted generic build script?
On Thu, 18 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: On Thu, 18 Mar 2004, Harold L Hunt II wrote: [snip] Oops. Mea culpa. I've verified that it worked in bash, and ran the script through sh -n (which turns out to not be enough). Harold, could you please try the attached patch and see if it fixes things for you? If yes, I'll commit it to CVS. Igor Yes, the patch fixes the problem. Thanks, Harold Harold, Great, committed. Those quoting issues are tricky. :-) Thanks very much for testing. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
New patch for generic build script (was RE: Pending patches for generic build script)
All,
I am attaching a new release of the this patch to mitigate below.
Igor, please review and advise. Note: I built against 1.19 for the
generic-build-script and 1.7 for the
generic readme.
Change log entry:
2004-02-24 Alan Miles [EMAIL PROTECTED]
* templates/generic-readme : Changed the runtime requirements string
from other requirements, e.g., libintl1 to:
other Runtime requirements, e.g., libintl1 allowing better text
replacement using the values generated by depend() function. The generic
build script will replace this string in its function readmelist().
* templates/generic-readme : Changed the build requirements string
from other requirements, e.g., gettext to:
other Build requirements, e.g., gettext allowing better text
replacement using values from the generic build script, which
will replace this string in its function readmelist().
* templates/generic-readme : Replaced the listed files under the
Files included section with the string THEFILES. The generic
build script will replace the string THEFILES with a sorted list of
files which will comprise the binary distribution. The generic build
scripts readmelist() function does this.
* templates/generic-readme : Changed the port notes string
from Other information to:
Other Port information allowing better text
replacement using values from the generic build script, which
will replace this string in its function readmelist().
* templates/generic-readme : Changed the older release string
from PKG-older VER-1 to:
PKG-older VER-older REL since the release number
may not be 1. The generic build script will analyse the setup.hint file
and set the values of older VER and older REL, substituting these
values. If the script cannot find the setup.hint file, these values
become values of VER and REL respectively.Again the generic build
script's readmelist() and hintfiledata() functions do the substitutions
and extract the data from the setup.hint file.
* templates/generic-build-script : Added defaults and instructions to
Package
maintainers regarding some new constants:
export SHORTDESC=short description, 2 or 3 lines
export OTHERRUNTIME= other Runtime requirements, e.g., libintl1
export OTHERBUILD= other Build requirements, e.g., gettext
export OTHERPORT=Other Port information
export OLDERVER=${VER} # Set the default to the current package's
version number
export OLDERREL=${REL} # Set the default to the current package's
release number
export MAINTNAME=Your Name Here
export MAINTEMAIL=your email here
The readmelist() function substitutes these values into the binary
package README.
Note: Function hintfiledata() overrides the values of SHORTDESC, setting
it to the
setup.hint file's ldesc value, and obtains the OLDERVER, OLDERREL values
from the
setup.hint if it contains the prev: value
* templates/generic-build-script : Added function hintfiledata() which
parses
and extracts the ldesc: value and prev: values, if the
${srcdir}/CYGWIN-PATCHES/setup.hint file exists, altering the SHORTDESC,
OLDERVER,
OLDERREL values respectively.
* templates/generic-build-script : Added function readmelist() which
examines
all the files in ${instdir}, sorting them and then replacing the
THEFILES string
with the lines. This replacement exploits sed's e command, which allows
one to pipe
input from a shell command into pattern space. The command does the
following replacements:
(a) string PKG becomes the value of ${PKG}
(b) string VER becomes the value of ${VER}
(c) string REL becomes the value of ${REL}
(d) string package name becomes the value of ${PKG}
(e) string short description, 2 or 3 lines becomes the value of
${SHORTDESC}
(f) string other Build requirements, e.g., gettext becomes the value
of ${OTHERBUILD}
(g) string Other Port information becomes the value of ${OTHERPORT}
(h) string older VER becomes the value of ${OLDERVER}
(i) string older REL becomes the value of ${OLDERREL}
(j) string Your Name Here becomes the value of ${MAINTNAME}
(k) string your email here becomes the value of ${MAINTMAIL}
(l) string other Runtime requirements, e.g., libintl1 becomes the
value of sorted
depends() function.
* templates/generic-build-script : Added the call to function
readmelist() in the all list
* templates/generic-build-script : Fixed a problem in the functions
strip(), mkpatch(),
and depend() when there are no dll's or exes (the find returns no
files) - xargs would try to
execute strip or cygcheck/cygpath
Re: New patch for generic build script
Alan, I was going to say that I'll review the patch later, and offer a few quick comments, but it looks like I did a full patch review, so here goes: (1) WOW, this is a HUGE ChangeLog. Wa-ay too detailed. Most of this stuff should go into comments in the script, if you feel like documenting it at all and if it isn't self-documenting. I also forgot to include a link to the Cygwin ChangeLog guidelines (http://cygwin.com/contrib.html, based on the GNU ChangeLog guidelines, to which there's a link on the above page), so please review that. Just to give you a feel for what would be the right level of detail, here's an attempt to shorten this: 2004-02-24 Alan Miles alan.milesatieee.org * templates/generic-readme: Fix phrasing for better pattern matching. Parameterize initial release version. * templates/generic-build-script: Add 'readmelist' argument that calls readmelist(). Add readmelist() to the 'all' sequence. Define constant strings for pattern matching. (readmelist): New function to update the README. (hintfiledata): New function to extract setup.hint data. (strip,mkpatch,depend): Add xargs option to prevent complaints when no executables are found. (install): Parameterize README filename. Even that might be too detailed, but at least it's manageable. :-) I may have missed something, too. (2) It's usually a good idea to submit independent changes as separate patches. For example, I'd do the xargs change separately. I'm not sure if the rest of the patch is acceptable as-is (pending further review), but I'd suggest singling this change out and sending a separate short patch. (3) Please, please set your linewrap at 80 columns (for both the patch and the ChangeLog). It might even be better for the ChangeLog to be wrapped at 76 columns or so... (4) I'd like to keep the order or the file entries (i.e., /etc/postinstall at the end). I also think it would be good to keep the (this file) after the README entry. (5) Frankly, I don't see the point in the first hunk of the readme patch. You can just as well match all of the lines between 'Runtime requirements' and 'other requirements.*' (or 'Build requirements'...). (6) I've been thinking that it might actually be better to have a computer-readable README.in, and a separate 'gen_readme' script that would produce a README from it. The reasoning here is that the package build script is invoked not only by the package maintainers, but also (hopefully) every time someone builds a package from sources. Do we really want to regenerate the README for these people? Besides, the dependences are all going to be different, at the very least. Alternatively, leave the functionality in the generic-build-script, but don't call it by default (like signing). (7) If the variable's value comes from the ldesc field, why not name it LDESC? You might want to give similar descriptive naming to other variables. (8) The OTHERPORT idea is wrong, wrong, wrong. I mentioned this earlier, but I guess I wasn't articulate enough. OTHERPORT is actually a whole change log for the previous ports. There should be no reason to regenerate it, and certainly no reason to stick the port notes information into the script. It might be ok to have the *latest* version's changes in the script (after all, that's the version that this script builds), but the others should be put into the readme only once. Perhaps we should table it and get the rest of the patch going. In fact, let's do this a couple of patterns at a time. Some things can be easily extracted from other places, such as setup.hint, so for those it makes sense to have auto-generation. If the maintainer has to modify a variable in the script to put some text into the README, why not put it directly into the README and avoid the hassle? If you think that having only one file to maintain is easier, I doubt that's true -- eventually the 'one-size-fits-all' generic-build-script will become a maintenance nightmare, especially with trying to pull in the latest changes from CVS. So, please split your patch into multiple contained patches, each of which has one independent part of this functionality. We'll look at one patch at a time, and decide what to do with them on a patch-by-patch basis, rather than trying to get approval for one monster patch. Ooh, boy, I just read all of the above... I'm getting really verbose as the night grows older. Good thing I'm not writing ChangeLogs. :-) In your words: now to bed... Igor P.S. I'm too tired to snip out the relevant parts from the message below. Apologies to all for a long quote. On Tue, 24 Feb 2004, Alan Miles wrote: All, I am attaching a new release of the this patch to mitigate below. Igor, please review and advise. Note: I built against 1.19 for the generic-build-script and 1.7 for the generic readme. Change log entry: 2004-02-24 Alan Miles alan.milesatieee.org
RE: Pending patches for generic build script
On Sat, 21 Feb 2004, Rafael Kitover wrote:
-Original Message-
From: Igor Pechtchanski
Sent: Saturday, February 14, 2004 7:23 AM
Subject: Re: Pending patches for generic build script
On Fri, 13 Feb 2004, Charles Wilson wrote:
Igor Pechtchanski wrote:
false || true
As a bonus, this construct documents that this particular line can
return a false value.
I see. Well, this does look reasonably readable... Another problem with
set +e that I vaguely recall reading about is that it may not always be
propagated into functions... If you're willing to test this and make sure
it always works properly, and if nobody else protests, I'll consider
patching the generic-build-script.
Yes, I've never liked the silly looking ' \' syntax in the gbs. If
propagation of 'set +e' into functions is a problem, then just have each
function re-do it...
Chuck,
Ok, great! Since you're in favor of it (and you're the ultimate authority
on the gbs, I'm just temporarily handling the maintainer duties), it makes
me much more confident. I'll let Rafael test out the propagation of set
+e into functions, and then make the appropriate change.
[SNIP]
Umm, yes, since bash is in the Base category, any Cygwin machine will
have it, and it's not like the performance of the gbs itself is an
issue...
I think I'll wait until all the others' patches have been applied, though,
and then do it in one shot as one big change.
Rafael, if you're reading this, could you do the tests with both sh and
bash, and let me know if bash behaves better with respect to set +e? If
it does, we can switch the gbs to use bash.
Igor
Of course, waiting for the various gbs patches to go through first makes
perfect sense. I was just bringing up the issue for discussion, it's not an
emergency, we have plenty of those over on the main list :)
Yeah, I know what you mean. But changing the gbs via small incremental
improvements is the way to go, IMO. Using the set +e approach vs. the
current '' one will improve readability and make the gbs more robust.
FWIW, I've emptied my patch queue for now, so feel free to start testing.
What I was planning to do was make a canonical Cygwin package, kind of like GNU
Hello, using Hello as a base, and call it boffo to match the setup
documentation :) Eventually we'll be at a point were a new maintainer can get a
copy of boffo, tweak it, make their package, and have the package script do
some basic sanity checks. Also add some sort of selftest function for the gbs
against the canonical package, making development of the gbs itself a bit
easier (it can really suck when you have to wait half an hour for a build to go
through to check a minor tweak in the package script...)
I'm not sure I parsed all of this correctly, but I'll probably get it once
the patches actually arrive. :-)
Another feature I've dreamt up is have an update-script function for
the gbs, such that you could run pkg/CYGWIN-PATCHES/pkg.sh update-script
which would get the latest copy out of cvs or wherever is appropriate,
and patch the maintainer's script with the latest tweaks, as an
interactive patch if necessary.
Sure, just don't call it ${PKG}.sh, since that name is now recognized as
a postinstall script... The latest version of the gbs makes it somewhat
easier, since it now contains the CVS Id tag.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: New patch for generic-build-script
On Wed, 18 Feb 2004, Yaakov Selkowitz wrote:
Igor,
OK, here's the patch again, along with my ChangeLog. Feel free to edit
as necessary.
Yaakov
2004-02-17 Yaakov Selkowitz yselkowitz AT users DOT sourceforge DOT net
* generic-build-script: Add 'configure', 'make', and 'test'
arguments as aliases for 'conf', 'build', and 'check'
respectively. Add 'first' argument that calls mkdir(), spkg(),
and finish(). Add checksig() to beginning of 'all' sequence.
(install_docs): Add ABOUT-NLS, FAQ, THANKS.
(SIG): Define as 1 (on by default).
(reconf): New function for clean reconfigure.
(install): Clean ${instdir} before install. Automatically gzip
info and man pages, if present. Code cleanup.
(list): Simplify sed expression.
(depend): New function for listing runtime dependencies of
package executables and libraries.
(strip,mkpatch): Remove redirection of output to /dev/null.
(spkg): Improve readability. Change test of ${SIG} to equality.
(checksig): Change order to ORIGINAL PACKAGE, SCRIPT, PATCH.
Change test of ${SIG} to equality.
Yaakov,
This looks good. The only two comments I have are:
1) You replaced ''s by ';' after 'fi's in install() (where they were
needed), and left the one after 'find' in mkpatch() (where it was not).
This is minor, and I edited the patch accordingly[*] -- just letting you
know to expect conflicts with your local copy after the patch is applied.
2) Did you really mean to turn package signing on by default? I, for
example, don't use package signing for my packages, and don't even have
GPG installed. I'd rather the default setting was to not sign the
packages, and signing could be turned on on a package-by-package basis.
If you don't mind, I'll change that '1' to a '0' for now (please speak up
if you disagree). Alternatively, we could check for the existence of
/usr/bin/gpg as one of the factors for turning on package signing,
something like 'SIG=`[ ! -x /usr/bin/gpg ]; echo $?`', but that could come
in a later patch.
Once you respond to this, I'll apply the patch. Thanks for contributing.
Igor
[*] FYI, here are the diffs between the edited patch and the original:
@@ -44,7 +44,7 @@
TODO \
export test_rule=test
-+export SIG=1 #set to 0 to turn off signing by default
++export SIG=0 #set to 1 to turn on signing by default
# helper function
# unpacks the original package source archive into ./${BASEPKG}/
@@ -75,12 +75,12 @@
done \
+ if [ -d ${instdir}${prefix}/share/info ] ; then \
+find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
-+ fi ; \
++ fi \
+ if [ -d ${instdir}${prefix}/share/man ] ; then \
+find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
+ -name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
+ -name *.7 -o -name *.8 | xargs gzip -q ; \
-+ fi ; \
++ fi \
templist= \
for f in ${install_docs} ; do \
if [ -f ${srcdir}/$f ] ; then \
@@ -126,7 +126,7 @@
mkpatch() {
(cd ${srcdir} \
- find . -name autom4te.cache | xargs rm -rf /dev/null ; \
-+ find . -name autom4te.cache | xargs rm -rf \
++ find . -name autom4te.cache | xargs rm -rf ; \
unpack ${src_orig_pkg} \
mv ${BASEPKG} ../${BASEPKG}-orig \
cd ${topdir} \
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ [EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-'Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: New patch for generic-build-script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor Pechtchanski wrote: | Yaakov, | | This looks good. The only two comments I have are: | | 1) You replaced ''s by ';' after 'fi's in install() (where they were | needed), and left the one after 'find' in mkpatch() (where it was not). | This is minor, and I edited the patch accordingly[*] -- just letting you | know to expect conflicts with your local copy after the patch is applied. Oh, THAT'S what you meant. I missed that one. Sorry. | 2) Did you really mean to turn package signing on by default? I, for | example, don't use package signing for my packages, and don't even have | GPG installed. I'd rather the default setting was to not sign the | packages, and signing could be turned on on a package-by-package basis. | If you don't mind, I'll change that '1' to a '0' for now (please speak up | if you disagree). Alternatively, we could check for the existence of | /usr/bin/gpg as one of the factors for turning on package signing, | something like 'SIG=`[ ! -x /usr/bin/gpg ]; echo $?`', but that could come | in a later patch. | | Once you respond to this, I'll apply the patch. Thanks for contributing. | Igor | [*] FYI, here are the diffs between the edited patch and the original: Alright, everything looks fine. Go ahead and check it in. When I see this clear on cygwin-cvs-apps, I'll start looking at my next round of patches. Thanks! Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAM3t0piWmPGlmQSMRAgvpAKDq6OiH5mhJY8fg+rF0G7VB9v5WnQCgrwub 0vClXN56GT+7L+W7kDiUSuo= =5UFz -END PGP SIGNATURE-
