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.
What it tells me is that we have too many ways of doing this. There's
1) "my" way -- the so-called "method 2" from
http://www.cygwin.com/setup.html, which is focused on native building
2) Jan's way -- which is focused on cross-building
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:[EMAIL PROTECTED]:/cvs/cygwin-apps co mknetrel
4) the "Method 1" from http://www.cygwin.com/setup.html -- rarely used
for new packages
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.
Now, all of the RPM-nuts are jumping up and down screaming "RPM! RPM!"
right now -- and the Debian faction is yelling "dpkg! dpkg!". BEFORE
voicing that, please go back and READ the 27,374 threads where this has
been suggested in the past. Here's a summary:
-- setup.exe must be able to install the packages
-- setup.exe is a native windows program
-- therefore, we'd need
+ a native port of rpm, or
+ change our whole modus operandi to a "two-step" procedure;
natively install the "core" packages from regular tarballs -- including
an rpm package -- using a native setup.exe, and then use a different
tool for system maintainance (or 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)
All of these same arguments apply to dpkg. So stop yelling "RPM! RPM!"
or "dpkg! dpkg!" and THINK a bit.
Personally, I don't really like Method 2 -- even though it came about as
a result of discussions between Robert Collins and I, and I use it for
all of my packages. It works -- but it duplicates a lot of code into
every -src package, and there's no way to make a global change in
packaging defaults...What if we decided to follow the LSB and put docu
into /usr/share/doc/ instead of /usr/doc/? Difficult, at present... You
CAN use a method-2-ish script on a cross environment, but not OOB.
Either a method2 script is "tuned" for native building, or it's "tuned"
for cross building. There's really no in-between. (FWIW, I made some
mingw- versions of some of my graphics libs, using method-2 scripts and
a cygwin-host, mingw-target cross compiler. These method-2 scripts only
vaguely resemble the build scripts for the "native" versions of the same
packages. Compare zlib-1.1.4-1 and mingw-zlib-1.1.4-1 (from
cygutils/testing))
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). BOTH need to be heavily documented. And at
present, BOTH are for all intents and purposes unsupported. They do
what their creators want -- it "works for them" -- but...
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. An analogy: it's
kinda like the upstream maintainer ran "configure" for us, and we have
to build with HIS config.h and Makefiles.
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. So, cvs co mknetrel
will give you a whole bunch of shell fragments in the extra/
subdirectory -- one for each of the packages that cgf maintains. Well,
we probably don't want a "central repository" of shell fragments --
those fragments should be federated in the -src tarballs for the
individual packages. There's probably some way to make that work -- but
(a) mknetrel works for what cgf wants (b) he has explicitly said it is
UNsupported for general use.
Then, there's always "the current mish mash works. If it ain't broke,
don't fix it."
--Chuck
[agent provocateur]
Nicholas Wourms wrote:
> Jan,
>
> The config.site doesn't seem right, like not detecting libintl. The new
> gettext (libintl) requires -lintl and -liconv to properly link. Also,
> it seems like you were having trouble with libtool dependency support. I
> recommend deleting "depcomp install-sh mkinstalldirs missing ..." before
> running running automake like this:
>
> automake --add-missing --copy --include-deps
>
> It might be worth your while to briefly pop on that windows machine to
> run configure under the "real" deal. That way you can be sure that
> config.site has the proper variables. However, the autotools are
> supposed to work on cross builds as well, by detecting support in the
> cross directories...
>
> Before you generate a patch, make sure that you remove the side-effects
> of the new autotools. The specific example is the autom4te.cache dir,
> which doesn't need to be distributed.
>
> Chuck, I'm no expert, so you might want to have a look-see at the build
> script to see if there is anything else you notice.
>
> Cheers,
> Nicholas
>
