MySQL Bugs: #44722: headers required to build plugins are not installed

Bug #44722	headers required to build plugins are not installed
Submitted:	7 May 2009 14:46	Modified:	30 Mar 2012 11:15
Reporter:	Antony Dovgal	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S3 (Non-critical)
Version:	5.1.0+	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	API, headers, plugin

Description:
The current situation with plugin API is quite disappointing - in order to compile a plugin one needs full MySQL sources configured using the same configure options as were used to compile installed MySQL server.
The sources are required because MySQL installation doesn't contain headers that are considered 'private', but in the same moment are required to build engine plugins.

Installing all the headers is one way to fix this, another way is to rewrite headers so that private part would be still private, but plugin API could function without need for the sources.

The problem was discussed in this thread: http://lists.mysql.com/internals/36428 and MySQL developers have decided to go the second way, see http://lists.mysql.com/internals/36546.

It was said that it never hurts to fill a bug report, so here it is.

How to repeat:
Try to build an engine plugin - you'll see how complicated and error-prone the procedure is.

So, let's consider this a reasonable request to rewrite the headers in order to separate server private code from plugin code.

6.0-beta? Isn't it.. well.. a bit too late?
Like 2 years from now?

it can easily happen earlier (or later).
Bug watch WL#4739 when it's done we'll know more about this bug.

It seems I was a bit too optimistic with about my expectations - it's been almost 3 years and the situation hasn't changed in a bit.
In some cases it even got worse since you've been rearranging the headers (instead of mysql_priv.h I now have to include sql/field.h, sql/structs.h, sql/handler.h), renaming functions (hash_get_key -> my_hash_get_key, my_free(a, b) -> my_free(a) etc.) and have switched to cmake-based build system, breaking third-party storage engines again and again.

Antony,

First of all thanks for your patience.
As the discussion you've quoted above says the SE API was never considered fixed or public.
What you're asking for can't be delivered by the current mysql code structure (as Serg correctly explained in the discussion).
And moving from the present code structure to a more modular one is not an easy process.
Which is not to say that we don't understand the problems with the current code structure and the hudles it's putting on the developers. We are suffering from the same problems internally as well.
That's all I can say right now. Your problem is not forgotten nor is it underestimated.

>What you're asking for can't be delivered by the current mysql code structure (as Serg correctly explained in the discussion).

This is not quite correct. Apparently you can do it (I even provided a patch for that), but you don't want to do it because 'by explicitly providing the definitions we're saying "<skip> Whatever happens - it's all your
fault."' (c) Sergey.

I personally see absolutely no problem if you just install all the headers and make it MY responsibility to use them in the right way.
Keeping a stable API would help, of course.

>And moving from the present code structure to a more modular one is not an easy process.

Yeah, I can totally understand that.
But the situation won't improve if you do nothing except repeating how complex the solution is.

See you in 3 years? =)