Markus Schiltknecht <[EMAIL PROTECTED]> 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 days. 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 enough. It helps if the DLLs use a good naming convention, changing the file name for incompatible updates. Then the two versions can co-exist peacefully. > 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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
