This is the mail archive of the
mailing list for the Cygwin project.
Re: mknetrel for president
- From: Christopher Faylor <cgf at redhat dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 7 Jul 2002 22:38:56 -0400
- Subject: Re: mknetrel for president
- References: <firstname.lastname@example.org>
- Reply-to: cygwin-apps at cygwin dot com
On Mon, Jul 08, 2002 at 03:05:54AM +0200, Jan Nieuwenhuizen wrote:
>Hi Chris [and other mknetrel hackers],
>Today, I had a look at mknetrel 1). I think it's great, and it indeed
>looks a bit like the cygwin-cross tools 2).
>A very short overview.
> * creation of cygwin packages only, by cross building on linux.
It's not just for cross building on linux. It can be used anywhere.
> * set of functions for each stage (configure, make, install) etc,
> and between stages.
> * each package can override any of these functions with its own.
> * configure, build, package src and binary package.
> * rather simple, specific and lightweight.
>Looking at mknetrel, there are two things that I really miss from my
> * setting up the cross building environment.
There should be little, if any cross build environment to set up. You
either have the cross compilers or you don't.
> * downloading, untarring and patching of latest, pristine sources (for
> stuff that hasn't yet gone into Cygwin), and
One tool, one job. Hmm. Where did I hear that before?
>Now, I seem to remember that Chris posted a real easy way to setup the
>cross building environment from CVS [but I can't seem to find that
>now], and the other feature I added to mknetrel today.
I don't know what you mean by "cross build environment". If you want
to build on linux you have to build a compiler and a linker. There's
no getting around that. Otherwise, just build on cygwin itself.
Also the purpose of mknetrel is to absolutely, positively minimize
the amount of patching that is required. I've only found the need
to actually patch a few packages, usually when generic use of
things like automode.o wasn't sufficient.
Usually, the seeding of config.cache files manages to get around just
about every other requirement for patching.
>Anyway, all in all, there's not too much difference, so I think that
>mknetrel looks a good way to go, esp. because it's simple and contains
>a lot less legacy stuff, and mostly because it's silly to keep
>I've done some random qad hacking at mknetrel, as if it were my own,
>to enable packaging guile with it; patch is attached.
If you want to submit these as individually contained patches, I'll take
a look at them. Otherwise, there is the generic problem with monolithic