-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm not sure this helps us, because we're using CMake, not qmake.
Blessings!
Jaak
On 06.08.2013 05:07, Troy A. Griffitts wrote:
Jaak,
I've include -DSWORD_NUMVERSION as a pkg-config cflag directive. I
hope this is good enough for you. You can
Questions:
(I hope these don't seem too naive to be asked in erudite company!)
When it's not something obvious such as support for av11n, how does one
determine what to specify for the *MinimumVersion* property in module.conf
files?
See
Relying on pkgconfig is not an entirely viable solution as it is not
feasible to use on all target platforms - most notably Windows.
--Greg
On Mon, Aug 5, 2013 at 9:07 PM, Troy A. Griffitts scr...@crosswire.orgwrote:
Jaak,
I've include -DSWORD_NUMVERSION as a pkg-config cflag directive. I
Windows frontends do not use a common packaging system to share a SWORD devel
installation.
Greg Hellings greg.helli...@gmail.com wrote:
Relying on pkgconfig is not an entirely viable solution as it is not
feasible to use on all target platforms - most notably Windows.
--Greg
On Mon, Aug 5,
On Tue, Aug 6, 2013 at 6:29 AM, Troy A. Griffitts scr...@crosswire.orgwrote:
Windows frontends do not use a common packaging system to share a SWORD
devel installation.
Correct, but accessing this information at build time might still be
useful. Could config.h.in be updated to include this
For example, consider the following code:
class Q_CORE_EXPORT QString
{
public:
...
#ifndef QT_NO_REGEXP
int indexOf(const QRegExp , int from = 0) const;
int lastIndexOf(const QRegExp , int from = -1) const;
inline QBool contains(const QRegExp rx) const { return
QBool(indexOf(rx) !=
On Tue, Aug 6, 2013 at 8:05 AM, Troy A. Griffitts scr...@crosswire.orgwrote:
For example, consider the following code:
class Q_CORE_EXPORT QString
{
public:
...
#ifndef QT_NO_REGEXP
int indexOf(const QRegExp , int from = 0) const;
int lastIndexOf(const QRegExp , int from = -1)
Often, there's some obvious feature that requires a minimum Sword
version. Absent that, I have been setting 1.5.8. I'll probably bump that
to 1.6.1 after the release of 1.7.0.
There are two functions of MinimumVersion. One is to shelter users from
modules they can't use. Another is to
Thanks Chris,
Suppose the module being developed has some preverse content, that gets
converted by *osis2mod* as follows:
div type=x-milestone subType=x-preverse sID=pv1/
div type=x-milestone subType=x-preverse eID=pv1/
am I correct in thinking that I should set
MinimumVersion=1.6.0
?
As Chris noted, this is a clue to a frontend that the module might not work as
expected. What a frontend does with that can vary.
The MinimumVersion, at least in part, is a handshake between osis2mod and the
SWORD engine as to whether a module built by osis2mod has features that a
particular
1.7.0 not 1.6.0.
On Aug 6, 2013, at 11:00 AM, David Haslam dfh...@googlemail.com wrote:
Thanks Chris,
Suppose the module being developed has some preverse content, that gets
converted by *osis2mod* as follows:
div type=x-milestone subType=x-preverse sID=pv1/
div type=x-milestone
Thanks DM for the further clarification.
So, if my understanding is correct, osis2mod version 1.7.0 transforms the
OSIS such that because at least one instance of preverse content must use
the milestone form of the div element, then all div elements in the module
must also be the milestone form
The current focus is all on whether the engine can be recompiled in different
platforms, each with its own idiosyncrasies. That's natural at this stage.
Most of the developers are responding in like manner.
I''m rather more concerned with module development, and how this fares after
the software
The pre-verse div should be ignored as a div. It probably should have been a
milestone element. It should not confuse the SWORD engine.
osis2mod 1.6.1 had the pre-verse div. It is not new w/ 1.7.0. It was supposed
to work with SWORD 1.6.1, but it did not. From what I can tell 1.7.0 does work
On Tue, Aug 6, 2013 at 10:41 AM, David Haslam dfh...@googlemail.com wrote:
The current focus is all on whether the engine can be recompiled in
different
platforms, each with its own idiosyncrasies. That's natural at this stage.
Most of the developers are responding in like manner.
I''m
Yes, quick lookup and paste for an example, but the problem is the same
regardless of my mention of vtable: The classes are different between
the compiled objects and this is not a safe situation.
My only mention of this is to show that we're not simply speaking of
obtaining version
On Tue, Aug 6, 2013 at 11:12 AM, Troy A. Griffitts scr...@crosswire.orgwrote:
Yes, quick lookup and paste for an example, but the problem is the same
regardless of my mention of vtable: The classes are different between the
compiled objects and this is not a safe situation.
My only mention
Greg,
If I were a person who also compiles a front-end, then your suggestion might
make more sense.
This is not the case - so I can't be the agent to take on this aspect of the
testing.
I can merely report what I observe with module utilities (compiled for
Windows) that match SWORD version
Thanks DM,
I agree - mod2imp is only for getting some clues as to what went on under
the hood when the module was built using osis2mod.
The OSIS file from which the module was made was generated by [the latest]
usf2m2osis.py
It is well-formed and valid to the schema, and the only milestone
19 matches
Mail list logo
