[sword-devel] SWORD 1.7.0RC2

Mon Aug 12 00:34:08 MST 2013

OK, I've put together a scheme which moves the new version macros into 
our swversion.h file.  The new scheme goes out to 4 segments as we 
support in the SWVersion class.  Here are the defines.  Please add your 
comments and ask question, but I hope these will be self-explanitory.  
My only concert about SWORD_VERSION_NUM is the possible size we might 
get to if we ever get to 5.0.  Don't know how compilers handle macro 
checking on values over 4GB.

#define SWORD_VERSION_NUM 106902000
#define SWORD_VERSION_STR "1.6.902"
#define SWORD_VERSION_MAJOR 1
#define SWORD_VERSION_MINOR 6
#define SWORD_VERSION_MICRO 902
#define SWORD_VERSION_NANO 0

As for RCs, I've always bumped the subsequent segment up to near max 
(901 for RC1).  Not sure if this is standard but it keeps the versions 
sortable and is mostly obvious to a human what is going on.  I'm happy 
to change this is someone has problems with it.

As for padding of the new SWORD_VERSION_NUM for comparisons, the final 2 
segments are ###, wereas the second is ## and the first obviously 
shouldn't be padded or it will change the value to octal :)

Again, if you hate this, I can change it, but I compromised between 
consistency (all ###) and dangerously high values (> 4GB).

Comments welcome.  Waiting for Greg to get this into svn before RC3.

Troy

On 08/07/2013 12:53 AM, Jaak Ristioja wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, Aug 6, 2013 at 11:12 AM, Troy A. Griffitts wrote:
>> 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.
> Just to be clear, I'm not against providing sword.pc files so that
> people could use pkg-config in projects to detect Sword and required
> compile options. But I'm not sure whether it were a proper place for
> passing #defines such as SWORD_VERSION. For feature test macros (see
> "man 7 feature_test_macros") this is probably still a good place thou.
>
> As for the ease of use pkg-config aims to provide, I know a similar
> way to also improve Sword for projects using CMake so that those need
> no more CMake code than a regular FIND_PACKAGE() call, which will
> define the respective Sword_INCLUDE_DIRS, Sword_LIBRARIES,
> Sword_DEFINITIONS, Sword_VERSION_MINOR etc variables. For BibleTime
> this approach would mean we could delete the cmake/FindSword.cmake
> sword detection logic file and just use FIND_PACKAGE(Sword 1.7.0
> REQUIRED) to have all the respective variables defined. Using this
> approach Sword can put the version define into the Sword_DEFINITIONS
> variable, and I'd be happy that I don't have to mess around fixing
> BibleTime's logic for detecting Sword. This also beats trying to use
> pkg-config from inside CMake.
>
> If this approach were to be implemented by Sword, the issue about
> whether the version macro needs to be in #defined in an include header
> file would probably become miniscule for BibleTime and other projects
> using CMake. So from this perspective I think I can better understand
> Troys standpoint. :) But although this pkg-config like approach for
> CMake projects would practically solve the issue BibleTime currently
> has with 1.7.0RC2, I still retain my position that generally it were
> good to define the version macro in a header file.
>
> Since Sword has two parallel build systems, both need to be maintained
> (both should generate the same files for installation, including the
> generated *.pc, *.h etc files). As far as I'm familiar with both build
> systems, neither makes it technically infeasible to implement what has
> been discussed in this thread. I'm willing to help as much as I can,
> but I'm more familiar with pure M4, pure CMake and poking Greg via IRC
> than with autotools. :)
>
> On 06.08.2013 19:26, Greg Hellings wrote:
>> 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.
> Personally, I'd add both forms just in case, but if I had to choose,
> I'd choose a single numeric version because it would result in simpler
> C/C++ preprocessor commands for most common version checks.
>
> ***
>
> Troy, can you please give us some information about the current
> SWORD_NUMVERSION values? From the commit (SVN 2952), I conclude that
> it equals (MAJOR * 10^5) + (MINOR * 10^3) + PATCH, but how exactly
> does PATCH relate to regular, alpha-, beta- and RC versions?
>
> Blessings,
> Jaak
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (GNU/Linux)
>
> iQgcBAEBAgAGBQJSAX5/AAoJEEqsYmEt1rCOcqs/+QF4LlrXtT9wg4pIo+JMQlpI
> /VV4lzN72o+Gt3pd53Rcv5xvBeHGA8Cxq+9YZM4lIIJVGnQwZDicwlSu0Fu3riWH
> hoacrKKKfPEDsZ58UWxKaUQlEQA6Wc+CL5aEWljYrqx7mrxMrSUEGu5WTYGCvXAk
> 066MUWClxBVxz+XOrRNDQiKSixJh7Z+bdb36Hf2OaEeGnJw/rJHPPlZzVWsG3UWp
> 35dv+e9ksvYeXKLxUVmn3pdn+k5cSN6ufIplGXTUqrmi9loZFXVwX2qW+mTDBPGQ
> +JcCNY06ut7WwrsgvGk77zq4UZD4mc/qYA1AGJGxP83QkORnbdREIfrgFslNEkZJ
> gRbV2v5K5clSA7z8QWooeQBtTtrXmtVnMkR87TlcOqMuIrOU5/XMCY3jEbE+UyRa
> 50hObW1KsEeG5ziICC1iWWAc4YV0hCXKfcbreQToS+TInzrD0ZJipkHtdlzTorQg
> L7BRNYP881tdSIJIj5mr0NLcWMIYrTbbUEs+h8G3TlkXcsn5bkDsJfsjDFZaQpS4
> WGsnrxO8bxZwOwlgk0/mpLQXaIZF2Jbs6tfGcsNEhOnNQGKTLW4E84z/fGvtpOBH
> zvhdvWCSYQM8RlNNpQWZ2U3fMqqmAv3++L4+SUkSCc6Y1rZxynzEhSYSXNp2RRZN
> 6ZHJfbEIEcIhckCI3LjmGtmnPaZR4fRuhRrfjkc/tsKL0B444F+7mQTk4SA/9oQr
> LVRhXF+rebZAJE/xg1VvxkLsNlgaM3UanBxsjHJhSJZQR+fr8su2/TpyV0zZF7VQ
> tkUzbemuPYFDI+rMWywYH0H7ChcWuC1nsNHP8KCl6uwzOV8bSwQwOY2PtHiKFoaT
> K1VhzECYIJmiKqOIhzswI+CKx2Yu6jV4KPoleczMhadsp4MTLniY1MhOlGI3wMit
> EHW7L1q/aW4ziOKjhixdJMnRfz90MmOJQo2csICIuvJdAD+HZpHF9Icgykg0wPj1
> Q6Mo3M50mUCNMXJDYfz124l5FYNfIeVamsrk0u+C+xM7SvTxmfTP49xHOnSoYF/a
> SEQ8wlyMH0AE1eItdgnU9SD8swJUQGmBIdY5MhrOzCC2+zhMkPf5BDbYUBnaUJw5
> coOdbg3dfyU0vCXJLI8bOkLoFpU9aLX1bIB3iLVnU8bgNUrabG8+JPrAbmiwuY7/
> fdNB6HFfGZ1rMegEoVPmVyy2QMxczaliyU8ov5z4gmqAF/7CH3jn9yLL1yxZ/Ji4
> GAO72aqVKQBrwrJ3rDyBuzoLwWCO+CVSPvhACDaM8RuNc21d4eHoZtmMM5t2zCdo
> FwBADwf/GIt9ZQLl3PAt0UowUXwkw1GiOQTBI382t6zwlA8zw5egFI0qh1AG1OFP
> 2IIgiyc2umGFDoR7SnqNlVVn3INtfzqDyR5J7xRoRz8+fEstQBUXSLjDuqw78GAp
> 7Ja6fKjBkTyTKGSzr46bzJreYCelu6YpcZHM4KIaJf9hO+5A014OGLAN/ea7Hgz1
> IjNWCdwfMAQGL9m3G7lai9BMvQ19yxExepEscqGbvHTjbF/DP5Bn/OwsLCUUW0m9
> q4jz4w/78H+x+tf2/ysPYj8mho+JT2QXv3v9pbCePD2NyPhxqif+HOzWn6oud5HO
> SJdDplaAkawkm84qhEzRXXHx2tM0izD20VeSyy2hklVbTdoSLK+4JY16xRMCVI8C
> HUFFFnqzVwGcEXg9ebKT6hAfBjLCxelrKoulsHzXgzCq44dpmoNklTAeoaZLLg8V
> /j90glVq7BVO3K+Z9xOvdjkNW0tQEyNF58/ACMq8+VM6i+AcQUDe9MZhoc9Wvupd
> f0s8FfUmLDUJXX8PB4LD4EQVppAJKgXtokFotjJuW7A/SvNx5E1hNvm3118eJpky
> dmWr3PdUyWZpvir6H2AhzQtFDs4SrSJP0DWVQ+PCCUPEgsKOGOrDbn6GPNLuYI4D
> Q3I5KqDZDfJM76DpkCd1wqdbyXm15Fwv4uxy3F890rYPOIr9gC/zW1szojnLWJUK
> yUTsWDPT+lGpXNds3Iy53MYgUZPwE8cwn0TeydmECxx0Co07eRT49hsoTPIElBem
> xZrX4eJ80nNsMnvyZYmN0LM6l2fy+SkEMhpplC26yeGYMauECVeCk0jCF08YKEb/
> CiR2Jw/p5oUP46EHZ5+A5z3u/b8ZJA9oZfWJ74Xl+t4qLBZBtJzbzKgOyZ9ZTYUp
> fmJCj1u06k9M8t9D26V6ncVGCAS3+QNvdOFv5Z0sY5DFJpGkOEdpgBGjr72+TyeA
> nzAKnoVoNj/F5VSrsSXjcHwYyj9AeAE3HnU/btd4fm5myKjnzs4MlrLiyEku7MdM
> PFMFtim/FLWD2HxIxoTdt4OfEIbmWfD/BE5hHVA1IRBdhwdvAyv7vIls9tiuZbQc
> Rwj7oKsrGj1kuMlcK16ITQqeYhrlMoLbvbKSSG5c/jOIuCRO79nO8psgxmytKaZ+
> DU4RaroEgeC+hhk5cQSRFnnwhzgkhKIWsxkQRXON9fdO9cKywdU2/kBVybV0QxAp
> qIuAinU072mdKonaYx+twLHp61/7UHMRXySHY2RWTC27zRmS29rbi+wtHYr0fnvX
> i8YeENkahC9M1tBMDgwWWlJE/3sC2PwQaXEyMZT7VFYthRLhoYz5ksh0DxnQ7e8Q
> nWCeQg4by0hCkTK1q5n6nNxcBxFUKPm+ra2gzEOZfSZAOmLQihA/VFoG6GZ2P0wS
> H5K1KwpExGXlconjI2AZ
> =Mlww
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page