Re: [sword-devel] Windows Development
Hi Zdenko, I use the git-svn bridge plugin for Git which will let you 'clone' the svn repository to a local git repository and do work as you would normally do in git. If you have svn permissions for a particular part of the svn repo, you will be able to push back up. We have access distributed to different individuals with write permission for particular parts of the svn repo, e.g., localizations, examples, build system, filters, tests, bindings, etc. If you would like permissions to make changes directly for a particular section of the repo, please let me know and I am happy to grant if appropriate. Otherwise, you can always send patches to patc...@crosswire.org for review and one of us with permissions can commit your changes or ask for updates before committing. Hope you are well, Troy On 10/9/21 10:15, ZdPo Ster wrote: On Tue, 5 Oct 2021 at 23:47, Greg Hellings wrote: ·*Share* the code, preferably using a method you all are used to using The official SVN is where all the magic happens. Most of us are happy to work in a git mirror while something matures and then eventually shine it up to get it submitted to Troy for inclusion in the SVN. Is there any official git mirror? https://www.crosswire.org/sword/develop/index.jsp refers only to svn... Potentially: how to submit a patch? Zdenko ___ 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
Re: [sword-devel] Windows Development
On Tue, 5 Oct 2021 at 23:47, Greg Hellings wrote: > · *Share* the code, preferably using a method you all are used to >> using >> > The official SVN is where all the magic happens. Most of us are happy to > work in a git mirror while something matures and then eventually shine it > up to get it submitted to Troy for inclusion in the SVN. > Is there any official git mirror? https://www.crosswire.org/sword/develop/index.jsp refers only to svn... Potentially: how to submit a patch? Zdenko ___ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Windows Development
Hi Jeff, On Mon, Oct 4, 2021 at 5:25 PM Jeff Becker wrote: > 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; > The existing Win32 is good and complete. It can do everything you need from a traditional Windows standpoint. It was recently improved with better Unicode path support. I'm happy to help you work on building it, if you have trouble. I do have a desktop, whence I'm writing you this message now, that is running Windows 10. I know at least one of the BibleTime developers also runs Windows to generate release builds on that platform. > 2) Convert what I have to the Linux platform and use what’s actually > available and current in the SWORD Project; > This will be the path of least resistance from the SWORD side. I have no knowledge into what else you're doing to know how it will affect that. > 3) Work to bring the work you all have done into the current Windows > / .Net Framework environment; > This would be a good route. I don't believe anyone has done it, though we do have active bindings for a large variety of other platforms already: Python, Perl, JNI, , Objective-C. We do know how to get bindings done, so you're welcome to take this path. > 4) Give up and go another route; > Happy hunting if this is your 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) > I would suggest a wrapper. Rewrites of SWORD tend to never reach feature completeness because there is OODLES of acknowledgement of corner cases in Sword that it already handles. > · *Create MS VC++ Project(s)* / Solution > This can be done, but you can also build off the CMake tooling that's already in place if you would like to. There's already bits in there to handle Python and Perl bindings being build from CMake, so it can probably handle adding some .Net wrapping. > · *Import code pages* (mostly .cpp and .h pages presumably) > > · *Work out build issues* for both *32 and 64 bit* platforms > The library currently handles both of these very smoothly across a large number of architectures. > · *Test* the results (beginning with my own existing projects) > > · *Share* the code, preferably using a method you all are used to > using > The official SVN is where all the magic happens. Most of us are happy to work in a git mirror while something matures and then eventually shine it up to get it submitted to Troy for inclusion in the SVN. > · *Maintain* the code (including changes to the main code base), > possibly as a new branch of the existing code > Hopefully we can find a way to avoid a permanent branch. Other bindings live in a bindings directory in the source tree and that is how they stay up to date. > > > 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; > Prophecies of our doom have been often repeated, being aimed at everything from our website (JSP-based) to our hosting (self-hosted SVN) to our language (C and C++). I look forward to this not panning out, either. > 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. > --Greg > > > I look forward to hearing from you all, especially those who currently > work in Windows development with this code. > > > > Jeff Becker > > > > > > > > > ___ > sword-devel mailing list: sword-devel@crosswire.org >
Re: [sword-devel] Windows Development
On Tue, Oct 5, 2021 at 4:26 PM John Dudeck 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
Re: [sword-devel] Windows Development
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. 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. 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
