I'm working on an ebuild for the native xml version of Berkeley DB, dbxml. It's a little tricky because that compile requires access to a compied xerces-c source tree. One suggestion I've had is to add on to the xerces-c ebuild through a use flag. In more detail, bdbxml relies on a library called XQilla that is an extension to xerces-c. I propose that xerces-c build and install this library via the xquilla use flag. A separate dbxml ebuild would take care of the rest of the compile, linking to xqilla as installed by the xerces-c ebuild. The is trying to solve the problem of keeping the various versions in sync. I don't want to install a separate copy of the xerces-c libraries, but otherwise I won't be able to ensure that I compile and link against the same ones. Such such a plan be acceptable to the xerces-c maintainer? If so I will submit such an ebuild.
A quick correction: the library is called XQilla (not XQuilla).
Well, I really don't want to include the XQilla package in xerces-c. While trying to build XQilla, it seems that some headers from xerces-c are missing: In file included from src/context/impl/XQContextImpl.cpp:62: src/context/impl/../../dom-api/impl/XPathDocumentImpl.hpp:20:48: error: xercesc/dom/impl/DOMDocumentImpl.hpp: No such file or directory
Well, patching the xerces-c ebuild to install the following (as private marked) header files to /usr/include/xercesc/dom/impl seems to be sufficient to compile XQilla: DOMAttrImpl.hpp DOMAttrMapImpl.hpp DOMCasts.hpp DOMCharacterDataImpl.hpp DOMChildNode.hpp DOMDeepNodeListPool.hpp DOMDocumentImpl.hpp DOMDocumentTypeImpl.hpp DOMElementImpl.hpp DOMElementNSImpl.hpp DOMNodeIDMap.hpp DOMNodeImpl.hpp DOMNodeListImpl.hpp DOMParentNode.hpp DOMRangeImpl.hpp DOMTextImpl.hpp DOMTypeInfoImpl.hpp DOMWriterImpl.hpp
For whatever reason I didn't get followup messages from bugzilla... Anyway, I'm attaching the ebuild and the diff that make it work perfectly well for me. I didn't need to patch anything. Maybe it was just my system, or maybe it was a different distribution of xqilla. I'm figured I'd use the distribution that comes with dbxml since that's the only thing I know of that uses xqilla anyway. The reason I suggest including xqilla in xerces-c is because they seem to be closely related and I'm worried that building against an unpatched xerces-c source while linking against potentially gentoo-modified libraries may be problematic.
Created attachment 111481 [details] xerces-c-2.7.0-r2.ebuild
Created attachment 111484 [details, diff] diff
Ok, I hope this is clear: I won't include xqilla in the xerces-c ebuild. Not even if you provide a patch. Sorry.
That's fine. I thought it was because you found that it wasn't compiling cleanly, so I provided my ebuild in which it was compiling cleanly with no patch. *nod*
XQilla ebuild is nearly ready; I'm just waiting on confirmation of one thing from upstream. If this bug is reassigned to developer-wanted I'll commit the ebuild to sunrise.
Created attachment 111808 [details] xqilla-1.0.1.ebuild Added ebuild to sunrise.
Created attachment 112111 [details] xqilla-1.0.1.ebuild Just syncing against the version current in the sunrise queue.
Comment on attachment 112111 [details] xqilla-1.0.1.ebuild Sunrise ebuilds have now eclipsed that which is attached here.
I had to add a "export " before the XERCESROOT declaration in the ebuild before it would compile, otherwise it would complain about XERCESROOT variable not being set.
I ran into such a problem in an unrelated ebuild that I wrote last week. I wonder if something has changed portage. Anyway, Vincent, be advised that there is a newer release of xqilla that has been out for a while. If you have a chance you might want to try copying the ebuild to xqilla-2.0.0.ebuild to see if it compiles cleanly. If you do, please report back here. I'm not doing XML DB stuff in my job these days, so I don't have time to test it myself.
(In reply to comment #7) > Ok, I hope this is clear: I won't include xqilla in the xerces-c ebuild. Not > even if you provide a patch. Sorry. > Dear Tiziano, i think you can't hold this position: For a project i need the current "dbxml-2.4.13" . This depends on "xqilla-2.1.2", what itself depends on "xerces-c-2.8.0". The former xqilla-1.0.1 "just" need some closer access to the xerces sources to build up. This have been solved by Chris Carlin with a "local compile" of the xerces sources while building xquilla. But the current xquilla-2.1.2 needs to patch the xerces-c with two files included in the upstream(!) source tarball. And dbxml-2.4.13 need *this* patched version of xerces-c (i.e. access to this version of shared libs) to start compiling (and therefore probabely for running, too). I think you have to withdraw your statement and we have to enhance the ebuild of xereces with an xqilla use-flag to opionally include this patches in a propper way.
This is now in the tree...
Closing. Dear Guido, I'm pretty sure that this is a problem with the language, but I want to say it nevertheless: I am _not_ paid for my Gentoo work and thus I do _not_ have to do anything you tell me to. Cheers, Tiziano
Dear Tiziano, i'm sorry for that! I'm sure that's just a problem of language: Of course you haven't to do anything for my call even if you would payed for Gentoo, because i don't pay anything to it, too. I thought you reject the request of Chris because you're the Gentoo maintainer of the xerces-c and therefore have to commit any changes. I just wanted to ask, if you may consider you decision, not to tell you anything. But for the others i have to point out, that -- before you add your comment -- you already did *MUCH* more than we have expected: *YOU* have implemented the changes under discussion into xerces-2.8.0, set up a adjusted euild for xqilla-2.1.2 and even move it from the sunrise repository to the main portage tree. Thank you for the *GREAT* support and feel free to criticize anything you want. With credits Guido
