coapp-developers team mailing list archive

[Philip Allison <mangobrain@xxxxxxxxxxxxxx>]

On 9 April 2010 17:28, Elizabeth M Smith
<emsmith@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> One thing that you're not addressing here is code.  So you maintain a
> project, and you maintain it for windows.  You do the work to make sure it
> compiles on windows and works on windows and doesn't need changes.
>
> Thank you! (A million times, it's great to see projects that care)
>
> Unfortunately you are the minority.
>
> What "shallow forks" help solve are projects that DON'T maintain for
> windows.
> Projects who don't care.
> Projects who don't have the developers who know Windows.
> Projects who don't have the tools to develop for Windows.
> Or don't want to learn the windows API - who expect windows to work exactly
> like unix or linux.
>
> So while I would love to say "leave such work to be done by people who
> really know the code they're trying to build" that is simply not feasible
> for every project.
>
> And while the goal would be to push fixes and things upstream to developers
> - like package maintainers do for linux distributions - the bottom line is
> not all open source projects take windows patches.
>
> How would you address those issues without shallow forks?

I accept your points, and indeed, shallow forks are not entirely
without merit.  I tend to use Gentoo Linux on my own development boxes
- a great divider of opinions, but in my experience, it certainly
makes for a great development environment: if you install a library,
you get the header files, and optionally the documentation as well,
instead of splitting packages into end-user and development versions.
The toolchain used to build it also gets installed (well, on an
already-working system, chances are it's already there), as it is a
build-time dependency, and you generally end up with everything you
need to start developing an app which uses that library.

I see some parallels between the goals of Gentoo package management
and the bullet points on the "What is CoApp?" wiki page, excepting of
course that Gentoo's aim is generally to produce binaries on the
user's box for the user's box, not to distribute those binaries.  As
with all distributions, sometimes an upstream project just doesn't
build right - build tools haven't quite been used in a standard way,
or the build scripts are a bit stale and don't quite work with the
current installed version of the build tools, so on and so forth - so
a lot of packages end up having a patching stage, sometimes with
Gentoo-specific patches, sometimes with patches shared with other
distros (Debian and Ubuntu spring to mind).  Sometimes the problems
get fixed upstream in future versions, sometimes not.  There's nothing
wrong with this.

My point is that sometimes these patches change the code, and
sometimes these patches tweak the build system, but I've never seen a
package outright replace the upstream build system.  MinGW is popular
because it allows, with admittedly fairly steep set-up costs, a
project to have one build script that covers both Windows and UNIX -
because the same toolchain is used on both.  This obviously isn't 100%
compatible with CoApp's goal of using a Microsoft toolchain - which
isn't necessarily a bad thing, just a *different* thing.  Unless the
plan is to port the autotools to the CoApp environment and make the
Visual Studio tools command-line compatible with GNU make, GCC, ld,
etc. - which would be absolutely awesome IMHO, but I get the feeling
that's *not* the plan, hence my questions. :)

Regards,
Phil