5:48 a.m.
The 'virterror.h' file has an #include directive to "libvirt.h" which
isn't correct
because libvirt include files are installed on a sub-directory named
'libvirt'.
i.e. when libvirt is compiled with configure --script=/usr, then libvirt
files are
installed in /usr/include/libvirt/.*
To be standard with Linux usage of include files, the correct directive in
virterror.h will be:
#include <libvirt/libvirt.h>
instead of:
#include "libvirt.h"
and in C/C++ source files using libvirt, there is just to include
libvirt with:
#include <libvirt/libvirt.h>
#include <libvirt/virterror.h>
This is conform to Linux usage of include files and this permit to simplify
Makefile(s) because there is no need to add option -I/usr/include/libvirt
to compile sources files.
Regards.
7:46 a.m.
On Fri, Jun 23, 2006 at 12:48:26PM +0200, Philippe Berthault wrote:
The 'virterror.h' file has an #include directive to
"libvirt.h" which
isn't correct
because libvirt include files are installed on a sub-directory named
'libvirt'.
I think this is correct because libvirt.h and virterror.h are in the
same directory. I think this is a relative address path and a relatively
common practice.
i.e. when libvirt is compiled with configure --script=/usr, then
libvirt
files are
installed in /usr/include/libvirt/.*
To be standard with Linux usage of include files, the correct directive in
virterror.h will be:
#include <libvirt/libvirt.h>
instead of:
#include "libvirt.h"
I must be using a non linux system :-)
paphio:~/XML -> grep '#include "' /usr/include/*/*.h | wc -l
1165
and in C/C++ source files using libvirt, there is just to include
libvirt with:
#include <libvirt/libvirt.h>
#include <libvirt/virterror.h>
that I agree with. Doesn't mean that relative addressing between header
files should be forbidden !
This is conform to Linux usage of include files and this permit to
simplify
Makefile(s) because there is no need to add option -I/usr/include/libvirt
to compile sources files.
The bug is that one should use "pkg-config libvirt --cflags" to get the
C compiler options and it does not return '-I/usr/include/libvirt'.
That said, I'm actually not against making the change. The problem this
raises is a problem of source tree. If you just modify the header, then
when compiling libvirt and including virterror.h you would load the installed
include libvirt.h and not the one from the source tree which is a very good
way to break the build or introduce very pernicious errors. What is required
to make that change is to reflect the include/libvirt structure in the
tree, moving headers in the structure, that doable but requires some not
so nice tweaks to try to preserve CVS history without breaking existing CVS
checkouts. I will try to do that,
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
9:15 a.m.
On Fri, Jun 23, 2006 at 08:46:06AM -0400, Daniel Veillard wrote:
On Fri, Jun 23, 2006 at 12:48:26PM +0200, Philippe Berthault wrote:
> The 'virterror.h' file has an #include directive to "libvirt.h"
which
> isn't correct
> because libvirt include files are installed on a sub-directory named
> 'libvirt'.
That said, I'm actually not against making the change. The problem this
raises is a problem of source tree. If you just modify the header, then
when compiling libvirt and including virterror.h you would load the installed
include libvirt.h and not the one from the source tree which is a very good
way to break the build or introduce very pernicious errors. What is required
to make that change is to reflect the include/libvirt structure in the
tree, moving headers in the structure, that doable but requires some not
so nice tweaks to try to preserve CVS history without breaking existing CVS
checkouts. I will try to do that,
I have just commited it to CVS. now the includes in the source tree
are under include/libvirt/ new directory. A number of files were also
changed to add the new subdir to the include paths.
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6537
days inactive
6540
days old
2 comments
2 participants
participants (2)
-
Daniel Veillard -
Philippe Berthault