From: Daniel Veillard (Daniel.Veillard@w3.org)
Date: Tue Oct 03 2000 - 06:01:34 EDT
On Mon, Oct 02, 2000 at 08:51:45PM -0500, Kenneth Pronovici wrote:
>
> > This can be solved through clever (arcane maybe) use of preprocessor,
> > at least I am pretty sure it can be. Note that I am at the moment working
> > far too many hours in the day on some other bsd/win32/linux
> > cross-platform code.
> > [...]
> > intricacies of cross-platfrom building, anyone so inclined
> > is welcome to provide me with due dose of enlightenment.
>
> Maybe I'm missing something here, but why not just have internal
> libxml code include use
>
> #include "file.h"
>
> but install the include files to
>
> /include/libxml/file.h
>
> (or wherever) and have libxml client code use
>
> #include <libxml/file.h>
Yeah ... too simple, doesn't work I'm afraid.
for example debugXML.h needs tree.h, both for libxml code and client code
For the client code this will be located under a libxml subtree when
installed. Do you ever do "make install" on Windows ? Where do the includes
go, I hope not in the same directory for all installed packages !
Having an isolation by subtree and the client code using <libxml/xxx.h>
seems a needed practice to avoid utter mess, I assume it's not
challenged.
So assuming the headers have to be addressed by <libxml/xxx.h> from client
code. I don't want to have debugXML.h include "tree.h" because this
can lead to serious troubles due to interaction with other packages.
So debugXML.h have to include <libxml/tree.h>, and unless the headers
installed by "make install" are modified before being installed, then
the libxml code itself also need to be able to handle <libxml/tree,h> .
> The way I've done this with libraries in the past is to have an include
> directory for the library that I just path to during the library build
> with a "-I ../include" compiler flag - there's no reason why it has to
> match what the clients use, right?
Hum, wrong IMHO
> Anyway, it seems like this would simplify things...
The right way will be to have an include/libxml tree in the libxml
sources . I would rather not have to change the structure of the
CVS code base now, but I can probably manage to get the tarballs to follow
this structure automatically. I don't think I will change the CVs structure
(and hence my enviroment) soon, maybe when switching to libxml3 if it
ever get released :-)
I will play with the tarball generation,
Daniel
-- Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux XML libxml WWW Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind http://www.w3.org/People/all#veillard%40w3.org | RPM badminton Kaffe ---- Message from the list xml@rpmfind.net Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@rpmfind.net
This archive was generated by hypermail 2b29 : Tue Oct 03 2000 - 09:43:51 EDT