As a general rule, CrossWire develops software. We don't primarily compile that 
software and distribute binaries.

My intention is for the software we develop to run on as many platforms as 
possible. We have a ton of effort in the cross-platform engine (which does a 
large part of the work for each utility shipped with the engine) to run on 
Windows (usually the outlier these days with MacOS switching to a BSD-based 
system).

I personally own compiling and bundling an installer for Windows for The SWORD 
Project for Windows frontend. I do not include the utilities with this 
frontends and it is usually behind a few versions on its engine anyway. It 
doesn't get a new release often and the next release will probably be a major 
update from RTF to HTML render output (though I've said that for years).

So:

1) I don't know of anyone who personally owns compiling binaries of the SWORD 
engine utilities for Windows. Greg has graciously done it a few times when 
asked.

2) The utilities are maintained in trunk, not in a stable branch; i.e.,  don't 
go through the formal process of freezing ABI compatibility and issuing bug 
fixes for the utilities. Thus the utilities need to be built from trunk to get 
the lastest and this is what we use for building modules we release.

Because of these two things and the background information above, it can be 
said that we don't support distributing Windows binaries of the SWORD engine 
utilities. We don't support distributing any binaries of the utilities.  We're 
not picking a fight with Windows.

If you want to run your own module repository and build all your own modules on 
Windows, then I would suggest downloading a free compiler and learning to 
compile trunk from SVN. But if you're running your own module repo, we have no 
say over the policies that you choose. Use the last Windows binary set of the 
utilities you find on CrossWire. All we're saying is that no one has stepped up 
to own compiling and testing binaries of the utilities for Windows. And this 
would be a daunting task as they don't have regular release cycles; they change 
in trunk and when they change they are considered the latest version.

Hope this clears up a bit.

Troy


On December 30, 2017 6:35:44 AM MST, DM Smith <dmsm...@crosswire.org> wrote:
>I’m wondering if using Docker would be a good solution. 
>
>— DM Smith
>From my phone. Brief. Weird autocorrections. 
>
>> On Dec 30, 2017, at 4:05 AM, David Haslam <dfh...@protonmail.com>
>wrote:
>> 
>> Thanks everyone for disparaging those of us using Windows.  ;>}
>> 
>> I've been building modules for years with the Win32 tools, and barely
>encountered any problems attributable to the utility itself.
>> Nearly all the problems that arise in module development are due to
>getting things wrong in the OSIS XML or in the .conf file.
>> 
>> osis2mod.exe just works!
>> 
>> As do all the other Win32 utilities (though there are a few I've
>never had cause to try).
>> 
>> If you're a regular Windows user, and all your other useful software
>is in Windows,
>> it's just not sensible to expect folk to jump ship to Linux merely
>for building and testing modules.
>> 
>> Of course, that doesn't mean that when we submit a fully tested
>module along with its source text and .conf file
>> that the Linux users in the modules team never introduce their own
>new bugs, does it?
>> 
>> Best regards,
>> 
>> David
>> 
>> Sent with ProtonMail Secure Email.
>> 
>>> -------- Original Message --------
>>> Subject: Re: [sword-devel] Win32 sword utilities for SWORD release
>1.8.0 ?
>>> Local Time: 30 December 2017 7:05 AM
>>> UTC Time: 30 December 2017 07:05
>>> From: ref...@gmx.net
>>> To: sword-devel mailing list <sword-devel@crosswire.org>
>>> 
>>> Couple of points.
>>> 
>>> A casual module developer does not need any of the utilities at
>their most up to date as we would not accept a module, but only a
>source text. So, as long is the OSIS etc is right, the rest is my
>concern as the module upload person.
>>> 
>>> Someone who wants to do heavy lifting and on a regular basis should
>usually go a direction which is well-known to work. They should not
>rely on tools which are maintained with little commitment. I.e. they
>should use Linux. Even if someone (else) successfully learns to compile
>on or for Windows, this is not the same as us having a commitment to
>maintain Windows versions. We do not have that commitment and moaning
>about it does not change this.
>>> 
>>> For your environment, John, the simplest I can suggest would be to
>move the module building onto the Linux server, instead of learning to
>crosscompile. The way I would do that if I was tied to Windows
>workstations is to install the module utilities on the server and use
>git hooks to compile a module each time someone pushes updates to the
>text. This would require a move from SVN to git, but the added
>advantages of that would be significant anyways. I gladly can tell you
>more about that if you are interested.
>>> 
>>> Peter
>>> 
>>> 
>>> 
>>> Sent from my mobile. Please forgive shortness, typos and weird
>autocorrects.
>> 
>> _______________________________________________
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Reply via email to