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:
+
In your source package include the same foo-vendor-suffix.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-vendor-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-vendor-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:
+
+ 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:
+
+ 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-vendor-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:
+
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-vendor.tar.[gz|bz2]: The original source tarball, exactly as downloaded from the original vendor.
+
foo-vendor-release.patch: the patch file as described in Method One, above.
+
foo-vendor-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 tree boffo-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 into boffo-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 it boffo-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 adapt this 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:
+
Binary tar files are named "package-version-release.tar.bz2". They generally contain the executable files that will be installed on a user's system plus any auxiliary files needed by the package. See the making packages section below for more details on how to generate a binary tar file.
-
Source tar files are named "package-version-release-src.tar.bz2". Source tar files should contain the source files, patches and scripts needed to rebuild the package. While installing these files is optional, the inclusion of a source tar file is part of the totality that makes up a Cygwin package and so, these files are not optional. In some cases, there may be multiple packages generated from the same source; for instance, one might have a "boffo" package and its associated shared library in "libboffo7", where both are generated from the same -src tarball. See the making packages section below for more details on the contents of a -src tar file, and the setup.hint section for information on the "external-source:" option.
+
Binary tar files are named "package-version-release.tar.bz2". They generally contain the executable files that will be installed on a user's system plus any auxiliary files needed by the package. See the package contents section below for more details on the contents of a binary tar file.
+
Source tar files are named "package-version-release-src.tar.bz2". Source tar files should contain the source files, patches and scripts needed to rebuild the package. While installing these files is optional, the inclusion of a source tar file is part of the totality that makes up a Cygwin package and so, these files are not optional. In some cases, there may be multiple packages generated from the same source; for instance, one might have a "boffo" package and its associated shared library in "libboffo7", where both are generated from the same -src tarball. See the package contents section below for more details on the contents of a -src tar file, and the setup.hint section for information on the "external-source:" option.
A script runs on sourceware.org which collects information from (currently) the release directory in the ftp download area. Information from subdirectories of these directories is parsed to automatically generate the default setup.ini file which is used by the Cygwin setup program for installation control. If you are responsible for maintaining a Cygwin package, it is important that you understand how this process works.
Note that both packages point to the same -src tarball. Also, it is required that the version strings match (libboffo7-5.2 won't point to boffo-1.4-src). The same logic is used to "match up" prev: and test: versions.
The files paths within both the -src and the binary package files are quite important. Since setup extracts into a predetermined directory, you must structure your package contents accordingly.
The following requirements avoid problems that have occured in the past with packages. Thus only skip them if you *know* your package will not recreate that prior problem.
All executables in your binary package are stripped (run 'strip' on them). Some makefiles have a install-strip command you can use to do this automatically when you setup your 'installed' tree.
-
Source packages are extracted in /usr/src. See the Package Source section for more information.
-
In your binary package, you may choose to include a file /usr/share/doc/Cygwin/foo-vendor-suffix.README containing (at a minimum) the information needed for an end user to recreate the package. This includes CFLAGS settings, configure parameters, etc.
-
In your binary package include a directory /usr/share/doc/foo/ that includes any binary-relevant vendor documentation, such as ChangeLogs, copyright licences, READMEs etc.
-
If you are not creating your package from an installed virtual root, be sure to check that the file permissions are appropriate.
-
If the package has any global settings (i.e. in files in /etc) that are not overrideable on a per user basis (sshd, as a daemon, is an example of this) do not include the relevant config files in your package. Instead include in your post-install script to install the settings files. Be sure that if you would overwrite an already present file that the user is offered the choice of keeping their own or overwriting with your defaults.
-
Ensure that your package handles binary only systems, textmode only systems, and hybrid systems correctly.
There are three accepted ways to package the 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:
+
All executables in your binary package are stripped.
+
Source packages are extracted in /usr/src (so the paths in 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 tarball minus the -src.tar.bz2 part:
Generally, this will contain the original source tarball, exactly as downloaded from the original vendor, any needed patch files, and a
+ cygport script that drives the packaging process.
-
In your source package include the same foo-vendor-suffix.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-vendor-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-vendor-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:
-
- 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:
-
- 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-vendor-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:
-
In your binary package, you may choose to include a file /usr/share/doc/Cygwin/foo-vendor-suffix.README containing (at a minimum) the information needed for an end user to recreate the package. This includes CFLAGS settings, configure parameters, etc.
+ (You can adapt this generic README.)
+
In your binary package include a directory /usr/share/doc/foo/ that includes any binary-relevant vendor documentation, such as ChangeLogs, copyright licences, READMEs etc.
+
If you are not creating your package from an installed virtual root, be sure to check that the file permissions are appropriate.
+
If the package has any global settings (i.e. in files in /etc) that are not overrideable on a per user basis (sshd, as a daemon, is an example of this) do not include the relevant config files in your package. Instead install the files into /etc/defaults and include in your post-install script to install the settings files. Be sure that if you would overwrite an already present file that the user is offered the choice of keeping their own or overwriting with your defaults.
+
Ensure that your package handles being installed on binary and text mounts correctly.
-
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-vendor.tar.[gz|bz2]: The original source tarball, exactly as downloaded from the original vendor.
-
foo-vendor-release.patch: the patch file as described in Method One, above.
-
foo-vendor-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 tree boffo-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 into boffo-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 it boffo-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 adapt this 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:
-
Finally, rebuild the whole thing (you're still in /tmp):
+
+
While you could make a package satisfying these requirements by hand, the
+accepted way to make Cygwin packages is using the cygport tool, which
+automatically handles most of the above issues for you.
The cygport framework improves
+on previous Cygwin build scripts, and
+borrows concepts from the Gentoo portage system.
+
+
Suppose that the vendor's boffo-1.0.tar.bz2 source tarball, that you
+downloaded from the boffo homepage, unpacks into boffo-1.0/.
+
+
Further, suppose you've got "boffo" ported to Cygwin. It took some work, but
+you've got a patch file, which we will name boffo-1.0-1.src.patch, and
+with that applied 'boffo' builds and runs.
+
+
All that remains is to write a 'boffo.cygport' file which
+will describe how to unpack, configure, build and package:
+
-./boffo-1.0-1.sh all
+# package name
+NAME="boffo"
+VERSION=1.0
+RELEASE=1
+
+# setup.hint generation
+CATEGORY="Games Text"
+SUMMARY="A whackamole simulation in ASCII art"
+DESCRIPTION="A whackamole simulation in ASCII art.
+Intended for use on VT100 terminals at BAUD rates 1200 and
+above. Uses arrow keys for positioning over moles. Space
+bar whacks the mole.
+No actual moles will be harmed during execution of this game."
+REQUIRES="libncurses6"
+
+# source and patch files
+SRC_URI="http://boffo.org/downloads/${P}.tar.xz"
+PATCH_URI="boffo-1.0-1.src.patch"
+
+# use the standard src_compile, src_install and src_test
- (Or, you may want to do each step in 'all' manually: prep, conf, build, (check), install, strip, pkg, spkg, finish.
-
-
-
-
-
Method Three: cygport
-
The technique of method two became popular to many maintainers, however it suffers from a number of drawbacks when applied on a wide scale. The cygportREADME explains a number of these problems.
-
The cygport framework is a response to these issues, and borrows concepts from the Gentoo portage system. It separates the g-b-s into a small file containing the package-specific parts and moves the main script infrastructure into shared files. For more information on using cygport consult the documentation and sample port files.
-
Source packages created with cygport have a similar structure to those created with method two, except that they contain a 'boffo-1.0-1.cygport' file in place of the 'boffo-1.0-1.sh' script. The binary package is built by running 'cygport boffo-1.0-1 all' instead of './boffo-1.0-1.sh all', and so on for prep, compile, package, finish, etc.
+
+
The source and binary packages can then be built and setup.hint generated by running 'cygport boffo all'.
+
+
For more information on using cygport consult
+the man page,
+README, documentation
+and sample .cygport files.
If your package requires certain commands to be executed after the files in the package are installed, include them in a file in the package called /etc/postinstall/package.sh or /etc/postinstall/package.bat.
If the file's name ends in ".sh", it is executed with the Cygwin shell; if it ends in ".bat", it is executed with the DOS command interpreter. If it doesn't end with either of these suffixes, it is ignored.