[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: bundled libs

From: Stephen Leake
Subject: Re: [Monotone-devel] Re: bundled libs
Date: Mon, 18 Feb 2008 07:17:12 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.1 (windows-nt)

Markus Schiltknecht <address@hidden> writes:

> Stephen Leake wrote:
>> Windows MinGW is an important platform (because of the number of
>> users), and it has essentially no distribution package manager (just a
>> SourceForge site), and no pcre package at the moment.
> Agreed. And how's the Visual C++ build doing?

I'm not working on that (I don't have Visual C++), but I am working on
a MinGW buildbot. Which will also do Cygwin, I hope. It currently
builds MinGW; now I need to install the actual buildbot stuff.

>> On the other hand, Windows Cygwin is easy to use. On the gripping
>> hand, some people just hate Windows Cygwin.
> Yes, from what I know, it's said to be slow.

Not in my experience. I'm not clear what people's objections are, but I
have run into people who simply refuse to install Cygwin "ever again".
They got burned somehow.

I've had the opposite experience. It turns out Emacs DVC won't run on
some of my team's Windows boxes. I can't figure out what the
difference is between their box and mine! But one solution is to run
Cygwin Emacs on Cygwin XWindows; works fine, and is not noticeably
slower than native Emacs. The hardware is up to running Cygwin these

In addition, mtn sync file: and mtn sync ssh: work on Cygwin, but not
on MinGW.

>> I'm not clear what it would take to contribute a MinGW pcre package,
>> but that does seem like the right approach.
> Well, I'm not only talking about pcre, but also about botan, sqlite
> and lua. Please note that pcre, sqlite and lua all provide some
> windows dlls to download. I'm not sure if these are compatible or
> could be used. 

Ah; that makes sense. I had only checked the MinGW site.

Once I get the MinGW buildbot going, I can try configuring a second
build to use those as "system libs".

> So even if there's no package manager, there are packages. So we
> could maybe simply distribute the monotone win32 binary together
> with the required dlls? Hoping no other program changes those DLLs?
> How does Windows do package management? 

The only thing close to native package management on Windows is the
Microsoft Windows Update service. It pushes security changes, and will
also push other changes if you let it. That is the _only_ user option.
It's designed for people like my mother-in-law, who barely understand
what a mouse does :).

But such people will be using mtn win32 binary installation, if they
use mtn at all. Developers should not mind some manual packaging, as
long as the instructions are clear, and it doesn't change very often.

> How can such a thing even work?

Windows will keep DLLs separate if they are in separate directories.
So putting the DLLs for mtn in the same directory as mtn.exe should be

It helps if the DLLs use a good naming convention, changing the file
name for incompatible updates. Then the two versions can co-exist

> So, maybe it's simpler for us to just bundle what we need with
> monotone. And if we need to do that for windows, we can as well do it
> on net.venge.monotone as a standard procedure and provide the bundled
> variant for Unixen as well.

If we have sufficient resources (ie buildbots and developer time), it
is certainly the best for the widest set of users to have both known
good bundled packages, _and_ the ability to use the equivalent system
lib as well.

If we run out of testing/maintaining resources, I think dropping the
bundled libs (perhaps on a subset of the supported systems?) is better
than dropping the system libs, as long as there is a way to get the
needed libraries on all platforms.

I'm not clear if this last paragraph is talking about bundling DLLs or
source. The current Windows mtn binary installer does bundle DLLs.

-- Stephe

reply via email to

[Prev in Thread] Current Thread [Next in Thread]