On Tue, Oct 5, 2021 at 4:26 PM John Dudeck <john.dud...@sim.org> wrote:
> As a Sword content developer, but not a Sword software developer per se, I > need to be able to do Sword content development on Windows. Not because I > dislike Linux, but because I have created in-house Perl tools for a > publishing team that uses Windows workstations and is not able or inclined > to add Linux workstations for Sword content development, when everything > else we do is on Windows. Mainly what we do is develop French content as a > contractor for Logos, then also generate Sword modules from the Logos XML > targeted for AndBible. (We also publish print and epub books). > > Theoretically I guess we could use WSL, but it would have to be easy to > get it set up, and work seamlessly with our Windows-based workflow. > WSL is crazy easy and I highly suggest you use it. WSL2 is even better. I, personally, run Fedora in there but it is side-loaded through a custom-built script. Getting Ubuntu out of the Windows Store is silly simple and you can leverage it from there. I don't know the state of Sword packaging, but building from source in WSL is just as easy as it is on full-fledged Linux. > > All that we need and want are the Windows command-line versions of the > Sword tools, mostly just osis2mod.exe, tei2mod.exe and xml2gbs.exe, without > having to whine and wait for somebody to generate them with each new tools > revision. I don't have the time or desire to do the Win32 cross-builds on > Linux. We don't care whether the exe's are built from C, C++, C#, Visual > Basic, FORTRAN, Java, IBM360 Assembler, .Net Whatever™, or are 32 or 64 > bit. Just that they work on Windows, work correctly, and that bug fixes > arrive in a timely manner. > These are automatically created on GitHub whenever I push a version tag there. They've been available up there for quite some time, and anyone with the ability to run the basic tools necessary can get them there. https://github.com/devroles/mingw_sword_package --Greg > > Thanks to all who have created Sword and the ongoing efforts to support > and improve it for the Lord's glory! > > John Dudeck > > > > Hello, everyone. > > > > Sorry for disappearing a few months ago without resolving the questions > that I had. I have been > > taking care of issues in my personal life which I won’t go into here. > > > > I’ve had time to consider what I would do with the project that I have > been working on and > > inquiring about here. Seems I have a few options: > > 1) Make the existing Win32 code work for what I’m doing; > > 2) Convert what I have to the Linux platform and use what’s actually > available and current in > > the SWORD Project; > > 3) Work to bring the work you all have done into the current Windows > / .Net Framework > > environment; > > 4) Give up and go another route; > > > > I’m leaning toward the third, but I don’t want to step on any toes. It > will involve: > > · Work out design issues (such as .Net only or .Net as a wrapper, > Azure > > compatibility) > > · Create MS VC++ Project(s) / Solution > > · Import code pages (mostly .cpp and .h pages presumably) > > · Work out build issues for both 32 and 64 bit platforms > > · Test the results (beginning with my own existing projects) > > · Share the code, preferably using a method you all are used to > using > > · Maintain the code (including changes to the main code base), > possibly as a new > > branch of the existing code > > > > I’m willing to take this on if it’s something that will be used by > others and, hopefully, supported > > by others as well. > > > > I have to admit that my VC++ skills need improvement since I spend most > of my time in C#. But > > it’s a welcome chance to build my skill set. But, of course, any help > would be greatly > > appreciated, especially in understanding both the current state and > plans for the existing code > > base. > > > > Regarding the other options listed above: > > 1) I have successfully accessed the sword.dll file from C#. It > required creating two separate > > wrapper classes and obtaining the mangled name using a utility provided > with Visual > > Studio. There are shortcomings to this approach including extensive > coding and > > performance hits. We can discuss those if a decision is made to move > forward; > > 2) I think I individually, we as contributors and potential > contributors, as well as others who > > will come on later will all lose out without a viable, up-to-date > interface for Windows VS > > development; > > 3) Bringing the code into current Windows, Visual Studio and .Net > Framework development; > > 4) I like what’s been accomplished in the SWORD Project and I want > to both use it and > > contribute to it. > > > > I look forward to hearing from you all, especially those who currently > work in Windows > > development with this code. > > > > Jeff Becker > > John Dudeck > Programmer at Editions Cle Lyon, France > john.dud...@sim.org j...@editionscle.com > -- > "Pere celeste, je veux vraiment une communion avec toi; aussi je confesse > que tu as raison et que j'ai tort." -- Roy Hession > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
