Zdenko, you may have a look at my cmake configuration for SWORD for various
targets here:
* Windows MSYS2/MINGW64:
https://github.com/kovzol/bibref/blob/master/.github/workflows/build.yml#L110-L145
* WebAssembly:
https://github.com/kovzol/bibref/blob/master/.github/workflows/build.yml#L44-L59
Please let me know if I can help you more.
Best, Zoltan
ZdPo Ster <zdpos...@gmail.com> ezt írta (időpont: 2025. aug. 20., Sze,
7:51):
> My personal aim is to build the sword on windows with msvc and/or clang.
> So autotools is not an option (compared to linux).
> I have several years experience with cmake and building c++ multiplatform
> projects, so I can help with this.
> I believe bringing the sword to "msvc (and git ;-) ) world" could bring
> another contributor to this project.
>
> Zdenko
>
> On Wed, 20 Aug 2025 at 05:55, Greg Hellings <greg.helli...@gmail.com>
> wrote:
>
>>
>>
>> On Tue, Aug 19, 2025, 10:34 PM Aaron Rainbolt <arraybo...@gmail.com>
>> wrote:
>>
>>> FWIW (and as you well know since you're still a co-maintainer of it),
>>> the SWORD package for Fedora relies on the CMake toolchain.
>>>
>>
>> Indeed. But it really shouldn't. Mea culpa on that! The main reason I
>> never switched it is because it is the only currently easy access I have to
>> the bindings without always needing to stand up a development environment
>> everywhere.
>>
>> Personally, I've always used CMake rather than autotools for building
>>> SWORD when doing custom builds of it. I was under the impression that
>>> the autotools toolchain was deprecated.
>>>
>>
>> No. Autotools is the source of truth. CMake is a "best effort"
>> alternative that started out really as just a way for me to enable Python
>> bindings and Windows builds. But now autotools supports Windows
>> (cross-build) targets just as readily as it does Unix targets. And people
>> who want to use Python or Perl are well served by the existing CMake
>> toolchain.
>>
>> Ideally the bindings should be pulled out to a separate package and
>> uploaded to, for example, PyPI. (Peter - do you still use the Perl
>> bindings? I think you might have been the only one to ever use those, but
>> do you still?) That way they are available through that language's native
>> tooling. I did that, once upon a time, but adding tooling to automatically
>> regenerate the Swig binding would take that a long way.
>>
>>
>>> As for why one would use CMake instead, you could probably quote
>>> whatever the usual arguments are for using CMake instead of autotools
>>>
>>
>> I've never actually seen such a debate. Despite having no qualms with
>> shell script, I still find CMake more legible. But autotools is well known
>> and readily supported almost anywhere. Except for Windows build hosts. And
>> early on I was hoping to provide a way to build with MSVC through it to
>> replace the old handcrafted Windows build scripts. But when MinGW had fully
>> matured, that need was eliminated.
>>
>> (easier to audit for security as opposed to autogenerated
>>> multi-thousand-line-long shell scripts written in convoluted
>>> antediluvian POSIX sh language designed to work on older versions of
>>> Solaris and that check for bugs existing in assorted other ancient and
>>> likely entirely unused flavors of UNIX among other things, you don't
>>> have to build the build system itself and potentially run into
>>> insurmountable issues in so doing if trying to build SWORD on a system
>>> older or newer than the ones upstream uses, modifying the build system
>>> to add extra source files or move things around only gives one a
>>> migraine rather than making their head explode, etc.). I personally
>>> would like to not have to change the Fedora SWORD package from using
>>> CMake, and would ask for help if the CMake side of things broke
>>> because I don't want to fight with autoheadache.
>>>
>>
>> The problem is, those antique targets are still actively supported by
>> Sword, so using autotools is still a really good choice. Personally I don't
>> even dabble in C these days unless I need to edit someone else's code. But
>> more modern languages don't really target those older systems, so autotools
>> for a C++ code base is pretty much the best thing going to service all of
>> breadth of systems that Sword supports.
>>
>> --Greg
>>
>>
>>> On Tue, Aug 19, 2025 at 10:22 PM Greg Hellings <greg.helli...@gmail.com>
>>> wrote:
>>> >
>>> > What are your needs for using the CMake toolchain? It is strictly
>>> inferior to the autotools system with the exception of supporting Python
>>> and Perl more robustly. But I never was able to get it handling all of the
>>> Unicode tests perfectly, and even I don't use it anymore for the places
>>> where I maintain Sword builds. The two initial reasons for putting it
>>> together were MinGW support which was superior at that time in CMake than
>>> autotools (this is no longer the case) and the Python/Perl bindings. But
>>> even those I would likely move over to autotools at this point when the
>>> need for an update appears.
>>> >
>>> > --Greg
>>> >
>>> > On Mon, Aug 18, 2025, 4:25 AM ZdPo Ster <zdpos...@gmail.com> wrote:
>>> >>
>>> >> Any idea when cmake build will be fixed & improved?
>>> >> Recent svn version can not be built with cmake. Minimum change to at
>>> least finish configure requires:
>>> >>
>>> >> diff --git a/CMakeLists.txt b/CMakeLists.txt
>>> >> index 676353b5..bd3e6f81 100644
>>> >> --- a/CMakeLists.txt
>>> >> +++ b/CMakeLists.txt
>>> >> @@ -11,13 +11,14 @@
>>> >> # of their own GPLv2 license and all copyright is transferred to
>>> them for
>>> >> # all posterity and eternity, wherever such transfer is possible.
>>> Where it is
>>> >> # not, then this file is released under the GPLv2 by myself.
>>> >> +CMAKE_MINIMUM_REQUIRED(VERSION 3.10.0)
>>> >>
>>> >> CMAKE_POLICY(SET CMP0010 NEW)
>>> >> include(FindSubversion)
>>> >> Subversion_WC_INFO(${CMAKE_CURRENT_SOURCE_DIR} MYSVN
>>> IGNORE_SVN_FAILURE)
>>> >>
>>> >> PROJECT(libsword CXX C)
>>> >> -CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0)
>>> >> +
>>> >> SET(SWORD_VERSION 1.9.0)
>>> >> if(DEFINED MYSVN_WC_REVISION)
>>> >> SET(SWORD_VERSION ${SWORD_VERSION}.${MYSVN_WC_REVISION})
>>> >>
>>> >> --Zdenko
>>> >>
>>> >> On Fri, 17 Mar 2023 at 19:25, Greg Hellings <greg.helli...@gmail.com>
>>> wrote:
>>> >>>
>>> >>> Indeed. It's not a principled stand that I'm refusing to get
>>> Subversion going. It's simply that it's too much work that I haven't
>>> bothered and don't foresee doing so anytime soon.
>>> >>>
>>> >>> And, with no setup to automatically test the scripts in all the
>>> environments they must support, it's not likely others are willing to
>>> commit this on my behalf.
>>> >>>
>>> >>> --Greg
>>> >>>
>>> >>> On Sun, Mar 12, 2023, 09:42 Peter von Kaehne <ref...@gmx.net> wrote:
>>> >>>>
>>> >>>> I think you misunderstood Greg.
>>> >>>>
>>> >>>> There is a long campaign and strong feeling to have the project on
>>> Git but there is no agreement or movement to that. And it seems Greg is
>>> pausing his contributions until that matter is resolved.
>>> >>>>
>>> >>>> Peter
>>> >>>>
>>> >>>> Sent from my phone. Please forgive misspellings and weird
>>> “corrections”
>>> >>>>
>>> >>>> On 12 Mar 2023, at 15:51, ZdPo Ster <zdpos...@gmail.com> wrote:
>>> >>>>
>>> >>>>
>>> >>>> I am sorry, but I did not get the point of your reply.
>>> >>>> I do not use subversion - I use git-svn as proposed several months
>>> ago on this forum. But current cmake configuration expects everybody to use
>>> subversion, which is wrong.
>>> >>>> These patches improve cmake build:
>>> >>>>
>>> >>>> that will work also with git-svn
>>> >>>> MSVC build
>>> >>>> fix depreciated
>>> >>>>
>>> >>>> AFAIK it should cause no harm for other combinations, just improve
>>> current state.
>>> >>>>
>>> >>>> Zdenko
>>> >>>>
>>> >>>> On Thu, 9 Mar 2023 at 23:18, Greg Hellings <greg.helli...@gmail.com>
>>> wrote:
>>> >>>>>
>>> >>>>> I've never bothered to get Subversion setup on my local machine.
>>> Remembering the setup, plus my credentials, and how to use it is more labor
>>> than I've been willing to spend on this effort. If, in the future, I
>>> overcome that inertia then I'll happily test and apply this patch.
>>> >>>>>
>>> >>>>> --Greg
>>> >>>>>
>>> >>>>> On Sat, Feb 25, 2023 at 5:34 AM ZdPo Ster <zdpos...@gmail.com>
>>> wrote:
>>> >>>>>>
>>> >>>>>> Any update on this (after 3.5 months)?
>>> >>>>>>
>>> >>>>>> Zdenko
>>> >>>>>>
>>> >>>>>> On Sat, 26 Nov 2022 at 21:53, Greg Hellings <
>>> greg.helli...@gmail.com> wrote:
>>> >>>>>>>
>>> >>>>>>> Thanks. I am not privy to the patches email inbox, so this
>>> mailing list is the way to reach me for CMake things. I'll review these
>>> when I have the opportunity.
>>> >>>>>>>
>>> >>>>>>> --Greg
>>> >>>>>>>
>>> >>>>>>> On Sat, Nov 26, 2022, 13:46 Peter von Kaehne <ref...@gmx.net>
>>> wrote:
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> How to suggest improvements to the sword project?
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> You did it the right way. It just is a bit on/off as a project.
>>> GHellings is the cmake pumpkin holder as far as I know. I bcc him on a
>>> different email address.
>>> >>>>>>>>
>>> >>>>>>>> Peter
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> BR,
>>> >>>>>>>>
>>> >>>>>>>> Zdenko
>>> >>>>>>>>
>>> >>>>>>>> ---------- Forwarded message ---------
>>> >>>>>>>> From: ZdPo Ster <zdpos...@gmail.com>
>>> >>>>>>>> Date: Sun, 6 Nov 2022 at 22:22
>>> >>>>>>>> Subject: cmake patches
>>> >>>>>>>> To: <patc...@crosswire.org>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> Hello,
>>> >>>>>>>>
>>> >>>>>>>> please find 3 few patches related to cmake build (tested on
>>> windows with MSVC 2019):
>>> >>>>>>>>
>>> >>>>>>>> cmake_fix_deprecation.patch - cmake version 3.23.2 produce
>>> depreciation warning for old minimum version, co IMO it is time to increase
>>> expected cmake version
>>> >>>>>>>> cmake_fix_msvc.patch - there is no "/O3" options in current
>>> MSVC[1]
>>> >>>>>>>> cmake_git_svn.patch - I use git svn for accessing code, but
>>> cmake produce error because of missing svn executable. He is patch that
>>> fixed it + code for detecting svn revision (MYSVN_WC_REVISION) from git
>>> >>>>>>>>
>>> >>>>>>>> [1]
>>> https://learn.microsoft.com/en-us/cpp/build/reference/o-options-optimize-code?view=msvc-160
>>> >>>>>>>>
>>> >>>>>>>> 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
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> 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
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> 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
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>> _______________________________________________
>> 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
>
--
*Dr. Zoltán** Kovács, MSc*
*Private Pädagogische Hochschule der Diözese Linzhttps://matek.hu/zoltan
<https://matek.hu/zoltan>*
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
