On 04.04.2009 00:15, Konstantin Osipov wrote:
> * Antony Dovgal <tony@stripped> [09/04/03 18:53]:
>> > Opening up the class headers means you are creating a pact between you
>> > and your developer base. You are saying "this is an API, we promise to
>> > inform you of changes, and to not make them lightly". Is this where
>> > the MySQL codebase is today?
>> I'm definitely not the right person to answer such questions.
> Well, it isn't. And this is why there is hesitation with going
> forward with your "lazy" approach.
The point is that my 'lazy' (I agree with the term) approach does not open any server API
- *it's already open*.
In order to build a plugin I need full MySQL sources, which means I already have access to
all the headers and private structs.
And if my plugin uses some private server struct, you can't change the struct without
breaking the plugin -
this is the current situation and my patch doesn't change it in any way.
The patch addresses another problem - I need to configure the sources using the same
options that were used for MySQL server.
This isn't a problem when you build both plugin and server from sources, but what if the
server was installed from RPM?
Can I install appropriate -devel package with headers and be sure that my plugin will
compile and work ok?
Nope, I still have to have the sources and make sure I ./configure in the right way.
This is what I'm trying to fix.