[Mingw-cross-env-list] Similarities between Mingw-cross-env, *BSD Ports, and Gentoo Portage

[Volker Grabsch]

Nikos Chantziaras schrieb:
> Off topic:  Just out of curiosity; why didn't you guys use Portage
> for mingw-cross-env? It's pretty much made for exactly this kind
> of usage.

Indeed, the main architecture of mingw-cross-env is heavily
influenced by the ideas of the *BSD Ports system, and also by
the Gentoo Portage system. I tried to provide a similar system
with minimum "meta stuff" and minimum "buerocracy" in the package
files.

The goal was to have a system that can be fully understood and
maintained by a single person, to ensure this project will survive
as long as at least one person engages in it.

(Just some numbers: The main Makefile that contains the whole "ports"
 system has 264 lines, 46 of which don't really count as those are
 just for "make dist". Every package file (src/*.mk) has an "overhead"
 of about 12 lines for checksum, etc.)

Having said that, I'm open to base this project on some well-established
standard code, be it Portage or something else. My biggest fear is
that this would make us less flexible and would add an additional
burden on the individual packages. But maybe I'm wrong and switching
to a standardizes port-system would safe some time and work in the
future. I don't know.

> And it would have allowed USE flags to configure the
> packages when building them ;-)

I could have implemented a similar mechanism in our main Makefile,
but I hesitated for a specific reason: This would mean that we'll
get bug reports from people with with different configurations.

It is often hard enough to reproduce issues where everyone runs
exactly the same (full-featured) build. Allowing that kind of
flexibility would result in bug reports (and the need to invest
time to fix those) for many different configurations. And for what?
Just for saving a few hundred KB in the output *.exe files?

Note tham I'm very aware of the fact the people are doing exactly
that, right now, for whatever reason. They are making private changes
to some package files, and trust "hg pull -u" to integrate those
automatically into newer versions of mingw-cross-env. This is okay
for me, as long as it is clear that they are on their own, and that
bug reports should always refer to an unmodified ("full-featured")
build.

On the other hand, of course it would be much nicer if we were more
flexible and this kind of local changes wasn't needed anymore. However,
encouraging everyone to do so might result in a nightmare. We aren't
a Linux port, we are a win32 cross-compiling port, with lots of patches,
but also some ugly hacks to make everything work. It is a huge difference
if the target platform is your fried (as with most Unix systems) or your
enemy (as with Windows platforms, but I'd also add MacOS X platforms
here, for that matter). Lots of thing do or do not work simply
depending on how you combine things. At least that's my personal
torturous experience. I simply don't know how to handle that with
a fairly small community without limiting flexibility, but I'd love
to hear about alternative concepts of managing projects like this.

Our mailing list has currently 92 members, of which 3-8 people are
active on a regular basis. 33 people contributed at least a patch at
some point. This is pretty good when compared to other Free Software
projects. However, we are very small compared to other software
distributions like FreeBSD, Debian, and Gentoo. That's why we have
I think we have to spare our resources.


Regards,
Volker

-- 
Volker Grabsch
---<<(())>>---