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]

mknetrel for president

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

  * optionally download latest source version.
  * setup (configure, build, install, package) cross building environment.
  * creation of cygwin packages, by cross building on linux.
  * set of functions for each stage (configure, make, install) etc.
  * each stage of each package can be overridden by using a more
    specific shell snippet
  * configure, build, package src and binary package.
  * recreate actual (think autotools etc), patch by diffing against
    pristine sources.
  * create [cross] build script that has effectively been used, by
    glueing all shell snippets together.
  * mirror essential parts of cygwin distro.
  * generate setup.ini.
  * bit barok (lots of history in it), flexible and configurable.

Looking at mknetrel, there are two things that I really miss from my
self-centered pov:

  * setting up the cross building environment.
  * downloading, untarring and patching of latest, pristine sources (for
    stuff that hasn't yet gone into Cygwin), and

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.

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
duplicating efforts.

I've done some random qad hacking at mknetrel, as if it were my own,
to enable packaging guile with it; patch is attached.

What I'd like to add also, is the auto-generation of a Cygwin build
script.  That should be not too hard; fix mknetrel up for native
Cygwin builds, move all functions out of mknetrel, and replace
mknetrel's command line parsing with a simple 'what=$base' statement
or so.

Chris, I don't expect you to apply this patch like it is, but am rather
posting it to get some comments about what you think and where
to go, eg, I can imagine that you want to keep the `importing' of new
sources in a separate tool.  Also, part of the package splitting
options I added may be a bit too simplistic, and too specific for
guile; and you may want to move that back into extra/guile.



1) cvs co mknetrel

Attachment: pats
Description: mknetrel patch

Jan Nieuwenhuizen <> | GNU LilyPond - The music typesetter       |

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