> 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). >
It's not based on any technical consideration one way or another, but for me I would intuitively search in plugin.ini which is a central file with information about the plugin. In the other scenario, consider that a plugin may have many source files, yet only one of them will contain DRIZZLE_DECLARE_PLUGIN and I can't always know which file has that info. Always having it in plugin.ini sounds like good housekeeping. Like you listed below, either way you won't get rid of plugin.ini, since it contains build related data anyway. henrik On Thu, Jan 5, 2012 at 8:02 PM, Daniel Nichter <[email protected]> wrote: > 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 > -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
