Hi Jaak,
Thanks for pointing this out. I believe this is a bug in the CMake
system. The autotools build system does not install zlib.h (it did
install zconf.h, which it shouldn't have done and is also a bug which is
now fixed).
Greg, is this right?
Troy
On 06/13/2013 10:47 AM, Jaak Ristioja wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Troy,
Imho there are already header files which clash, namely the zlib ones:
$ `echo -n 'ls -ld '; find include/ -name '*.h' | sed -e
's_^include/_/usr/include/_'` 2>/dev/null
- -rw-r--r-- 1 root root 15292 sept 24 2012 /usr/include/zconf.h
- -rw-r--r-- 1 root root 87011 sept 24 2012 /usr/include/zlib.h
Jaak
On 13.06.2013 11:32, Troy A. Griffitts wrote:
Jaak,
On 06/13/2013 10:12 AM, Jaak Ristioja wrote: Troy,
It still seems that you missed one thing. Namely, the #includes
with <> still include a prefix, i.e. sound/ and omniORB4/. The
Sword #includes do not, and this by itself is a big problem which
makes header filename clashes a lot more probable, especially if
other libraries would follow suit and have the same #include
convention as Sword does.
Jaak, I didn't miss this.
As I said in my last email, I'm not saying your wrong. I'm just
saying:
a) the headers I looked at include things DIFFERENTLY than your
patch, so I'm not sure your fix is the most standard. b) things
work right now on a ton of platforms and compilers and build
projects, and I don't want to change this just before a release,
which could potential break all of these-- especially if there
are no known problems with this right now. There is no reason to
push a potentially disruptive patch just before a release.
Also, if you use pkg-config to get the compile and link
directives, you shouldn't need to care about what to pass to the
compiler.
.cpp: g++ `pkg-config --cflags sword` $< -o $@ `pkg-config --libs
sword`
Thanks for being concerned. I understand your concern and value
your input, Troy
Regarding <> and "", the latter provides a better safeguard
against including the wrong headers in some situations, especially
when dealing with multiple versions of the headers being installed
at the same time. More commonly, using "" instead of <> can also
help to simplify the build system for libraries such as Sword.
I don't consider using <> instead of "" a bug. But what I think is
very inconvenient is that one has to explicitly use
-I/usr/include/sword/ instead of just using #include
<sword/stuff.h> in the source files.
This is cause for confusion for developers, who might think (as I
did and do): 1) Do I need to #include <stuff.h> // Sword header ?
2) If I #include <sword/stuff.h> then why do I need to pass an
extra -I argument to the compiler?
What I'm asking is that even if you don't want "" instead of <>,
please use a sword/ prefix for all respective #includes in all
header files of Sword.
Blessings, Jaak
On 13.06.2013 09:47, Troy A. Griffitts wrote:
Jaak,
I'm of the same mind as Greg. Our include syntax has been
working as is for 20 years on a number of compilers and
platforms. I hesitate to wholesale change this now because
of 'in principle' arguments without any actual problems being
seen. I don't have time to compile your changes on all the
platforms we support to test them. I know what we have now
works.
I'm not saying that you're not right, but I also don't see
your changes as standard. Just a brief look on my box,
/usr/include/sound/sfnt_info.h includes
/usr/include/sound/asound.h with: #include <sound/asound.h>
/usr/include/omniORB4/anyStream.h includes
/usr/include/omniORB4/omniTypedefs.hh with: #include
<omniORB4/omniTypedefs.hh>
Just the first 2 I looked at.
I'd like more time to investigate this before making a
change,
Troy
On 06/12/2013 10:28 PM, Jaak Ristioja wrote:
Well, using -I/usr/include/sword is just an ugly
workaround. It doesn't change the fact that Sword headers
include each other in a wrong manner (using <> instead of
""). Because it would only be a workaround, we do not want
to stick to it forever. We want this fixed.
Secondly, headers in the Sword include directory have a
greater chance of colluding with other headers in
/usr/include/ and elsewhere. Hence the Sword headers
themselves might include wrong header files if that
happens. That's why using "" instead of <> is important so
that relative paths would be searched before any locations
specified by -I arguments to the compiler.
I don't believe my patch broke anything, the main changes
were substituting <> with "" when #including Sword headers.
However, if it did break anything, it should be easy to
amend. I'm highly motivated to get my patches applied to
the next version of Sword one way or the other. So just ask
and I'll fix it.
Blessings, Jaak
On 12.06.2013 23:05, Greg Hellings wrote:
On Wed, Jun 12, 2013 at 2:51 PM, Jaak Ristioja
<j...@ristioja.ee <mailto:j...@ristioja.ee>> wrote:
Hi!
What's the integration status on this patch?
Blessings, Jaak
Can we allow changes which are not bare-minimum
build-breakers, such as restructuring the includes, be
a later issue for the next next release and just get
1.7.0 out the door, please? Also, what prevents you
from having -I/usr/include -I/usr/include/sowrd and
then having #include <sword/foo.h> and having it all
work just as planned? --Greg
PS: Is Troy the only one with access to apply this?
On 10.06.2013 22:49, Jaak Ristioja wrote:
Argh, someone must have changed things on SVN lately,
so this patch was invalid for the current trunk... I
wish you guys would learn git or something. Anyway,
here's something which should apply to SVN 2819, I
hope. SHA1SUM: 071a4fb64f1d0c2ed5d746d08791592f76eaf633
Blessings, Jaak On 10.06.2013 22:34, Jaak Ristioja
wrote:
Attached is a patch for this. Please apply. SHA1SUM:
9a99e34ce419ea3288a32148d431ec971fb0e675 Blessings,
Jaak On 10.06.2013 19:38, Jaak Ristioja wrote:
I'm working on the patch but here's a short
overview of the problem, in case discussion is
required. The problem is that source code using
Sword can't do stuff like: #include
<sword/versekey.h> This is VERY BAD, because we
must do #include <versekey.h> and provide
-I/path/to/sword/includes/ to the compiler every
time. The problem with this approach is that
versekey.h might also exist in /usr/include or in
other -I/include/paths. Additionally, this makes
the #include list rather incomprehensible,
especially when we want to sort it alphabetically.
There's no telling what <versekey.h> refers to - is
it part of Sword, part of something else, or a typo
(e.g. maybe this needs to be "versekey.h"). Why
#includes like <sword/versekey.h> don't work is
that the Sword headers themselves use includes
like <versekey.h> instead of "versekey.h" which is
correct. If I don't include -I/usr/include/sword in
my compiler arguments, but #include
<sword/versekey.h>, the versekey.h file tries to
#include <swkey.h> which fails because it can't
find the file in in the include path. The *.cpp
files in Sword also need to use "" instead of <> to
distinguish between header system and local header
files. Afaik this is just best practice. Existing
code using #include <versekey.h> etc will continue
to work as long as the -I/path/to/sword/includes
exists. Blessings, Jaak On 10.06.2013 19:21, Jaak
Ristioja wrote:
Actually I just remembered another serious flaw
which causes a headache for developers using
Sword. I'll write a patch ASAP. Blessings, Jaak
On 10.06.2013 09:43, Troy A. Griffitts wrote:
Jaak,
I accepted and applied your header file patch
nearly 5 months ago. Are you telling me that
you still have 549 warnings from SWORD
headers?
Troy
On 06/09/2013 11:55 PM, Jaak Ristioja wrote:
On 09.06.2013 23:21, Troy A. Griffitts wrote:
I don't think other developers are
getting ignored. Please be specific.
Just because I don't accept a patch
doesn't mean a developer is getting
ignored.
In fact, many times trying to make this
release, when people complain that we
need something fixed for this release, I
ask for a simple testsuite addition to
show the problem and desired result, and
don't get a response.
I don't believe the problem is as you
think it is Jaak. Many people whine about
this or that. Not all whine for things to
go in the same direction.
Everyone whines for a release but not
everyone is willing to help submit tests
and then fixes for those tests.
You stated that you would get involved
to help, but you only submit things for
which I previously told you I wasn't
interested in accepting (worrying about
pedantic warnings whose changes often
make the code less readable and do
nothing to improve any of the real
problems for the end user. Though I do
appreciate a few of the warning fixes
you submitted, a few being actual bug
fixed too (thank you)-- I'm just ranting
right now.)
As a BibleTime developer, I want to available
tools (-Wall, -Wextra, cppcheck, etc) to fix
any errors in my code. Due to the Sword header
files which generate a lot of warnings this
task is VERY inconvenient. For example, when I
compile the whole of BibleTime with GCC, I get
549 warnings from Sword headers (mostly for
unused arguments) - how am I supposed to find
the warnings relevant for BibleTime? This alone
often makes it a pain to develop BibleTime and
gives me enough reason to want to fork Sword.
Turning on and fixing pedantic warnings will
help find real bugs. FACT! Forcing developers
to work blindfolded will not help anyone.
The same tools can be used to find bugs in
Sword code, and SHOULD regularly be used for
this purpose to ensure code quality. As is
obvious these are currently NOT BEING USED by
Sword developers. However, when things
eventually break, users complain to the
BibleTime project. Hence, it is also in the
interests of front-ends to ensure that the code
of Sword is of good quality. Again - if Sword
won't work to ensure this and wont let us in to
fix things, we have another reason to fork.
This again leads us to the issue of attracting
new developers to Sword. I don't want to write
on this more than necessary to provide a small
argument for my conclusion. Afaik the current
situation isn't working well. Biggest obstacles
for me personally include working blindfolded,
submitting patches by e-mail and not getting
enough feedback for (ignored) patches and other
emails.
To conclude - maybe its just me, but altogether
I really feel it were easier to maintain a
parallel fork (at minimal to provide set of
patches) than to waste my time writing long
letters trying to make this relationship work
in its current form. I accept whatever path the
Sword project takes, but if it's not enough for
the needs of BibleTime and our devs, we will
make our own choices as well.
Blessings, Jaak The BibleTime team
PS: I apologize if this late-night response is
incomprehensible.
_______________________________________________
sword-devel mailing list:
sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above
page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above
page
_______________________________________________
sword-devel mailing list:
sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at
above page
_______________________________________________
sword-devel mailing list:
sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at
above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above
page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at
above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above
page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above
page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above
page
_______________________________________________ sword-devel
mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above
page
_______________________________________________ sword-devel
mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________ sword-devel mailing
list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel Instructions
to unsubscribe/change your settings at above page
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQgcBAEBAgAGBQJRuYcrAAoJEEqsYmEt1rCO2dBAAJmo5vimBUbV9Oj8eA6QOvR3
kj79xjqsWouPTuoV5fv5oYqO8KH3S03IzTIR5NjjYQ0gBJSstIE2bfvAwlUnTzkq
5+6/ZQiqLyK1mpMn/Hs1ykze5eV6bKz+bM+9gY2PvI/ftTiPf5inob9iLdU+pv0Z
mh6SGgkv21F3o0S/rWIxGEQM4em59IEbjYqxwniHnq8Icmr3ln2xbu3AObZziAVS
qLg/PHQaYrL1P6E7YetynO4gWqFAqFb5vK/7Jd55qsYLP2XdAP2nUUD5ftMBkils
WFbFZgj3G+6zfQdCo385WROzc6++AUGqXHsFvg0FvpHn5bDQ+66JiifSaykibU9G
cZerJ9yFWB6CyX+E1L7FTsZKkf4RHzwmv86OCXiJAJhECfHAnyKFK4Dp+2Z3oVNw
ME6e4DTmJuPQOEUI4BF2o5rd2HzxxzRZzonzkrpfXkH0DbRJNuZqL6xQVX3Eefen
hCENogvrBT9ZKG1Uq24denYJMSXLaS3JI2il4SruTMGML/ODvUnQ5uTPkoxUICJt
/e/El7vIPwIxLbNOTDiSg+d80c7Uo7Ro3tWOGkN0Qw640arLf11RFu1qeALJRHqK
Wsew6bZzpRZ1U07XXLLAakkIdCfxMW7xfaV4vouSOn5oxROK2I4joFdat1N/ykAD
/7y4uGk8Zbz2/X4gfl84rDvfDo73TVxTrHcVREmwIc2JKP7YUR5k1FOBbEt7y3jd
9p17l/D8SzIkFdKF+/0hsz0o4rSJIQqD5AByPihDtQ3ECIwxtcC9q/xD8RbzL4cg
B2QDJ5xUI1v2nWmQNzXn2RH5zYKARQWlmLJEwiyQA1DPk+U8TewRY/4dBU7C2JAA
E5KhC4lbB8sbBWj3o/qqs4MWXDfBgHI3jHjH5+0UVQj/ucSI/8uSVasy/LU16g4Y
PUbqDC9fNh/JtINj0Yi3IRnpg8et6Jdiy1kuzcPhVUne9er3Yd9VqywNS/uB1sMF
mNU3T+nXdkR8MnK7XQ0eCN3UPVj2Nk7+m+9PqY05agVWQSUxuwYt9gApiLZYIfJg
sTPKtx+uGQqJ4abRrGN9DGdM6bEG7rT1xG0CduJDwWrPHXv/AvXeGiZh4Qhs4jG4
6na7BY+yR1UpCHj9N8Qj3IS69BVmB63TMfEts135i4tChX0HIHi4fdNuhKcoK5pe
7hfEgD6D5rQKtbb5x1w9RlDUddeh/4ksuxo2/QFGPliKr5VhEsthUF3HS+IF4jRE
bdHZQyBjSbNITKMwTCyQt/pVeypBf7ZiNB7z6TbflDA1riwgQOuHCrkOi+t2BiK6
WQvm2GkEYn0ePQQVSlt87srYZw1NCLjoNkU2pVDfMGdtmSsUAXgP5UqgCDbO+gFP
61zwWYr4GJ3CiYThgtZifybTN3efL4eQyNNLgziPrgKqE85D4KEI5F5C9cU32c+k
vLrjBQgx2ss6ICsaCoDrFpoqfqQFhTYK8FYRJileigWR7sBislhnP/MM/4QGUiOu
A1GaaJNuu1aHrqB5+ff3LtdOg37BaZmB6tdjOxV3nrRADL+rEm3FBiU+9sbTartd
qckR/xTHYq9nBJ+BgYCgeq7O6U40AItLFE9WTWIFsGAU6Ve4FrDwYQa67syYtEkN
byQpgD9/hg5fKeMbYZcmEmNPcdb99cLc43qUVv3UcavzbJhV+iuefLTSUpoUqOOa
N02MmnT0y0iEPYxFeWTnXu4gmgv0FH9SuPPa8riwXaBnPEkSrhOaztApJAIj+d2M
ZAXalwIHK3wd6k2S9dTysCKIqfv4THAbZoVPkG49f0ThN5E5hzsgfVsZX8wbqbPk
qp/nl3/BYMeuddHtqzJYapJ4FJvB0g119MhnBz0bnXLWOlXJpborni39CjwSEZqz
cfFep3DHISyo2uQ1GqSn1qKAU9h3mMBAtfNQofQsZ3rKoXVtllhPG85bHBS7MupD
MxrxQtKIQLxS0xF2eeUg86bjzX7aP/ojoNuliGsV2AXO2DAbu/EVHPMJofI6mY7R
qdpg6hGTldIPI3smkFJKEL57f9O1rVsegmGIJoTloDX/qOXQg6D74C3tG6hST64v
B5dNGLF/h+PQAcC7TTiBPkIOPVzjXiqyup2zsqkIwCkWKYOHXTbUXr5yDVdKFEiB
cTsTa5DUlRbMJPfb9LCdcnHzkUCmukYBDtZA1omBIFP2B5kaZ9oosjVuYqMiJqfw
xbVW2JZCOcUkGG31wE5xYEFJkCCfDH+KJ3O2TEsS+af2I9D8mDYZY1sEzOuEJZ88
EW1N1VuxMyXzlhvahjnEr2mjsdYGVdC8bI4tBGjLBcrZ1AEKJItcpYhvugOJkTo4
hXHcWyz5IfOGfw8Yv4cFRKwUCcUztv5wmu8ZI0dXeaIGFphwelF/dwCiPcyN9FwF
fRudqSds6crUmMt3zgHHTzL35HYzh5UOZocGzCkW0Q1O+z6CaY80xUQOrJIvkU9l
8IUL7ePRsNDz3ZPMJaYvnVFHdmi5Y29Y9+GfyNsoSoyfhtbWoIqGWTt4OYazUBGu
1YQ3lum2Fix6ZjLI3THXUJhzfUt2rL76n+ulk8G3W88iDXHHvYoN7yWSx28bWBBp
pJmiiBWKa5p1ESADG3LXQ2sdDKpCrDpUaSbf2rf/gJGvomgcfKVxd8cJ4PfJYIsZ
j6YFDUOqnGf1/YnQo7GZ55AgLok2DQRTBkIFJbZiElkG7rwHEa6awUaftoT0m171
/Si9mQmShWYoKvkbUWsP
=jSzY
-----END PGP SIGNATURE-----
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
