<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 6, 2013 at 11:12 AM, Troy A. Griffitts <span dir="ltr"><<a href="mailto:scribe@crosswire.org" target="_blank">scribe@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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.<br>
<br>
My only mention of this is to show that we're not simply speaking
of obtaining version information when discussion whether or not to
use pkg-config.<br>
<br>
As I mentioned to Greg, my initial intent was to give you the
define for which you asked in swversion.h but didn't want a 3rd
place to have to change the version number for our package. I'm
happy to generate something with the autotools build system, but
Greg would probably have to follow suite in coordination, or
otherwise always rely on autotools generating this and we'll
commit the generated file into the package, as we currently do
with config.h.<br>
<br>
Regarding saving compile flags in a, e.g., swbuildoptions.h, I'm
not amiss to this either, but this again would need to be
coordinated between the autotools and the cmake builds.<br></div></div></blockquote><div><br></div><div>CMake supports the same syntax as autotools for populating files such as sword.pc. Since CMake already has the version information in the string form, the only difficult part from my viewpoint is to properly parse that into whatever final form we decide, whether that's a _MAJOR, _MINOR and _PATCH or a single numeric version with expanded numbers of variables.</div>
<div><br></div><div>I already have examples of CMake handling version data in cmake/FindCLucene.cmake around lines 82-99. And you can see that populating <a href="http://sword.pc.in">sword.pc.in</a> is as simple as a single call on line 52 of cmake/install.cmake. So adding an additional file that we process is pretty trivial for CMake as it was for autotools.</div>
<div><br></div><div>--Greg</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
<br>
I am still of the impression that pkg-config is the right way to
solve this problem, and the system which don't have pkg-config
don't have a problem to solve.<br>
<br>
e.g., you are grabbing the source for SWORD and installing it and
compiling it yourself. You know exactly which options you've
chosen to compile with, and you know exactly which version of
SWORD you grabbed.<br>
<br>
In conclusion, I'm not against adding a new version define to
swversion.h But we need to coordinate something between the make
system managers.<span class="HOEnZb"><font color="#888888"><br>
<br>
Troy</font></span><div><div class="h5"><br>
<br>
<br>
<br>
On 08/06/2013 04:29 PM, Jaak Ristioja wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06.08.2013 16:05, Troy A. Griffitts wrote:
</pre>
<blockquote type="cite">
<pre>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) !=
-1); } int count(const QRegExp &) const;
int indexOf(QRegExp &, int from = 0) const; int lastIndexOf(QRegExp
&, int from = -1) const; inline QBool contains(QRegExp &rx) const {
return QBool(indexOf(rx) != -1); } #endif
...
If this library was compiled with QT_NO_REGEXP defined, and you
include this header file in your project and build without
QT_NO_REGEXP defined, then your .o files will expect different
vtables than what are provided by the compiled library.
</pre>
</blockquote>
<pre>Ok, I think I must have misunderstood where the discussion ended up.
First of all since none of the functions in that #ifndef block are
virtual, there's no difference in the vtable. Secondly, during
compilation time the situation you just described can be better
circumvented in ways not requiring passing -Ddefines via pkg-config
(see Greg's reply about config.h files). Thirdly, one usually gets a
runtime warning like "Symbol _XTV1MyClass has different size in shared
object, consider re-linking", or a dynamic linking error which
prevents the program from starting. Proper precautions can be taken
for most such cases to prevent any memory errors.
Anyway, I'm not arguing against using pkg-config (or *.cmake files) to
detect -I, -L and -l options which need to be passed to the
compiler/linker. With -D and other stuff things might get a bit
complicated. I still think that #defining a SWORD_VERSION macro should
instead be done in some installed header file, at least for platforms
without a working pkg-config (or for devs who don't know what
pkg-config is or how to use it).
Blessings,
Jaak
PS: Just for your information, I attached to this email a ABI
compliance checker report for compatibility between Sword 1.6.2 and
1.7.0RC2. The tool gave me some compile errors so its output might not
be fully reliable, but the file might still be informative.
PPS: For good reading on shared libraries, see
<a href="http://www.akkadia.org/drepper/dsohowto.pdf" target="_blank">http://www.akkadia.org/drepper/dsohowto.pdf</a>
<a href="http://www.akkadia.org/drepper/goodpractice.pdf" target="_blank">http://www.akkadia.org/drepper/goodpractice.pdf</a>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQgcBAEBAgAGBQJSAQhUAAoJEEqsYmEt1rCOb1NAAMXMip28jilh+EJSFo5Iv7Yy
ymkWJBod1tkTOq+wEPZU8yCX+6aSPxKwajBOD+k2L4kGHbpiap3VTw5WuyIIhANi
sIyOciEzI0ge80HVAAN0yc7m4/qi00wZ5Gzl2TKCJGpTFfnn2nM62KTkeX+QMxRw
F52Tx7D48nfBhGp6KUYhKZnoI4Sb/1AVr1gBINLkYVaBMUJyGK7gXDy3/4T0CK5g
RY10gWWsAvOxy1Ckcl8gJUOU/gIT5+9bUNf8s5k00rKxwKuBNjoxSvmqVIXM5WEb
uJG/MGeHckCl2aEbnLSUIlGFdVcvey5nXPK86GCoiCTrWwOpuIcemqPCjBgvK9sF
rO1GPHXxTwZOwGE1ZVnnAGW2UBGaemWn1+NF89O1Sy+/SKH6cyLYQtc0PHbokwGE
/FxGRzgo//VYxcJPjyhS+xKC3QTSO5/eZziiIN79U7paNzbPOtj/YFoZLa6wnajj
qTOJMA3/b/h4DKIg2gOf4znKDJZGrMjc/RQmgvyusZEMugqdZiRlFBTpPlf8tO5y
i3Ho1GD0pDejdxvfDsMjj7JAOfr2oO+iU9mp4hjk5fORKDLPcOk0pf/c3VgIvxCe
UVZDwqOtSt58xqXBJNXELrc/oe8t29of4T0SzRtxyQ1LUkZG/tJmIVW+Oi+NLYdz
iUvoXPd3WsNJyTu32gsB6ClAhHrL0Up+RjlAJ4Ywto/kpil53D2uKOWZL63QgBiA
GkkVRj90d9iWRGQ0eOKrHsJWW6VLjQJSXZyn3J2rEFDuh3pU05qucIrcqN9SqcX5
YZoieBm2IvzbS7t39UjgLnfU5AnnuZg2tjIK2F2RB4Hi2sleXNNhxBVM3msgCMsw
TmXrzFrrkr/E5Z2uIGYiEHrlIU+OWDWpptxad5xfDZCo3k48jsA8WWGfU1/84yIZ
c4Lf2na63fvbh5+kN8Hx0KlHBgyZOuRRsFpo3fXgg63CgFC8Id661LiiX304G5Fy
soflW8+fFf2mWwZdJzaxfaPHALdufohTOGMx/iu5ymUH+j7xuntDr8gFhwkFczjF
VfkZiLrA9J/i7egLOITGNLAiLMRi6SwKyNRYTEZvG9m1el6YHexqBP/1aU7Cp6Jz
EkVW6/u/85pVEthjIJH2ngLq4cS3x3DMKS5AJfA/WYL/qNQcVZlkhtu9crP6ObUL
zw2Lz7xdZ0Tbuc9rfSkxxs+njcJyIlEtBF5Q17wjoUdnLmzSKirmGLSWJmgtre1w
alFSxiPJHS/psesHytrrzSR/d1tb1ZJDhZ7NfAxnePILsN+Fe+DGL5i49B6ryBDl
W/j5IlNBlzZ75OHe+6F14GyPeVH/17p8ctgsVZ/k50qVvUvb6txmGg2D6Y+ltaXc
KEEu6N320+tIvUhjCTE8yL4dqmI1mH5NXWXFvf2sp+YkMdCzPwZVD0ZriO6l8RsV
XCwTIB+OffRBzZ8c8fAR5mvl8ovP7wf7UHEHGJcdJLSP2hqEqvft1UV83ibnNgAw
dzVYp2RVB/q7W6WIoqIXSUoHB19RACYhy6j4AF6ALQqGKilTx7KZT2lh0oR6Kzit
O5KigSnjXhdObks4pmiNCe5ik7ij4a5AesYxQoPeoq0xPu3JiD6mbxsHs9Z4XOoc
u1a/ViaXM0nzb/XNHPbM1a+0Cnjqvx1mxupKpIpsiqmBr/W05UdPQHWbqMXnfeeh
xVPKyhO1M8uFhmwG7uMn6PNGN/9VVo3EFeI4AfZlWf+ZucKJg1n4k0nxVNk9TMZI
eIYyogIoOLOYW9gfholnJWRT7IDebs4HzbZT//7d9LtrSbZLAlmZBjbFD/Bm/I7x
P6y5sUdSxdkDB39qp9PzUvnTJCWOvVNnU2fX3/KKMEv9Fmg+hUWU6pF+L/bPtDLE
lR/kLVWGMiU/5BfPg8Yemg3e3objBbWPcS7tda95DQaqdLVB8og1KXoIg/TWjRWg
TExoUGfKib25q0a1IdZhqPdYPN/QfcaRO1AXT/BJ3OJM0L2irCC8Co6cr33/w/Db
kF5jz2ClEpLqjTtTzY6t6zYhe7bQsWCSPPniCekG+c47Xl9485bNz5hStbgoP6Px
GI2ojTP+3Krj8Pb+HZ+rPYT4JobKd+IdOBJs6Hm7AXec8LayW1blMl6dnXGqp+P3
miVc1xW70wrAxVMtsIqzJxSJkhoIQdIN3mrpQIWuB3qk8l568XbIoLW5zp5JIHnB
0TITR18ADEjdDpmvIBwjBJ9oFY4aWO0uZpPfVf0XL6UNno+XYFoMM4MKe4BOrOs8
ByDjEXO8D2iIT15kzuPqb5TepXy2+FWs7gYuHk/oQ4cGA3iB3RMjbTqk49uzPUbN
yRIlUy3DEirVou0lxzOVYpc5zu3DHPjBCAUzQzIlfHNWSW+qfOLTefoXI0Ohp6+7
P1HCmV0xpwruOa5d0VIlqP60rwTq5ESJRYCpS1/aJgi/TTMqeHsWM9NBXTmSrbP4
h5aTU8UUeaGG9ZN7EDtpIvzrGsUylKoet5OhmiBIf43U7z0feEJ6UJZtFv90FPlv
CYXZoQcRq39WfdDopqktXHvNzXs4ihml8C190b9RkhqBSZzc7gcxyLyGODDfMF70
HelnI9CkKtAXwdyYN6n7faIYwegWTlfs94azI+B5BSqMhipUjNRA2H9Jl7F19UEv
kRGL9N1JkJATl0csG4bw79o506mCY+zX8Rd11vuaom6m+rjD8mNr5cvAKsOX/HfG
/aye8G6DLBpX9C/t+aV+
=Jtus
-----END PGP SIGNATURE-----
</pre>
<br>
<fieldset></fieldset>
<br>
</div></div><div class="im"><pre>_______________________________________________
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
</div></blockquote>
<br>
</div>
<br>_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br></blockquote></div><br></div></div>