--nextPart3844620.1JXbF4rQkV
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 17 June 2007, Michael Olbrich wrote:
> On Sat, Jun 16, 2007 at 11:41:07AM +0200, Matthias Kretz wrote:
> > Can you make your example a bit more concrete? So far it looks designed
> > to break. Any real world examples?
> >
> > Have you read the rationale on
> > http://techbase.kde.org/Policies/Library_Code_Policy#As_library_develop=
er
> > ?
>
> I have, and I think it is wrong.

Let's see if I can summarize your reasoning correctly:
You think it is wrong because the include guard of two header files with th=
e=20
same file name (but different paths, and headers from different libs) could=
=20
use the same include guard and lead to an error that's too hard to find.=20
Therefore you'd like the build to break as soon as there are two header fil=
es=20
of the same file name anywhere in the include directories.

Example:
a) libs are using <> for includes
 Let's assume you want to make use of two libs in your app (staying with=20
libxyz and anotherlib). You've successfully used them for a first release.=
=20
Now at some point the build breaks because a newer version of libxyz=20
introduced the header foo.h and includes it from xyz.h. What are you as=20
application developer to do about that error? You cannot ask the lib=20
developers to rename the header file - it's part of their public API now.=20
=46rom your reasoning the application is simply screwed and has to include =
a=20
patched version of one of the libs in order to fix the build again.
b) libs are using "" for includes
You as application developer tell the libxyz developers about the problem o=
f=20
the include guard being the same for xyz/foo.h and anotherlib/foo.h and if=
=20
they care only a little about their users they'll go ahead and change the=20
include guard for the next minor release. Build fixed.

> To use the given example: I think=20
> "g++ -I/usr/include/anotherlib -I/usr/include/libxyz ..." should
> _always_ fail.
>
> The problem is the following:
> Many libraries use the same method to generate the include guards.

How about we add another policy for include guards then? It could e.g. say=
=20
that the include guard has to be prefixed with the name of the library.

> If we use <> instead, all source files will break and the error is much
> easier to recognize.

The error is still not easy to recognize. I guess for both cases the best=20
thing is to look at the output of the preprocessor. And then none of the to=
o=20
is really easier to recognize.

=2D-=20
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz@gmx.net, kretz@kde.org,
Matthias.Kretz@urz.uni-heidelberg.de

--nextPart3844620.1JXbF4rQkV
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGdjh6yg4WnCj6OIoRAvXXAJwOtv05uSdjNd/beWncYMYW/8L8sgCcCHs6
JZkAel+zVdWPX6K7Mr6pBJE=
=y8aP
-----END PGP SIGNATURE-----

--nextPart3844620.1JXbF4rQkV--