This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: [PATCH]: mknetrel builds Guile #3: libtool
Nicholas Wourms wrote:
Let keep the conversation about building a cross-compiler automatically
going. I think CGF is being rather stubborn about it and doesn't see
the potential benefits for the end user.
No need to be confrontational, Nicholas...
What probably should happen is
the build cross environment script should be in a separate cvs tree and
maintained apart from mknetrel. When things get properly situated, then
we could release a package that contains these scripts for people to
download and use as they see fit. Perhaps that could be build method #3.
You're probably talking about a linux/solaris/hpux/whatever "package"
that consists of all of the cross compiler bits for a cygwin-target
environment.
Why does this need to be driven by mknetrel?
Sure, I see that mknetrel needs to *work* within that linux-host,
cygwin-target environment -- but there is no reason why the environment
itself should be created by mknetrel.
Seems like, if you *really* want to do this, the "right answer" is to
use the native packaging tools on the HOST platform -- that means rpm or
dpkg or whatnot.
OTOH, *personally* I don't care one way or the other -- I don't use a
cross-hosted environ. It's cgf's personal project which he has
graciously made available, and it is intended for a very specific
purpose: building packages that will be installed on *cygwin*. Not
building packages that will be installed on <insert fav unix>, that
themselves will be used to build cygwin packages.
Since it's Chris's project, he can set the goals/scope of the project as
narrow or as wide as he likes; and given that the other platforms have
better native tools to do exactly what you want, shouldn't all this
effort be focused on making a better .spec file for
gcc-linuxHcygwinT-3.1.0-i686.rpm? or dpkg or whatnot?
--Chuck