This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: ITP: Guile 1.5.6
Charles Wilson <cwilson@ece.gatech.edu> writes:
> After looking at the build script, I remembered the cross-compiling
> configuration build kit that Jan(?) developed.
> http://lilypond.org/cygwin/cygwin-cross.tar.gz
> This toolkit was used to generate the guile build script.
Indeed. It's a cardhouse of shell scripts, mainly because when I
started it, almost nothing would compile out of the box, or without
extra flags and settings.
It started as a thing just for myself, to support the lilypond port to
Cygwin, and although it's grown rather robust and tested on several
boxes, it hasn't caught on.
The result is something a bit too specific for cross compilation,
aimed a bit too much at 'make world' (download and build everything
requested), and too flexible (sendmail anyone?).
> What it tells me is that we have too many ways of doing this.
I fully agree, that time has come, esp. with all these contributions,
to try to bundle efforts.
> 3) cgf's way (mknetrel), which is also focused on cross-building (but
> recent reports and changes make it easier to use natively, I think)
> cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/cygwin-apps co mknetrel
I'll have a look at this tomorrow.
> What we *really* need is separate tool that can
> a) automate a lot of this with sensible defaults (how many "method
> 2" scripts have exactly the same conf(), mkpatch(), or spkg()?)
> b) is flexible enough that every step can be overridden, if
> necessary -- because EVERY package is special...flexibility is the
> greatest strength (and greatest weakness) of method2. It can do
> ANYTHING.
> c) is a supported tool
> d) works without major tweaking both natively and in a cross environment.
Maybe
e) is appointed by the great dictator to be 'the one true tool',
and gets patches from everyone.
or is that c.2)?
[snip very interesting summary]
> use setup in a different "mode" where it exec's the cygwin rpm.exe
> -- but this leads to other problems: a cygwin-dependent rpm.exe
> won't be able to update the cygwin package, unless some of the
> 'in-use-replace' magic from the current setup is grafted into rpm)
[althoug this doesn't seem too bad?]
> The two best candidates right now are probably the cross-tool at lilypond, or cgf's mknetrel. Unfortunately, BOTH will require work --
> lilypond's needs to "play better" on native platforms (as does
> mknetrel, but mknetrel is closer).
I'll definately have a closer look at mknetrel.
> BOTH need to be heavily documented.
Yes.
> And at present, BOTH are for all intents and purposes
> unsupported.
Well, I *do* take patches or bug reports.
> Differences:
> Lilypond's tool combines a bunch of stuff at "maintainer package
> creation time" to generate a single, all-in-one build
> script. Downstream folks (the rest of us) only get that one script,
> which was configured for the "real (cygwin)" maintainer's build system
> -- it might not (probably will not) work on our system. Oops.
Yes. This was tossed-in without too much thought, to fulfill the
script requirement. The script is generated at run-time, from
snippets of shell script. For all intents or purposes, you'd want to
run the cross-tool package itself.
> Mknetrel combines stuff at "runtime"; there is no "build script" per
> se. However, the 'stuff' -- shell script fragments and
> default-overrides for each individual package -- are all buried
> within the mknetrel hierarchy, NOT separated out into your build
> area.
This sounds an awful lot like lily's cross tools! I'm appending the
little stale documentation there is on the tools. Possibly, we can
even share snippets, or tricks, and put them in the repository.
Greetings,
Jan.
cross-tools:/INSTALL
By default, the cygwin-x-development environment gets built and
installed in
$HOME/usr/src/cygwin/cygwin-x.y.z
The entry point is
./bin/cygwin-cross.sh
which downloads, builds and installs cross-development tools for
Cygnus' GNU/Windows package (binutils, gcc, flex, bison).
This script is merely a wrapper around a bunch of script-snippets in
./stage. The idea is that while most packages have similar download,
configure, build, install and packaging procedures, any of those
stages could differ and should be easy adjustable for individual
packages.
It all starts with a list of build type: bin, cross and native. For
each of these types, there is a list of build stages:
./stage/<type>.stages
and a list of packages
./stage/<type>.packages
that must be built in that type of build.
Packages of the bin build type are merely downloaded and untarred.
Packages of the cross build type are configured, built, packaged, and
installed for cygwin GNU/Linux to cygwin cross-development. These
tools are used to build the packages of the native cygwin type.
The cygwin-cross.sh script simply walks all build types, and applies
all stages of that type to all packages of that type. Applying a
stage consists of including a script in the ./stage directory. The
script to include has a matching order from specific to generic:
./stage/<package>-<x.y.z>.<stage>
./stage/<package>.<stage>
./stage/<type>.<stage>
./stage/<template>.<stage>
the first script that matches is included, and implements a stage.
Adding a new package
To create a new Cygwin package for package baz from
ftp://foo.org/bar/baz-1.0.tar.gz, with your Cygwin patch
baz-cygwin.patch:
* in stage/native.packages, add 'baz' to packages
* copy your baz-cygwin.patch to ./patches
* in stage/baz.setup: add
archive='ftp://foo.org/bar'
patch='baz-cygwin.patch'
* run
./bin/cygwin-cross.sh
For a Cygwin compliant test package see foo/foo-1.0.tar.gz patches/foo.patch
Jan Nieuwenhuizen
janneke@gnu.org
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org