* 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/