For example, in slave/plugin.ini:
sources=module.cc replication_slave.cc queue_thread.cc queue_consumer.cc
queue_producer.cc sql_executor.cc replication_schema.cc
headers=replication_slave.h queue_thread.h queue_consumer.h queue_producer.h
sql_executor.h replication_schema.h
libs=${top_builddir}/libdrizzle-2.0/libdrizzle-2.0.la
Other plugins have that kind of stuff too. It seems DRIZZLE_DECLARE_PLUGIN
can't accommodate that. So I would vote for putting everything in plugin.ini
and using only the minimal DRIZZLE_PLUGIN. If we change plugin systems, then
hopefully it will either be compatible with the existing plugin.ini files or we
can just write a script to convert the well-formatted plugin.ini files.
So to summarize the debate:
1. There's two plugin interfaces DRIZZLE_PLUGIN and DRIZZLE_DECLARE_PLUGIN
2. The short one (DRIZZLE_PLUGIN) puts all metadata in plugin.ini (author,
version, etc.)
3. The longer one (DRIZZLE_DECLARE_PLUGIN) puts some metadata (author, version,
title) in the source code but other metadata (sources, headers, libs, etc.)
must still be in plugin.ini
4. Brian favors the longer one because "projects churn module/plugin API's with
some frequency. Keeping it in source makes it easy to port to whatever the
current flavor of interface is without much effort."
5. I (and Andrew) favor the the shorter one to centralize all metadata in one
place, plugin.ini
Does anyone else have an opinion on this? I'd like to change this while in the
process of making plugin names uniform (see my original email in this thread).
-Daniel
Le 15 déc. 2011 à 15:20, Henrik Ingo a écrit :
> On Thu, Dec 15, 2011 at 5:37 PM, Daniel Nichter <[email protected]> wrote:
>> Is it possible to put everything in the source file?
>
> It depends what you mean by "everything". Most of the stuff in a
> plugin.ini file is consumed by config/pandora-plugin for its own
> purposes (it creates autoconf input files for us). The author and
> module name fields go into drizzled/plugin.h, where you'll see two
> familiar macros:
>
> #define DRIZZLE_PLUGIN(init,system,options) \
> DRIZZLE_DECLARE_PLUGIN \
> { \
> DRIZZLE_VERSION_ID, \
> STRINGIFY_ARG(PANDORA_MODULE_NAME), \
> STRINGIFY_ARG(PANDORA_MODULE_VERSION), \
> STRINGIFY_ARG(PANDORA_MODULE_AUTHOR), \
> STRINGIFY_ARG(PANDORA_MODULE_TITLE), \
> PANDORA_MODULE_LICENSE, \
> init, \
> STRINGIFY_ARG(PANDORA_MODULE_DEPENDENCIES), \
> options \
> }
>
> According to grep this is the only place where PANDORA_MODULE_AUTHOR
> appears, didn't check the others.
>
>
> So it seems Drizzle supports both of, and code comments do not decree
> or deprecate either one of, the following:
>
> - Module meta data (author, name, title, version, license) is
> specified in plugin.ini. In the c++ source you can omit them by using
> the shorter DRIZZLE_PLUGIN macro.
>
> - Module meta data is specified in DRIZZLE_DECLARE_PLUGIN macro, and
> you can omit it from plugin.ini.
>
>
> henrik
>
>> If not and we're stuck
>> with plugin.ini files, then we'll have to port that info in any case (if the
>> plugin API changes), so porting a few extra lines doesn't seem bothersome,
>> especially if all the info to be ported is in one file with a common format.
>> My other reason for preferring the plugin.ini file is that it's slightly
>> easier to parse.
>>
>> -Daniel
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
