maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Arjen Lentz <arjen@xxxxxxxxxxxxx> 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.