generic-build-script extension to update version numbers in README

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

generic-build-script extension to update version numbers in README

Christian Franke
[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-script Fri 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}" 2>&1 | tee ${makelogfile} )
+  make CFLAGS="${MY_CFLAGS}" 2>&1 | 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 \
Reply | Threaded
Open this post in threaded view
|

Re: generic-build-script extension to update version numbers in README

Igor Peshansky
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 features of the g-b-s into a separate script (tentative name:
"maintainer-only-features.sh", suggestions welcome).  In the meantime,
another thing that would help is defining the "core g-b-s" features.  Is
anyone using the package signature feature?  acceptpatch?  logging?

> 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.

There was also Jari Aalto's build script (I forget the name) which had
some of the above properties, IIRC.

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.
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_ [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ [hidden email]
     |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Reply | Threaded
Open this post in threaded view
|

Re: generic-build-script extension to update version numbers in README

Charles Wilson-2
Igor Pechtchanski wrote:

> 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.

At times I wish that I had originally stored all of my build scripts in
a cvs repository.  If I imported the "official" generic-build-script as
a "vendor branch", then I could more easily do a 'cvs merge -j
vendor-release-27' within a workspace on the 'gettext' branch...

That would have made this a lot easier.  But now, it's just too much
work to set up for all 30+ packages, so I keep on keeping on,
hand-merging with every new release...

>>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.
I too thought of a "regular" gbs and a single "maintainer-extras"
script.  However, I suggested multiple fragments because it's
open-ended.  We just keep adding more fragments to the master
repository, and it's up to the end-user (e.g. package maintainers) which
ones they actually download and use.  Or they can write their own.
Maybe the "regular" gbs's 'maintainer-action' function can honor an
environment variable, like CVSROOT: GBS_PATH=.:/usr/src/gbs-fragments or
something.  That way, gbs can look in the specified locations for the
proper fragments ('.' first for package-specific versions).

Sure, it's insecure as all heck, but if you're maintaining cygwin
packages on a compromised machine...we've ALL got a problem!

> 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).

See attached patch, which shows the changes from gbs-1.38 and
gettext-0.14.5-1.  These changes were necessary to support:

1) four separate binary packages

2) two variant builds: "normal" and "relocatable".  I wanted both
variants to be buildable with only minor changes to the buildscript
(it's simply a 3 line change to the buildscript now)

3) The upstream maintainer is VERY specific about which files should go
into the "runtime" package (cygwin's libintl3 + libgettextpo0 + gettext
packages) and which files should go into the developer's package
(cygwin's gettext-devel).  It's not a simple regex, but specific file
listings.

4) The test suite CAN be run all at once -- but the rpath tests take
over an hour.  I split them up into three different sets.

5) My modifications require bootstrapping.  To ease maintainance and
avoid giant patches, I ship only the pre-autotool patches and run the
bootstrap as part of the prep() phase.

6) I *also* run the boostrap in the -orig directory as part of the
mkpatch() step.  Thus, I ship two patches: the pre-autotool one, and the
post-autotool one (which SHOULD just be the contents of CYGWIN-PATCHES
if I've done it right).

7) Since I've got two patches, I had to include them both in the
checksig and spkg functions, along with their signatures.  (No, I don't
actually sign anything, but it's all set up if someone more security
obsessed were to take over my package)

BTW, the cvs buildscript is even worse: I have to keep track of which
tests in the testsuite are known-to-fail, for two different test
harnesses (local and pseudo-remote) -- because a failed test completely
stops the suite.  No '-k' option!  Heck, even my simplest package, zlib,
doesn't use the gbs directly; zlib is not autotool enabled so...

> 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.

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.

>>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.

I know.  I'm just a curmudgeon.

> Let me try to find some time (probably in a couple of weeks) to extract
> the non-core features of the g-b-s into a separate script (tentative name:
> "maintainer-only-features.sh", suggestions welcome).  In the meantime,
> another thing that would help is defining the "core g-b-s" features.  Is
> anyone using the package signature feature?

Unfortunately, no -- because it's intrinsically tied in with spkg.  If
we didn't need to actually SHIP the signatures, then we could move all
signature-related stuff to an aux script.  But that kinda defeats the
purpose.

   acceptpatch?

IMO, yes.  Ditto 'muck-with-readme', 'list', 'depends'.

  logging?

No, for reasons described above.  I'd *LOVE* to be wrong about this, but
the only cures I see are worse than the disease.

>> 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.
>
> There was also Jari Aalto's build script (I forget the name) which had
> some of the above properties, IIRC.

Sure, with enough man-hours you can do anything you want.  But if it's
hard for existing maintainers to keep up with the current incremental
changes to gbs, it'll be durn near impossible to follow a wholesale
architectural redesign.

> 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.

You're still thinking that they are "private mods" as in 'tetchy little
changes here and there'.  It's more like gbs is used as a base from
which to massively fork, with wholesale rewriting of some of the
functions. Maybe I'm just lucky in that my packages SUCK and everybody
else gets to use the gbs unmodified, but not me.  I almost ALWAYS have
to modify install(), for instance.  And any time I have to re-run the
autotools, Katie bar the door...

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...

--
Chuck


--- /desktop/generic-build-script 2005-10-31 00:09:38.359375000 -0500
+++ gettext-0.14.5-1.sh 2005-11-15 03:38:42.000000000 -0500
@@ -43,6 +43,10 @@
 export SHORTPKG=${PKG}-${VER}
 export FULLPKG=${SHORTPKG}-${REL}
 
+PKG2=libintl3
+PKG3=gettext-devel
+PKG4=libgettextpo0
+
 # determine correct decompression option and tarball filename
 export src_orig_pkg_name=
 if [ -e "${src_orig_pkg_name}" ] ; then
@@ -70,20 +74,38 @@
 # determine correct names for generated files
 export src_pkg_name=${FULLPKG}-src.tar.bz2
 export src_patch_name=${FULLPKG}.patch
+export src_patch_name2=${FULLPKG}.patch2
 export bin_pkg_name=${FULLPKG}.tar.bz2
+export bin_pkg_name2=${PKG2}-${VER}-${REL}.tar.bz2
+export bin_pkg_name3=${PKG3}-${VER}-${REL}.tar.bz2
+export bin_pkg_name4=${PKG4}-${VER}-${REL}.tar.bz2
 
 export src_pkg=${topdir}/${src_pkg_name}
 export src_patch=${topdir}/${src_patch_name}
+export src_patch2=${topdir}/${src_patch_name2}
 export bin_pkg=${topdir}/${bin_pkg_name}
+export bin_pkg2=${topdir}/${bin_pkg_name2}
+export bin_pkg3=${topdir}/${bin_pkg_name3}
+export bin_pkg4=${topdir}/${bin_pkg_name4}
 export srcdir=${topdir}/${BASEPKG}
 export objdir=${srcdir}/.build
 export instdir=${srcdir}/.inst
 export srcinstdir=${srcdir}/.sinst
 export checkfile=${topdir}/${FULLPKG}.check
 
-prefix=/usr
-sysconfdir=/etc
-localstatedir=/var
+if [ -f ${objdir}/RELOC ] ; then
+  RELOCDIR=`cat ${objdir}/RELOC`
+else
+  # RELOCDIR=`mktemp -d /tmp/gettext-reloc-XXXXXX`
+  RELOCDIR=
+  echo -n ${RELOCDIR} > ${objdir}/RELOC
+fi
+
+prefix=${RELOCDIR}/usr
+sysconfdir=${RELOCDIR}/etc
+localstatedir=${RELOCDIR}/var
+pnoslash=`echo $prefix | sed -e "s#^${RELOCDIR}##" -e 's#^/##'`
+snoslash=`echo $sysconfdir | sed -e "s#^${RELOCDIR}##" -e 's#^/##'`
 if [ -z "$MY_CFLAGS" ]; then
   MY_CFLAGS="-O2"
 fi
@@ -91,6 +113,8 @@
   MY_LDFLAGS=
 fi
 
+alias_path="${RELOCDIR}/usr/share/locale:${RELOCDIR}/usr/local/share/locale:${RELOCDIR}/usr/X11R6/lib/X11/locale"
+
 export install_docs="\
  ABOUT-NLS \
  ANNOUNCE \
@@ -126,6 +150,80 @@
 # Sort in POSIX order.
 export LC_ALL=C
 
+PKG1_LIST="\
+  ${pnoslash}/share/doc/Cygwin/${PKG}-${VER}.README \
+  ${pnoslash}/share/doc/${PKG}-${VER}/* \
+  ${pnoslash}/share/gettext/ABOUT-NLS \
+  ${pnoslash}/bin/gettext.*exe \
+  ${pnoslash}/bin/ngettext.*exe \
+  ${pnoslash}/bin/envsubst.*exe \
+  ${pnoslash}/bin/gettext.sh \
+  ${pnoslash}/share/man/man1/gettext.* \
+  ${pnoslash}/share/man/man1/ngettext.* \
+  ${pnoslash}/share/man/man1/envsubst.* \
+  ${pnoslash}/share/doc/gettext/gettext.1.html \
+  ${pnoslash}/share/doc/gettext/ngettext.1.html \
+  ${pnoslash}/share/doc/gettext/envsubst.1.html \
+  ${pnoslash}/share/locale/*/LC_MESSAGES/gettext-runtime.mo \
+  ${pnoslash}/lib/libintl.* \
+  ${pnoslash}/lib/charset.alias \
+  ${pnoslash}/share/locale/locale.alias \
+  ${pnoslash}/include/libintl.h \
+  ${pnoslash}/share/man/man3/* \
+  ${pnoslash}/share/doc/gettext/*.3.html \
+  ${pnoslash}/share/doc/gettext/javadoc1/* \
+  ${pnoslash}/share/doc/gettext/javadoc2/* \
+  ${pnoslash}/share/doc/gettext/csharpdoc/* \
+  ${pnoslash}/lib/libasprintf.* \
+  ${pnoslash}/include/autosprintf.h \
+  ${pnoslash}/share/doc/libasprintf/autosprintf.html \
+  ${pnoslash}/share/info/autosprintf.info* \
+"
+PKG2_LIST="\
+  ${pnoslash}/bin/cygintl-*.dll \
+"
+PKG4_LIST="\
+  ${pnoslash}/bin/cyggettextpo-*.dll \
+  ${pnoslash}/bin/cyggettextlib-*.dll \
+  ${pnoslash}/bin/cyggettextsrc-*.dll \
+"
+PKG3_LIST="\
+  ${pnoslash}/share/doc/Cygwin/${PKG3}-${VER}.README \
+  ${pnoslash}/bin/msg*.*exe \
+  ${pnoslash}/bin/xgettext.*exe \
+  ${pnoslash}/bin/gettextize \
+  ${pnoslash}/bin/autopoint \
+  ${pnoslash}/share/man/man1/msg*.* \
+  ${pnoslash}/share/man/man1/xgettext.* \
+  ${pnoslash}/share/man/man1/gettextize.* \
+  ${pnoslash}/share/man/man1/autopoint.* \
+  ${pnoslash}/share/doc/gettext/msg*.1.html \
+  ${pnoslash}/share/doc/gettext/xgettext.1.html \
+  ${pnoslash}/share/doc/gettext/gettextize.1.html \
+  ${pnoslash}/share/doc/gettext/autopoint.1.html \
+  ${pnoslash}/share/doc/gettext/gettext_*.html \
+  ${pnoslash}/share/doc/gettext/tutorial.html \
+  ${pnoslash}/share/doc/gettext/FAQ.html \
+  ${pnoslash}/share/doc/gettext/examples/* \
+  ${pnoslash}/share/info/gettext.info* \
+  ${pnoslash}/include/gettext-po.h \
+  ${pnoslash}/lib/libgettextlib* \
+  ${pnoslash}/lib/libgettextsrc* \
+  ${pnoslash}/lib/libgettextpo* \
+  ${pnoslash}/lib/gettext/* \
+  ${pnoslash}/share/locale/*/LC_MESSAGES/gettext-tools.mo \
+  ${pnoslash}/share/gettext/config.rpath \
+  ${pnoslash}/share/gettext/mkinstalldirs \
+  ${pnoslash}/share/gettext/intl/* \
+  ${pnoslash}/share/gettext/po/* \
+  ${pnoslash}/share/gettext/projects/* \
+  ${pnoslash}/share/gettext/gettext.h \
+  ${pnoslash}/share/gettext/msgunfmt.tcl \
+  ${pnoslash}/share/gettext/archive.tar.gz \
+  ${pnoslash}/share/aclocal/* \
+  ${pnoslash}/share/emacs/site-lisp/* \
+"
+
 # helper functions
 
 # Provide help.
@@ -142,6 +240,9 @@
     reconf Rerun configure
     build, make Build the package (make)
     check, test Run the testsuite (make ${test_rule})
+    check-rpath         Run the rpath subset of make check
+    check-runtime       Run the runtime subset of make check
+    check-tools         Run the tools subset of make check
     clean Remove built files (make clean)
     install Install package to staging area (make install)
     list List package contents
@@ -179,17 +280,35 @@
   mkdir -p ${instdir} && \
   mkdir -p ${srcinstdir} )
 }
+patchit() {
+  thedir=$1
+  (cd ${thedir} && \
+  if [ -f ${src_patch} ] ; then \
+    patch -Z -p1 < ${src_patch} ;\
+  fi )
+}
+fixup() {
+  thedir=$1
+  (cd ${thedir} && \
+  ./autogen.sh )
+}  
 prep() {
   (cd ${topdir} && \
   unpack ${src_orig_pkg} && \
   cd ${topdir} && \
-  if [ -f ${src_patch} ] ; then \
-    patch -Z -p0 < ${src_patch} ;\
-  fi && \
-  mkdirs )
+  patchit ${srcdir}
+  fixup ${srcdir}
+  if [ -f ${src_patch2} ] ; then \
+    patch -Z -p0 < ${src_patch2} ;\
+  fi
+  mkdirs && \
+  cd ${srcdir} && \
+  chmod +x gettext-tools/misc/gettextize.in && \
+  chmod +x gettext-tools/misc/autopoint.in )
 }
 conf() {
   (cd ${objdir} && \
+  export PATH=/usr/X11R6/bin:/usr/bin:/bin
   CFLAGS="${MY_CFLAGS}" LDFLAGS="${MY_LDFLAGS}" \
   ${srcdir}/configure \
   --srcdir=${srcdir} --prefix="${prefix}" \
@@ -197,7 +316,10 @@
   --libdir='${prefix}/lib' --includedir='${prefix}/include' \
   --mandir='${prefix}/share/man' --infodir='${prefix}/share/info' \
   --libexecdir='${sbindir}' --localstatedir="${localstatedir}" \
-  --datadir='${prefix}/share' )
+  --datadir='${prefix}/share' \
+  --with-included-gettext --disable-rpath && \
+  chmod +x gettext-tools/misc/gettextize && \
+  chmod +x gettext-tools/misc/autopoint )
 }
 reconf() {
   (cd ${topdir} && \
@@ -207,11 +329,27 @@
 }
 build() {
   (cd ${objdir} && \
-  make CFLAGS="${MY_CFLAGS}" )
+  make CFLAGS="${MY_CFLAGS}" aliaspath=${alias_path} EMACS=no )
 }
+check_rpath() {
+  (cd ${objdir}/autoconf-lib-link && \
+  CFLAGS="${MY_CFLAGS}" LDFLAGS="${MY_LDFLAGS}" \
+  make aliaspath=${alias_path} EMACS=no check | tee ${checkfile}-rpath 2>&1
+)}
+check_runtime() {
+  (cd ${objdir}/gettext-runtime && \
+  CFLAGS="${MY_CFLAGS}" LDFLAGS="${MY_LDFLAGS}" \
+  make aliaspath=${alias_path} EMACS=no check | tee ${checkfile}-runtime 2>&1
+)}
+check_tools() {
+  (cd ${objdir}/gettext-tools && \
+  CFLAGS="${MY_CFLAGS}" LDFLAGS="${MY_LDFLAGS}" \
+  make aliaspath=${alias_path} EMACS=no check | tee ${checkfile}-tools 2>&1
+)}
 check() {
-  (cd ${objdir} && \
-  make ${test_rule} | tee ${checkfile} 2>&1 )
+  check_rpath
+  check_runtime
+  check_tools
 }
 clean() {
   (cd ${objdir} && \
@@ -220,17 +358,21 @@
 install() {
   (cd ${objdir} && \
   rm -fr ${instdir}/* && \
-  make install DESTDIR=${instdir} && \
+  make install DESTDIR=${instdir} alias_path=${alias_path} EMACS=no && \
+  (cd ${instdir}${prefix}/bin ; chmod +x *.dll ) && \
   for f in ${prefix}/share/info/dir ${prefix}/info/dir ; do \
     if [ -f ${instdir}${f} ] ; then \
       rm -f ${instdir}${f} ; \
     fi ;\
   done &&\
-  for d in ${prefix}/share/doc/${SHORTPKG} ${prefix}/share/doc/Cygwin ; do \
+  for d in ${prefix}/share/doc/${SHORTPKG} ${prefix}/share/doc/Cygwin \
+           ${prefix}/share/emacs/site-lisp ; do \
     if [ ! -d ${instdir}${d} ] ; then \
       mkdir -p ${instdir}${d} ;\
     fi ;\
   done &&\
+  /usr/bin/install -m 644 ${srcdir}/gettext-tools/misc/*.el \
+     ${instdir}${prefix}/share/emacs/site-lisp/ && \
   if [ -d ${instdir}${prefix}/share/info ] ; then \
     find ${instdir}${prefix}/share/info -name "*.info" | xargs -r gzip -q ; \
   fi && \
@@ -254,6 +396,12 @@
     /usr/bin/install -m 644 $templist \
  ${instdir}${prefix}/share/doc/${SHORTPKG} ; \
   fi && \
+  cat ${srcdir}/CYGWIN-PATCHES/${PKG}.frag \
+    ${srcdir}/CYGWIN-PATCHES/README.frag > \
+         ${instdir}${prefix}/share/doc/Cygwin/${PKG}-${VER}.README && \
+  cat ${srcdir}/CYGWIN-PATCHES/${PKG3}.frag \
+    ${srcdir}/CYGWIN-PATCHES/README.frag > \
+         ${instdir}${prefix}/share/doc/Cygwin/${PKG3}-${VER}.README && \
   if [ -f ${srcdir}/CYGWIN-PATCHES/${PKG}.README ]; then \
     /usr/bin/install -m 644 ${srcdir}/CYGWIN-PATCHES/${PKG}.README \
       ${instdir}${prefix}/share/doc/Cygwin/${SHORTPKG}.README ; \
@@ -290,6 +438,8 @@
   fi )
 }
 strip() {
+  # maybe: only strip cygintl.  The other dlls are fragile.
+  #   find . -name "cygintl*.dll" | xargs strip > /dev/null 2>&1
   (cd ${instdir} && \
   find . -name "*.dll" -or -name "*.exe" | xargs -r strip 2>&1 ; \
   true )
@@ -307,18 +457,26 @@
   true )
 }
 pkg() {
-  (cd ${instdir} && \
-  tar cvjf ${bin_pkg} * )
+  (cd ${instdir}${RELOCDIR} && \
+  tar cvjf ${bin_pkg} ${PKG1_LIST}   && \
+  tar cvjf ${bin_pkg2} ${PKG2_LIST}  && \
+  tar cvjf ${bin_pkg3} ${PKG3_LIST}  && \
+  tar cvjf ${bin_pkg4} ${PKG4_LIST}  )
 }
 mkpatch() {
   (cd ${srcdir} && \
   find . -name "autom4te.cache" | xargs -r rm -rf ; \
   unpack ${src_orig_pkg} && \
   mv ${BASEPKG} ../${BASEPKG}-orig && \
+  temp=`(cd ../${PKG}-${VER}-orig ; pwd)` && \
+  patchit $temp
+  fixup $temp
+  cd $temp
+  find . -name "autom4te.cache" | xargs -r rm -rf ; \
   cd ${topdir} && \
-  diff -urN -x '.build' -x '.inst' -x '.sinst' \
+  diff -urN -x '.build' -x '.inst' -x '.sinst' -x '*~' \
     ${BASEPKG}-orig ${BASEPKG} > \
-    ${srcinstdir}/${src_patch_name} ; \
+    ${srcinstdir}/${src_patch_name2} ; \
   rm -rf ${BASEPKG}-orig )
 }
 # Note: maintainer-only functionality
@@ -327,9 +485,13 @@
 }
 spkg() {
   (mkpatch && \
+  cp ${src_patch} ${srcinstdir}
   if [ "${SIG}" -eq 1 ] ; then \
     name=${srcinstdir}/${src_patch_name} text="PATCH" sigfile ; \
   fi && \
+  if [ -e ${srcinstdir}/${src_patch_name2} -a "${SIG}" -eq 1 ] ; then \
+    name=${srcinstdir}/${src_patch_name2} text="PATCH2" sigfile ; \
+  fi && \
   cp ${src_orig_pkg} ${srcinstdir}/${src_orig_pkg_name} && \
   if [ -e ${src_orig_pkg}.sig ] ; then \
     cp ${src_orig_pkg}.sig ${srcinstdir}/ ; \
@@ -376,6 +538,12 @@
     else \
       echo "PATCH signature missing."; \
     fi; \
+    if [ -e ${src_patch2}.sig ]; then \
+      echo "PATCH2 signature follows:"; \
+      /usr/bin/gpg --verify ${src_patch2}.sig ${src_patch2}; \
+    else \
+      echo "PATCH2 signature missing."; \
+    fi; \
   else
     echo "You need the gnupg package installed in order to check signatures." ; \
   fi
@@ -392,6 +560,9 @@
     build) build ; STATUS=$? ;;
     make) build ; STATUS=$? ;;
     check) check ; STATUS=$? ;;
+    check-rpath)        check_rpath ; STATUS=$? ;;
+    check-runtime)      check_runtime ; STATUS=$? ;;
+    check-tools)        check_tools ; STATUS=$? ;;
     test) check ; STATUS=$? ;;
     clean) clean ; STATUS=$? ;;
     install) install ; STATUS=$? ;;
Reply | Threaded
Open this post in threaded view
|

Re: generic-build-script extension to update version numbers in README

Christian Franke
In reply to this post by Igor Peshansky
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

Reply | Threaded
Open this post in threaded view
|

Re: generic-build-script extension to update version numbers in README

Max O Bowsher
-----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:
      getattr(self, directive).append(arg)
    elif type(info[self.I_DEFAULT]) == str:
      setattr(self, directive, arg)
    elif type(info[self.I_DEFAULT]) == bool:
      setattr(self, directive, not info[self.I_DEFAULT])
    elif type(info[self.I_DEFAULT]) == dict:
      items = arg.split(" ")
      if directive == "ExtraFile":
        if len(items) == 1:
          val = os.path.basename(items[0])
        else:
          val = items[1]
      else:
        val = items[1:]
      getattr(self, directive)[items[0]] = val

  def dump_config(self):
    for directive in self.info.keys():
      print >> sys.stderr, "%s: %s" % (directive, getattr(self, directive))

  def read_fp(self, fp):
    for line in fp.readlines():
      line = line.rstrip('\r\n')
      if line and line[0] != '#':
        self.register_option(line)

def main():
  c = PkgConfig()
  opts, args = getopt.gnu_getopt(sys.argv[1:], 'F:')
  for o, a in opts:
    if o == "-F":
      f = open(a)
      c.read_fp(f)
      f.close()
  c.dump_config()
  gbsmunge(c, args[0])

def gbsmunge(c, from_fn, to_fn=None):
  if to_fn:
    to_fp = file(to_fn, 'w')
  else:
    to_fp = sys.stdout

  def out(s):
    to_fp.write(s + "\n")

  for line in fileinput.FileInput(from_fn):
    line = line.rstrip()
    # prologue
    if line == "export BASEPKG=${PKG}-${VER}":
      if c.AlternateTarballStem:
        out("export BASEPKG=" + c.AlternateTarballStem + "-${VER}")
        continue
    elif line == 'export install_docs="\\':
      out(line)
      for i in c.ExtraDocFile:
        out("\t%s\\" % (i,))
      continue
    elif line == "export test_rule=check":
      if c.TestMakeRule:
        out("export test_rule=" + c.TestMakeRule)
        continue
    # unpack
    elif line == '  tar xv${opt_decomp}f "$1"':
      if c.UnpackExclude:
        out("  tar --exclude='%s' -xv${opt_decomp}f \"$1\""
            % ("' --exclude='".join(c.UnpackExclude)))
        continue
    # prep
    elif line == "  mkdirs )":
      if c.PrepCmd:
        for cmd in c.PrepCmd:
          out("  %s && \\" % cmd)
      if c.AutoreconfCmd:
        out("  (cd ${BASEPKG} && \\")
        for cmd in c.AutoreconfCmd[:-1]:
          out("  %s && \\" % cmd)
        out("  %s ) && \\" % c.AutoreconfCmd[-1])
      out("  mkdirs )")
      continue
    # conf
    elif line == '  CFLAGS="${MY_CFLAGS}" LDFLAGS="${MY_LDFLAGS}" \\':
      if c.PreConfigureCmd:
        for cmd in c.PreConfigureCmd:
          out("  %s && \\" % cmd)
    elif line in (
        """  --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}" \\""",
        ):
      if c.NoDefaultConfigureArgs:
        continue
    elif line == "  --datadir='${prefix}/share' )":
      if c.ConfigureArg:
        if not c.NoDefaultConfigureArgs:
          out(line[:-1]+"\\")
        out("  " + " ".join(c.ConfigureArg) + " )")
        continue
      elif c.NoDefaultConfigureArgs:
        out("  )")
        continue
    # build
    elif line == "  make CFLAGS=\"${MY_CFLAGS}\" )":
      # This CFLAGS override can break builds!
      # e.g. neon 0.24.7, knocks out needed -I flag
      if c.MakeTarget:
        for i in c.MakeTarget[:-1]:
          out("  make %s && \\" % i)
        out("  make %s )" % c.MakeTarget[-1])
        continue
      else:
        out("  make )")
        continue
    # install
    elif line == "  make install DESTDIR=${instdir} && \\":
      if c.MakeInstallTarget:
        for i in c.MakeInstallTarget:
          out("  make %s DESTDIR=${instdir} && \\" % i)
      else:
        out(line)
      if c.InstallExtraCmd:
        for i in c.InstallExtraCmd:
          out("  %s && \\" % i)
      if c.ExtraFile:
        for to_f, from_f in c.ExtraFile.items():
          out("  mkdir -p ${instdir}%s && \\" % (os.path.dirname(to_f)))
          out("  cp ${srcdir}/CYGWIN-PATCHES/%s ${instdir}%s && \\"
              % (from_f, to_f))
      continue
    elif line.find("${prefix}/share/doc/${SHORTPKG} ") != -1:
      if c.AlternateShareDocDir:
        line = line.replace("${prefix}/share/doc/${SHORTPKG} ",
            "${prefix}/share/doc/%s " % c.AlternateShareDocDir)
        out(line)
        continue
    # pkg
    elif line == "  tar cvjf ${bin_pkg} * )":
      if c.SubPackage:
        allitems = []
        for tarball, items in c.SubPackage.items():
          allitems.extend(items)
          out("  tar -cjvf \"${topdir}/%s\" %s && \\"
              % (tarball, " ".join(items)))
        out("  tar --exclude='%s' -cjvf ${bin_pkg} * )"
            % ("' --exclude='".join(allitems)))
        continue
    # mkpatch
    elif line == '  mv ${BASEPKG} ../${BASEPKG}-orig && \\':
      if c.AutoreconfCmd:
        out(line)
        out("  (cd ../${BASEPKG}-orig && \\")
        for cmd in c.AutoreconfCmd[:-1]:
          out("  %s && \\" % cmd)
        out("  %s ) && \\" % c.AutoreconfCmd[-1])
        continue
    elif line == "  diff -urN -x '.build' -x '.inst' -x '.sinst' \\":
      if c.NoDiffNewFiles:
        line = line.replace(' -urN ', ' -ur ')
      if c.DiffExclude:
        out(line)
        out("    -x '" + "' -x '".join(c.DiffExclude) + "' \\")
        continue
    # several (conf, build, check, clean, install)
    elif line == '  (cd ${objdir} && \\':
      if c.BuildInSourceDir:
        out('  (cd ${srcdir} && \\')
        continue
    out(line)

if __name__ == '__main__':
  main()

Reply | Threaded
Open this post in threaded view
|

[Patch] g-b-s: New command: upgrade-self. (was: Re: generic-build-script extension to update version numbers in README)

Buzz-4
In reply to this post by Charles Wilson-2
Op Fri, 18 Nov 2005 23:20:25 -0500 schreef Charles Wilson
in <437EA809.30204<at>cwilson.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 2>&1 |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.buzz<at>bavag.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

gbs-update-self.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] g-b-s: New command: upgrade-self.

Christian Franke
Bas van Gompel wrote:

>[...]
>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.
>  
>


I like the idea having some semi-automatic function to update the build
script, but:

- It should be in a separate script

Typing e.g:

  update-gbs package-VERSION.sh

instead of

  ./package-VERSION.sh update-self

is no big deal;-)

Note that "no merge conflict" does not imply "no problem", is does even
not imply "no syntax error".
So your new script may behave interesting, especially if the update-self
function has been updated self;-)

When updating several build scripts, this should be done by the same
current code, not by the possibly outdated and buggy code in the current
script itself.


- It should be possible to update scripts from local directory (like
setup.exe provides)

So the cvs update and merge part should be separate functions.


BTW: why not put g-b-s and such additional support scripts in a package?


Christian

Reply | Threaded
Open this post in threaded view
|

Re: [Patch] g-b-s: New command: upgrade-self.

Buzz-4
Op Tue, 22 Nov 2005 07:53:19 +0100 schreef Christian Franke
in <4382C05F.1030105<at>t-online.de>:
:  Bas van Gompel wrote:

[`upgrade-self' command]
 
:  I like the idea having some semi-automatic function to update the build
:  script, but:

Some IMO's are missing here, IMO. :-|

:  - It should be in a separate script

That is against the general spirit of g-b-s AIUI. The function may
well be moved into a `modules'-file when that materializes, though,
IMHO.

:  Note that "no merge conflict" does not imply "no problem", is does even
:  not imply "no syntax error".

Error-checking may be improved... a test-run, calling ``version'',
perhaps? (SHTDI)
[...]

Worst case: One has to do it the old-fashioned way. (Like it is now.)

:  - It should be possible to update scripts from local directory (like
:  setup.exe provides)

Touch (an existing) /usr/share/gbs/generic-build-script-HEAD for that,
and hope your current version is already there.

:  So the cvs update and merge part should be separate functions.

If you think so. SHTDI

:  BTW: why not put g-b-s and such additional support scripts in a package?

SHTDI


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