This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ITP: Guile 1.5.6

After looking at the build script, I remembered the cross-compiling configuration build kit that Jan(?) developed.
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, 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 co mknetrel

4) the "Method 1" from -- 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...

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."

[agent provocateur]

Nicholas Wourms wrote:


The 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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]