Correct. I suppose it stopped working after SVN 3840 ("Fixed
CMakeList.txt to properly include SVN revision number if within an SVN
repositor").
After some more research, I think the issue is that the
IGNORE_SVN_FAILURE option to Subversion_WC_INFO() was only introduced in
CMake 3.13 and
Hi Jaak,
Thanks for reminding us there is a problem here. I am not sure I have my head
around this one. What I added was supposed to be a cmake module which worked
correctly within svn and outside, as long as a parameter was passed which
basically says skip errors.
If I remember correctly, it
Hello,
If changes/fixes to the CMake build system is in queue, please consider
taking a look at this BibleTime issue as well. Thanks!
Best regards,
J
On 08.01.21 01:49, Jaak Ristioja wrote:
Hello!
The capricious CI for BibleTime again fails to build the latest SVN
trunk version of Sword
Hello!
The capricious CI for BibleTime again fails to build the latest SVN
trunk version of Sword with CMake:
-- Found Subversion: /usr/bin/svn (found version "1.9.7")
CMake Error at
/usr/local/cmake-3.12.4/share/cmake-3.12/Modules/FindSubversion.cmake:99
(message):
Command
On 01/04/2018 03:02 AM, Greg Hellings wrote:
> I'd like to wrap a Sword 1.8.1 release this week
FYI, I had been intending to get debug work done on Xiphos and arrange
the 4.0.8 release closely with Sword 1.8.1. However I've been handling
serious time suckage this week and last, and I'm about to
Greetings Sword devs,
I've put a little elbow grease into the CMake build scripts to bring the
"make tests" option there up to snuff. The current heads of both trunk and
sword-1-8-x should be able to run the tests/testsuite/runall.sh option with
a CMake build now. This is all nicely packaged with
Today I've been updating to the latest Sword 1.7 (from the 1-7-x
branch). I ran into an issue with the python module not getting
installed - here's the cmake command:
cmake -DLIBSWORD_LIBRARY_TYPE=Shared
-DLIB_INSTALL_DIR=/usr/local/lib64 -DSWORD_BUILD_TESTS=Yes
-DSWORD_BINDINGS=Python
On Fri, Jun 21, 2013 at 08:44:23AM -0500, Greg Hellings wrote:
OK. I tried running make tests, but the osistest doesn't seem to be
included. It'd be nice to get the test suite passing.
As a start for fixing osistest, I added osistest to the list of test
programs in
On Thu, Jun 20, 2013 at 8:04 AM, Ben crick...@gmail.com wrote:
Good catch - looks like I accidentally grep'd for the wrong string when
I was making sure I had gotten them all. I have added the additional
option of BINDIR that captures the appropriate value. You can try again
now, if you'd
On 06/19/2013 08:35 PM, Greg Hellings wrote:
On Wed, Jun 19, 2013 at 7:18 PM, Ben crick...@gmail.com
mailto:crick...@gmail.com wrote:
On 06/19/2013 10:00 AM, Greg Hellings wrote:
On Mon, Jun 17, 2013 at 6:14 AM, Ben crick...@gmail.com
mailto:crick...@gmail.com
On Mon, Jun 17, 2013 at 6:14 AM, Ben crick...@gmail.com wrote:
On 06/16/2013 11:55 PM, Greg Hellings wrote:
On Sun, Jun 16, 2013 at 9:22 PM, crick...@gmail.com
mailto:crick...@gmail.com wrote:
Hey Greg,
I'm building the python bindings with cmake 2.6.4. I'm trying to
On 06/19/2013 10:00 AM, Greg Hellings wrote:
On Mon, Jun 17, 2013 at 6:14 AM, Ben crick...@gmail.com
mailto:crick...@gmail.com wrote:
On 06/16/2013 11:55 PM, Greg Hellings wrote:
On Sun, Jun 16, 2013 at 9:22 PM, crick...@gmail.com
mailto:crick...@gmail.com
On Wed, Jun 19, 2013 at 7:18 PM, Ben crick...@gmail.com wrote:
On 06/19/2013 10:00 AM, Greg Hellings wrote:
On Mon, Jun 17, 2013 at 6:14 AM, Ben crick...@gmail.com
mailto:crick...@gmail.com wrote:
On 06/16/2013 11:55 PM, Greg Hellings wrote:
On Sun, Jun 16, 2013 at 9:22
On 06/16/2013 11:55 PM, Greg Hellings wrote:
On Sun, Jun 16, 2013 at 9:22 PM, crick...@gmail.com
mailto:crick...@gmail.com wrote:
Hey Greg,
I'm building the python bindings with cmake 2.6.4. I'm trying to
specify a user location, but it doesn't work with current svn -
Hey Greg,
I'm building the python bindings with cmake 2.6.4. I'm trying to specify a
user location, but it doesn't work with current svn -
SWORD_PYTHON_INSTALL_DIR is always just OFF, even if I pass a value
through the cmake command. If I pass 1 as the value, then
SWORD_PYTHON_INSTALL_DIR gets
On Sun, Jun 16, 2013 at 9:22 PM, crick...@gmail.com wrote:
Hey Greg,
I'm building the python bindings with cmake 2.6.4. I'm trying to specify a
user location, but it doesn't work with current svn -
SWORD_PYTHON_INSTALL_DIR is always just OFF, even if I pass a value
through the cmake
Are you seeing a problem with $SWORDSRC/src/utilfuns/swversion.cpp not
finding config.h?
./src/sword/utilfuns/swversion.cpp:18:20: fatal error: config.h: No such
file or directory
~A
On Saturday, January 5, 2013, Ben wrote:
Hey Andrew,
Cmake is a replacement for autotools/configure - it
No options. Just cmake ../sword
On Wednesday, January 9, 2013, Ben wrote:
I haven't been seeing that. Is that when you run cmake? What options are
you using?
On 01/09/2013 09:54 PM, Andrew Thule wrote:
Are you seeing a problem with $SWORDSRC/src/utilfuns/**swversion.cpp not
finding
Hey Andrew,
Cmake is a replacement for autotools/configure - it still uses make.
Cmake isn't related to python.
The normal sequence with cmake is:
cmake
make
make install
The normal sequence otherwise is:
./configure
make
make install
So cmake is just another way of setting up the Makefiles
Thanks, Greg. Both the python and icu patches work so far for me.
-Ben
On 01/04/2013 04:36 PM, Greg Hellings wrote:
Ben,
I just made a series of commits which further improve handling of
Python builds. They do the following:
1) Move handling of bindings configuration up a directory level so
Thanks Ben.
I'll have to give it a try.
~A
On Saturday, January 5, 2013, Ben wrote:
Hey Andrew,
Cmake is a replacement for autotools/configure - it still uses make. Cmake
isn't related to python.
The normal sequence with cmake is:
cmake
make
make install
The normal sequence otherwise
Ben,
I just made a series of commits which further improve handling of
Python builds. They do the following:
1) Move handling of bindings configuration up a directory level so
CMake can include support for bindings other than SWIG in the future
(unrelated to your complaint)
2) Add detection for
On Sat, Dec 22, 2012 at 12:51 PM, crick...@gmail.com wrote:
On Wed, Dec 19, 2012 at 9:06 PM, Greg Hellings greg.helli...@gmail.com
wrote:
On Tue, Dec 18, 2012 at 9:27 PM, crick...@gmail.com wrote:
Here's a patch that helps some with osistest. I still get the
following error when I run
I'm curious, why do people seem to prefer cmake to make? Is that a python
thing?
~A
On Fri, Jan 4, 2013 at 5:09 PM, Greg Hellings greg.helli...@gmail.comwrote:
On Sat, Dec 22, 2012 at 12:51 PM, crick...@gmail.com wrote:
On Wed, Dec 19, 2012 at 9:06 PM, Greg Hellings
On Wed, Dec 19, 2012 at 9:06 PM, Greg Hellings greg.helli...@gmail.com wrote:
On Tue, Dec 18, 2012 at 9:27 PM, crick...@gmail.com wrote:
Here's a patch that helps some with osistest. I still get the
following error when I run osistest, though:
UTF8Transliterator: ICU: no resource index to
On Tue, Dec 18, 2012 at 9:27 PM, crick...@gmail.com wrote:
On Tue, Dec 18, 2012 at 10:47 AM, Greg Hellings greg.helli...@gmail.com
wrote:
If you configure with SWORD_BUILD_TESTS=Yes CMake will configure the tests.
You can then issue 'make tests' from the top build directory and it
will
On Wed, Dec 19, 2012 at 7:59 PM, crick...@gmail.com wrote:
On Tue, Dec 18, 2012 at 9:27 PM, crick...@gmail.com wrote:
Here's a patch that helps some with osistest. I still get the
following error when I run osistest, though:
UTF8Transliterator: ICU: no resource index to load
If you configure with SWORD_BUILD_TESTS=Yes CMake will configure the tests.
You can then issue 'make tests' from the top build directory and it
will build _and_ attempt to run all the tests. Now it fails for me on
the first one because of a missing directory ../../osistest. I have
a feeling this
On Tue, Dec 18, 2012 at 10:47 AM, Greg Hellings greg.helli...@gmail.com wrote:
If you configure with SWORD_BUILD_TESTS=Yes CMake will configure the tests.
You can then issue 'make tests' from the top build directory and it
will build _and_ attempt to run all the tests. Now it fails for me on
On 12/17/2012 12:40 AM, Greg Hellings wrote:
On Sat, Dec 1, 2012 at 9:44 PM, Ben crick...@gmail.com wrote:
On 11/21/2012 10:27 PM, Ben wrote:
Hello,
A couple thoughts related to building python bindings with cmake:
1. build dir/bindings/swig/python/setup.py has the following line:
On Mon, Dec 17, 2012 at 5:32 AM, Ben crick...@gmail.com wrote:
Cool, thanks. Also, I was looking at the tests, and it didn't look to me
like cmake was building the tests directory properly, so I actually went
back to using the old build system. If you want to commit any changes to
build the
On Mon, Dec 17, 2012 at 9:17 AM, Greg Hellings greg.helli...@gmail.com wrote:
What does it seem to be doing improperly? That's a very broad
statement. I pretty much don't build the tests because they aren't
really kept up with and are intended to be a thing for people actively
developing on
On Mon, Dec 17, 2012 at 9:40 PM, crick...@gmail.com wrote:
On Mon, Dec 17, 2012 at 9:17 AM, Greg Hellings greg.helli...@gmail.com
wrote:
What does it seem to be doing improperly? That's a very broad
statement. I pretty much don't build the tests because they aren't
really kept up with and
On Sat, Dec 1, 2012 at 9:44 PM, Ben crick...@gmail.com wrote:
On 11/21/2012 10:27 PM, Ben wrote:
Hello,
A couple thoughts related to building python bindings with cmake:
1. build dir/bindings/swig/python/setup.py has the following line:
#!/usr/bin/python python
Looks like that should just
On 11/21/2012 10:27 PM, Ben wrote:
Hello,
A couple thoughts related to building python bindings with cmake:
1. build dir/bindings/swig/python/setup.py has the following line:
#!/usr/bin/python python
Looks like that should just be /usr/bin/python, or /usr/bin/env python?
2. It'd be nice to be
Hello,
A couple thoughts related to building python bindings with cmake:
1. build dir/bindings/swig/python/setup.py has the following line:
#!/usr/bin/python python
Looks like that should just be /usr/bin/python, or /usr/bin/env python?
2. It'd be nice to be able to install the python module
Hello,
I'm building sword with cmake, and I noticed that it doesn't look like
sword.conf gets installed. Is anyone planning to add that support to
cmake? I'm not actually sure if that file is used much, but maybe it
would be good for cmake to do the same thing as configure...
Thanks,
-Ben
Hmm, I was fairly sure I had added that, but it appears I didn't. I
can add that in, no problem.
I even documented the CMake option to enable it, but I check for a
different value during config and never actually got around to doing
the install!
--Greg
On Wed, Nov 14, 2012 at 9:12 PM,
Generating without bindings flatapi.cpp still included.
a bug?
bindings/sources.cmake:170
SET(sword_base_SOURCES
${sword_base_frontend_SOURCES}
${sword_base_keys_SOURCES}
${sword_base_mgr_SOURCES}
${sword_base_module_SOURCES}
${sword_base_utilfns_SOURCES}
All,
For those who would like to try out the CMake build system, but you
don't want to learn a new way to invoke the SWORD build process, I
have added a pair of sample scripts to the cmake/ directory. Both of
the samples will build the shared (.so) library, Perl and Python
bindings,
= ICU =
With autoconf icu / transliterations files were installed into:
/usr/lib/sword/1.6.1_icu_4.2.1
With CMake they end up in:
/usr/lib/1.6.1_icu_4.2.1
= locales.d, mods.d modules =
With CMake I'm missing:
/etc/sword.conf
/usr/share/sword/mods.d/globals.conf
Hi,
today I tried to build sword 1.6.2 with cmake.
I'm using Foresight Linux 64 bit version.
Here are the issues I found:
1. make install installed into /usr/lib instead of /usr/lib64, although
the pkgconfig file said libs are in lib64.
2. the icu stuff ended up in /usr/lib/1.6.2_icu... instead
of
Bin,
On Thu, Sep 30, 2010 at 10:34 PM, Ben Morgan benpmor...@gmail.com wrote:
Ok, that seems to work with BPBible now. However, it also seems to hard code
the path to libsword's dylib to be in the build directory, which could be a
problem (though I don't know too much about this linking stuff
Robert just pointed out to me some issues with building the CMake
bindings which may have been affecting those of you who reported
errors to me over the past few weeks. The fix is now at the top of
SVN head, if those who have had problems would like to update to the
latest HEAD and try building
Ok, that seems to work with BPBible now. However, it also seems to hard code
the path to libsword's dylib to be in the build directory, which could be a
problem (though I don't know too much about this linking stuff on MacOSX):
otool -L _Sword.so
_Sword.so (architecture i386):
On 15/09/10 08:45, Peter von Kaehne wrote:
[..] it did do anything funny on me. [.]]
It did _not_ do anything funny on me.
Sorry about that.
And yes, I second Matthew's comment on pretty output.
Peter
___
sword-devel mailing list:
On 15/09/10 01:57, Greg Hellings wrote:
I would like to use this as another chance to implore people to try
out the CMake system and report on how it is working for you. I have
implemented everything Dmitrijs has so far asked me for except for
CPack work. However, I haven't heard from other
I would like to use this as another chance to implore people to try
out the CMake system and report on how it is working for you. I have
implemented everything Dmitrijs has so far asked me for except for
CPack work. However, I haven't heard from other people if the system
is working for
On Tue, Sep 14, 2010 at 2:03 PM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
On 14 September 2010 19:46, Troy A. Griffitts scr...@crosswire.org wrote:
Thanks for the email link Greg. Yeah, the submitted changes in question
from project A were filter updates, and we do specifically state
Fellas,
I finally tracked down the missing steps in the CMake build having to
do with linking against ICU. The files have been pushed up to SVN as
r2536.
--Greg
___
sword-devel mailing list: sword-devel@crosswire.org
SWORD team,
For anyone interested in following along with the play-by-play of my
work on the CMake build system for SWORD, I have setup a preliminary
Wiki page: http://www.crosswire.org/wiki/CMake. Of course, it
requires a certain familiarity with Bazaar (just to get the sources)
and I try to
List (attempting to be gender neutral!),
I know I have mentioned in the past that I thought CMake would be a
worthy technology for SWORD to use to help simplify the disparate
number of build systems that we currently use. Autotools works
exceedingly well in Linux and passably for Mac users, but
52 matches
Mail list logo
