Given that there is, just as Matej points out, likely only "market" space for one library , I think success of your fork will mean exactly this - regression and breakage for those parts you are not interested in. You have made this very clear.
But, I guess, you are not in a mood to listen to this. Peter Sent from my phone. Apologies for brevity and typos.On 26 Sep 2016 10:27 am, Jaak Ristioja <j...@ristioja.ee> wrote: > > On 26.09.2016 10:56, Peter von Kaehne wrote: > > We are supporting 32 bit devices and operating systems for the foreseeable > > future. Emails on sword-support confirm that. > > I have no problem with Sword doing that. But you can't force Sword++ to > do that, unless of course you get involved and help out to maintain > support for such devices and environments. Currently Sword++ is > prioritizing Linux systems on x86_64 architecture, because that is the > only hardware/software environment the only developer (me) has > reasonable access to. Second, I am currently prioritizing refactoring > over portability to specific platforms because of limited time. > Foremost, I intend to write modular, highly portable C++, but not to do > all the porting right away. I don't expect x86_32 failures in the near > foreseeable future. Support for non-POSIX-like systems like Windows will > probably turn most acute, but I guess it will have to wait for someone > else to take the lead on that. C++ Filesystem TS and Networking TS might > help thou. > > > I am arguing against careless breakage. > > None of what is done in Sword++ will break Sword, only perhaps > illuminate some things which > > > Bindings and utilities are an absolute necessity, 32 bit support may well > > be necessity for a good while longer and the keeping small of the list of > > compulsory dependencies has reasons too. > > I prioritize working on the core library over all else. To function > efficiently at this stage, I'm currently dropping those from the Sword++ > repository to keep it simple and slim. This will help me focus on what I > think is more important for Sword++ in this stage. I'm currently keeping > the utilities, but may move them to a separate git repository in the > future. Making a number of dependencies non-optional also serves the > same purpose of helping me to work effectively, given my resource > constraints, mostly in time. The build system and code logic for making > support of some of those dependencies optional was broken, so it was > easier for me to remove that cruft and move on. > > As I stated in my original announcement: feel free to contribute, feel > free to merge code back to Sword. After all, it's open source. :) > > Many blessings, > J > > _______________________________________________ > 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 _______________________________________________ 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