Cygwin
Get that Linux feeling - on Windows
Historical Cygwin Packaging
While older, hand-made packages exist, the only accepted way to make a new
Cygwin package is using the cygport tool, which automatically handles most
packaging requirements and issues for you. It is also strongly recommended to
convert existing packages to cygport when updating them; ask on
the cygwin-apps
list if you need help converting an existing package to
use cygport.
Package Source
There are two previous ways of packaging source code for Cygwin packages.
Method One
-
Source packages are extracted underneath /usr/src (so your -src tarball should not include /usr/src). On extraction, the tar file should put the sources in a directory with the same name as the package tar ball minus the -src.tar.bz2 part:
boffo-1.0-1/Makefile.in boffo-1.0-1/README boffo-1.0-1/configure boffo-1.0-1/configure.in etc...
- In your source package include the same foo-version-release.README as used in the binary package.
- Your source package already be patched with any necessary Cygwin specific changes. The user should be able to just ./configure; make; and go.
- Include a single file foo-version-release.patch in your source package, that when applied (in reverse: 'patch -R') will remove all the patches you've applied to the package, leaving it as the vendor distributes it. This file should extract as :
/usr/src/foo-version-release.patch
(that is, since setup extracts everything into/usr/src
, the patch should be a "top level" member of the -src tarball.)
Optionally, this patch could also unpack inside the source tree:boffo-1.0-1/README boffo-1.0-1/configure boffo-1.0-1/CYGWIN-PATCHES/boffo-1.0-1.patch etc...
However, that tends to complicate actually creating the patch itself. Unless one enjoys recursion, one must move the .patch file OUT of the source tree, regenerate the patch to incorporate any new changes, and then copy the new patch back into .../CYGWIN-PATCHES/. This option is documented because some existing packages do it this way, but it is not recommended for new packages. Make boffo-1.0-1.patch a top-level member of the -src tarball instead:boffo-1.0-1.patch boffo-1.0-1/README boffo-1.0-1/configure etc...
To create the patch file described above, you might rundiff -Nrup vendor-src-dir patched-src-dir > foo-version-release.patch
To apply the generated patch (in reverse; that is, to remove the Cygwin specific changes from the unpacked -src tarball) the user would run (from within the source tree)patch -R -p1 < ../foo-version-release.patch
- In general, any Cygwin-specific "packaging" files -- such as cygwin-specific READMEs, a copy of the setup.hint file for your package, etc. -- should unpack within a /CYGWIN-PATCHES/ subdirectory in your sources. Naturally, applying the patch (in reverse, as described above) would remove these files from the source tree.
- So, returning to the boffo example, boffo-1.0-1-src.tar.bz2 would contain:
boffo-1.0-1.patch boffo-1.0-1/README boffo-1.0-1/configure boffo-1.0-1/configure.in boffo-1.0-1/Makefile.am boffo-1.0-1/Makefile.in boffo-1.0-1/boffo.c ... boffo-1.0-1/CYGWIN-PATCHES/boffo.README (Cygwin-specific) boffo-1.0-1/CYGWIN-PATCHES/setup.hint ...
Method Two
This method is sometimes referred to as the "g-b-s" method, after the filename of the generic-build-script
template.
- In a packaging technique inspired by rpms and debs, you may create a -src tarball which simply contains:
foo-version.tar.[gz|bz2]
: The original source tarball, exactly as downloaded from the original vendor.foo-version-release.patch
: the patch file as described in Method One, above.foo-version-release.sh
: A build script that drives the entire unpacking, configuration, build, and packaging (binary and -src) process.
- You can adapt this generic readme file for script-driven -src packages.
- Here is an example build script which can be adapted for your package. By carefully modifying the details of this script, it can create the binary and -src packages for you, once you've finished porting your package. How? See the Initial packaging procedure below. But first, a few facts:
- The buildscript will autodetect the package name, vendor version, and release number from its own filename.
- When the buildscript is used to compile the package, all building occurs within a hidden subdirectory inside the source tree:
boffo-1.0/.build/
- To create the binary package, the script redirects 'make install' into a hidden subdirectory
boffo-1.0/.inst/
, creating a faux treeboffo-1.0/.inst/usr/bin
, etc. This faux tree is tar'ed up into the new binary package. - To create the -src package, the script generates a patch file, and copies the original tarball, the patch, and the script into yet another hidden subdirectory
boffo-1.0/.sinst/
. The contents of this subdirectory are tar'ed up into the new -src package. - Sometimes, you will find that a package cannot build outside of its source directory. In this case, the script must recreate the source tree within the
.build
subdirectory. The jbigkit -src package uses GNU shtool's mkshadow to do this. generic-build-script
is not a one-size-fits-all solution. It must be customized for your package.
-
Initial packaging procedure, script-based
- Suppose you've got your boffo package ported to Cygwin. It took some work, but it now builds and runs. Further, suppose that the
boffo-1.0.tar.bz2
file that you downloaded from the boffo homepage unpacks intoboffo-1.0/
, so you've been doing all of your work in~/sources/boffo-1.0/
. That's good. - Place a copy of
boffo-1.0.tar.bz2
in~/sources
- Copy
generic-build-script
into~/sources/
and rename itboffo-1.0-1.sh
. Carefully adapt this script for your purposes. However, it should auto detect most of what it needs to know: the package name, vendor version, release number, etc. - Clean up inside your
~/sources/boffo-1.0/
directory -- make sure that no files which are generated during the build process are lying around. Usually, a 'make distclean
' will do the trick, but not always. - Ensure that you've put any Cygwin-specific readme files, setup.hint files, etc, into
~/sources/boffo-1.0/CYGWIN-PATCHES/
. You can adaptthis generic readme file
for this purpose. The build script expects that the Cygwin-specific README file will be named.../CYGWIN-PATCHES/<package>.README
. In this example, it would be stored as~/sources/boffo-1.0/CYGWIN-PATCHES/boffo.README
. The build script will ensure that it gets installed as/usr/share/doc/Cygwin/boffo-1.0.README
- Prepare the staging location for the -src package (yes, do the -src package first): From the directory above your boffo-1.0 tree (e.g.
~/sources/
in our example) execute './boffo-1.0-1.sh mkdirs
' - Create the -src package: '
./boffo-1.0-1.sh spkg
' - Now, let's go somewhere else and unpack this new -src package:
cd /tmp tar xvjf ~/sources/boffo-1.0-1-src.tar.bz2
- Finally, rebuild the whole thing (you're still in /tmp):
./boffo-1.0-1.sh all
(Or, you may want to do each step in 'all' manually: prep, conf, build, (check), install, strip, pkg, spkg, finish.
- Suppose you've got your boffo package ported to Cygwin. It took some work, but it now builds and runs. Further, suppose that the