Re: cygbuild as build script

[letters at hotpop dot com (Jari Aalto+mail.linux)]

* Mon 2004-01-26 Igor Pechtchanski <pechtcha <AT> cs.nyu.edu> list.cygwin-apps
* Message-Id: <Pine.GSO.4.56.0401260846510.16692 <AT> slinky.cs.nyu.edu>
| On Mon, 26 Jan 2004, Jari Aalto+mail.linux wrote:
| 
| Perhaps we could, in addition to (or, hopefully, even instead of) offering
| a new package, merge some of the features people deem useful from cygbuild
| into the generic-build-script?  That way, we have a more-or-less
| standardized way of building packages, and reviewers don't have to learn a
| new build system every time they look at a Method 2 package.  You're
| welcome to use whatever build script you want, of course, but keep in mind
| that anyone reading <http://cygwin.com/setup.html> will be pointed to the
| generic-build-script first.  ATM, I'm willing to look at small-ish (read:
| incremental) or trivial (e.g., whitespace, or global search-and-replace)
| patches -- perhaps later, when I have some more time, I'll consider more
| advanced ones.

The issue is deeper than that. cygbuild is an evolution from the
standard build script, so I'm afraid the features can't be
backported. See the documentation at sourceforge or get the code from
CVS. The project is not mature yet, but I hope I can squeeze the bugs
and make it more user friendly. In short:

    - I rewrote all in hope to get more things automated. It just
      took off from there.
    - Changed language to bash
    - Added external Perl library to give more rope, when bash and sed/awk
      started to look too complex. E.g. automated package.README file 
      update. Perl is good at editing content.
    - Template based extensions for difficult ports. Extendable by
      user scripts.
    - Perl program packages is supported in some extent
    - Python packages for Cygwin could be automated too.
    - Coming: automated CVS builds and checkouts. That is, if you monitor
      a project through CVS, you can make snapshot releases, like in Debian.
    
Cygbuild is in fact an "extendable environement" to the direction
where making and maintaining a port should be done with minumum
of effort. If it can be automated, it can be put to cygbuild.

DIFFERENCES IN USAGE

I don't think there is extra learning for testers compared to standard
Method 2 package. The result script is invoked similarly giving the 'all'
or 'pkg' or 'spkg' parameters.

For packagers, that would like to try cygbuild, yes - that requires a
little learning. For basic ports you only need one rule: all packaging
must happen inside source unpack directory:

    foo-1.1/

Here is example of quick OOTB port described at the start of the manual:

       CASE A) To build Cygwin Net release from a package that includes a
       standard "./configure" script, the quick path for porting would be in
       the fortunate case as simple as running commands:

           $ mkdir -p /tmp/build && rm /tmp/build/*
           $ cd /tmp/build
           $ cp package-NN.NN.tar.gz .
           $ tar zxvf package-NN.NN.tar.gz

           ... source has now been unpacked, go there
           ... It's mandatory that the unpack directory uses "package-NN.NN"
           ... version scheme for this utility to work. If not, read the
           ... topic 'Packages with no version number' how to continue porting.

           $ cd /tmp/build/package-NN.NN

           ... now, see if automatic build works, run commands in order below.
           ... If this is your first port, it's better to run commands
           ... individually and spot the problematic part at hand.
           ... In case this is "routine port", you can use command [all].

           $ cygbuild.sh makedirs
           $ cygbuild.sh files
           $ cygbuild.sh configure
           $ cygbuild.sh make
           $ cygbuild.sh strip
           $ cygbuild.sh install
           $ cygbuild.sh -r 1 package
           $ cygbuild.sh publish


For difficult ports the issue is different. If there are blind spots,
I'd be happy to put more documentation to those parts.

Jari

-- 
http://tiny-tools.sourceforge.net/
Swatch @time   http://www.mir.com.my/iTime/itime.htm
               http://www.ryanthiessen.com/swatch/resources.htm
Use Licenses!  http://www.linuxjournal.com/article.php?sid=6225
Which Licence? http://www.linuxjournal.com/article.php?sid=4825
OSI Licences   http://www.opensource.org/licenses/