On Tue, Nov 30, 2010 at 3:15 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: > On Tue, Nov 30, 2010 at 8:46 PM, Paul Davis <paul.joseph.da...@gmail.com> > wrote: >> On Tue, Nov 30, 2010 at 1:25 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: >>> Following some kind of discussion on IRC, I would like to propose that >>> we had plugin handling to our build system. By plugin, I mean : >>> >>> - custom daemons >>> - handlers >>> - auth plugin, >>> ... >>> >>> It implys that we are abble to add them dynamically to the build (and >>> eventually handling their dependancies) and that we manage insertionin >>> ini files if it's needed. Anyone have some experience or example using >>> autotools for that ? The only page I've found for now is this one : >>> >>> - http://www.flameeyes.eu/autotools-mythbuster/libtool/plugins.html >>> >>> Do we need to wait rebar integration ? >>> >>> - benoit >>> >> >> Could you be a tad more specific on what your use cases might be? I >> don't think that autotools is going to be too amenable to what you're >> wanting to do. Also, why do you need to distribute your plugin source >> as part of CouchDB? >> >> Something I could see is adding a couchdb-config script that allows >> plugin build systems to place their code on the code path that gets >> loaded and then they can just use the default.d and local.d >> directories. >> >> Paul >> > I would like to mak e easy integration of plugin like geocouch, or > what any other kind of plugins like application server , or stuff like > it. > > so yes maybe something like a pkg-config or stuff like it could work. > In this case that would imply to distribute plugins as separate > packages right ? So the work would be to provide a common way to > packages to find couchdb includes ?
Exactly. I think this is probably the route you want to take. This should be fairly easy to implement based on how things like the couchdb script are made. > - benoit >
