Cygbuild - A Porting tool for making Cygwin Net Releases

Links and download

Main project page (never changes; bookmark this one)
Manual
Developer information
ChangeLog Generated by editing the code in Emacs and pressing key binding (C-x 4 a). http://git.savannah.gnu.org/gitweb/?p=cygbuild.git;a=blob;f=ChangeLog;hb=devel
Official Cygwin setup format and Package Contributor's Guide

What is Cygbuild?

Cygbuild is something like Debian dh_make(1) .deb or rpm(1) .rpm maker utility, but for Win32 Cygwin platform. This is just an analogy and you can read more details from the disclaimer below.

If you are familiar with .deb or .rpm making or Activestate Perl .ppm and .ppd files, the Cygwin Net Release packaging is just another variant of these existing packaging methods. The process is quite straight forward: one must mirror whole system directory structure where the files would go, place the files in the correct directories and finally wrap all aup into a single package package-NN.NN-RELEASE.tar.bz2. The end user installs this premade Cygwin Net install tar package at system root /. In a nutshell this is roughly the methodology of making Cygwin Net Releases. For more information, refer to Cygwin Package Contributor's Guide

Normally the porting process starts by downloading some Unix or Linux package that would be nice to have under Cygwin as well. So the porter must:

Unpack package (tar -zxvf *tar.gz)
Configure it (./configure)
Build it (make all). This is where the porting may stuck and some other Cygwin related work may need to be done before package can be contributed. Perhaps you need download more libraries befofore compile can finish. And this means that you need to port extra libraries first to Cygwin ...
If the Makefile does not use install(1), the porter must modify Makefile or make his own install method. The culprit is many times the cp(1) command that is used in Makefiles to copy files to install location. The correct way is to use program install(1) Here the porter's experience is needed.

All of these steps can be automated in a certain degree at least for Unix/Linux packages that use standard packaging shemes. These packages are:

Standard GNU packages (./configure ; make prefix=.... install)
Debian .orig.tar.gz packages
Library packages (lib*.a etc). Cygbuild contains command 'package-devel' for these.
Standard Perl packages that use Makefile.PL
Standard Python packages that use setup.py

If the standard build commands cannot be used (./configure; make all test install), it is possible to use custom shell script files, which the porter can tweak. The manual page will explain this in detail, so see link at the top of page for further details and read section Optional external scripts.

What are the benefits of using Cygbuild?

There is a generic bourne shell example script (usually referred as g-b-s) in Cygwin's Package Contributor's Guide It can be used for maintaining a Cygwin Net Release. Cygbuild has been evolved from it and combines "Method One" and "Method Two" and adds "Method three++" (automation). The benefits of using Cygbuild are:

You do not have to modify or write separate installation script to every package you are porting.
Cygbuild can can generate the build script over and over; every time you port a new version of some package.
To start porting the package, the templates are automatically populated under directory CYGWIN-PATCHES/. The only need is to fill in and activate the ones needed.
If package does not provide manual page(s), it is simple matter of filling in the manual page template which is in readable Perl POD format. No need to master cryptic nroff(1) formats. User contributed manual pages are automatically installed from directory CYGWIN-PATCHES/.
The detection of packaging type (Perl, Python, Library, Stripping of *.exe *.dll etc.) is all automatic.
There is check command that helps verifying the install and package integrity for e.g.: missing manual pages, incorrect package.README file content, missing library dependencies in setup.hint etc.
It is possible to delegate custom or difficult configuration options to user written external scripts. This provides modularised way of handling difficult ports.

Disclaimer

The references to .deb and .rpm are actually a bit misleading, but they hopefully give some directions to what is sketched in this project. This project has evolved from the existing generic build script; some things needed improvements, the langauge was changed to bash, Perl was added, 5000+ more lines were coded; it just took off while doing porting work. The goal is practical: to make porting and maintenance of ports as easy as possible - with added automatisation and smart code base with high level languages like perl, python, ruby; please step in to propose your porting experience and your tools.

A person who is interested in porting software to Cygwin uses any tools he sees fit to make the port to happen. Most of the Cygwin application maintainers use some versions of the generic Bourne Shell script as a starting point. That suits to simple porting tasks, but usually requires keeping the script up to date for each new version. Many write additional tools and shell scripts which they use to maintain packages they contribute.

This project aims to help making the porting more automatic and maintaining it in the long term. Cygbuild's core is basicly the same as in the original Bourne Shell script, but with lot of enhancements and external modularity. It's written in Bash, which provides more programming rope than Bourne shell.

Whether a potential new Cygwin porter find Cygbuild's approach too complex at the porting task at hand, he might consider using the generic Bourne Shell script. But most likely the appetite grows and he may soon be porting projects A, B, C, D, E, F, and versions A-1, A-2, A-3, B-1, B-2, ... which mean more maintenance work for all of them when new versions appear. That may eventually become a big and time hogging task to manage if done manually for each package. Even if the ported wrote additional helper scripts, it is not guaranteed that other porter could adapt to them easily in case where porter ceases to maintain the port.

Cygbuild is single utility to handle all subsequent version updates easier and to keep them ported with minimum of efforts. The porting tasks are done in standard and predictable manner. The module structure allows using using external helper scripts (where needed) to provide reproducible results even if the maintainership of a port switches to a new person. Handing over a Cygbuild managed port to another person requires no additional learning of user's private scrips or his directory structure layouts, environment variable settings etc.

Cygbuild tries to help the port to happen in matter if minutes while keeping the maintenance cost at minimum. It is hoped that over the time, the added automatisation and experiences from different ports will help to produce a tool, which will take the unnecessary routine tasks off the porter's shoulders.

Install from Version Control

To download and install sources from development tree with git (see link "the tutorial" for quick guide). A directory cygbuild will appear after cloning.

        git clone git://git.savannah.nongnu.org/cygbuild.git
        cd cygbuild
        git checkout --track -b devel origin/devel
        make install-symlink

	... to get new updates from time to time
        git pull

Contact

There no mailing list for the project. Contact maintainer as needed by including "cygbuild" in the subject (otherwise message may be classified as spam by the filters). Report problems to bug tracker. In order to use trackers, a Savannah account is needed.

All files in this project are licensed under GNU GPL.

This project, as well as many other opensource projects, is hosted by Savannah.

W3C validated.