Arjen Lentz <arjen@openquery.com> writes:
On 26/03/2010, at 7:13 PM, Kristian Nielsen wrote:
I wanted to see if there was something I could do to help getting oqgraph-in-mariadb moving again.
Great!
Ok, I need pointers to two things to start: 1. Latest OQGRAPH branch. I see several OQGRAPH-related branches here: https://code.launchpad.net/maria https://code.launchpad.net/oqgraph On which branch should I base my work, to be sure I don't work on an obsolete tree? 2. Pointer to the Launchpad branch for the fixed boost graph library. Discussion follows ...
For issue 1 + 2, if you can point me to what the bug in boost is I could look into making an autoconf test for this bug, and only enable OQGraph by default if a boost without the bug is found. Or failing that, if you can supply me with the minimum version of boost needed, I could try for an autoconf test that does not enable OQGraph by defaults on hosts where it breaks the build.
That would simply mean that OQGRAPH does not get built anyway.
Maybe I did not explain the problem here properly. The primary issue is that adding OQGRAPH must not break the default source build for the user trying to build herself. The current OQGRAPH tree breaks this. A normal ./configure && make will try to build OQGRAPH if an old version of Boost is present, and MariaDB will fail to build. This needs to be fixed. Hence the need for knowing the minimal boost version, so we will not attempt to build OQGRAPH by default on systems where that will fail. Avoiding to build (with a nice message for the user) on systems with buggy boost would be a bonus, but not a requirement. I suggest to simply not have ./configure attempt to build OQGRAPH by default at all. There is hardly any point given that a special install of boost is a requirement (until fixed boost is upstream). Instead make OQGRAPH non-default, enabled by the usual --with-plugin-oqgraph option. I will look into doing this. (This will make my life somewhat harder for Buildbot, as I will then have to do some magic to have it build OQGRAPH only in branches where it is available; hopefully I can solve that somehow). After this issue is solved, the next step is to consider how to be able to actually build OQGRAPH somewhere ;-)
A third solution could be to just install the patched boost in /usr/local/include on the build VMs. This should work, though it's not 100% nice in terms of providing full source code (you could always release OQGraph as GPL with a boost linking exception if we're really paranoid).
I don't see this at all. OQGRAPH is already GPL. And the patched library is in the oqgraph project repos on Launchpad. So it's all there anyway.
Agree, I don't see a problem either. This seems like a feasible way forward to me. So unless you have better suggestions, I'll try with this, once I have the pointer to the correct branch on Launchpad for Boost.
A fourth solution could be to include the graph part of boost (with bug fix) as a patch in ourdelta/bakery/, just like the other patches already there.
That's possible.
(You did not say if you prefer this solution over the previous, so I assume you have no preferences?). - Kristian.