So Johanna and I just white-boarded a somewhat more generic approach that we believe would work well to cover the various use-cases without hardcoding much in terms of structure at all.
The brief summary is that we would allow people to specify how to set BROPATH and BRO_PLUGIN_PATH, and how to build their binary stuff; and otherwise don't impose any furher structure on them, just some defaults. Here's the idea in more detail: - We stay with the model of a "container" that can carry both scripts and binary plugins. (We could now maybe go back to "package" again; but I'll keep using "container" in the following). - The user's git repository *is* that container, however we don't enforce much of a layout on that at all, just some defaults they can change if desired. I'll call the disk location of the local clone for a user repository <repo>. - At install time ("cban install" or whatever) <repo> gets copied into a subdirectory <name> at a global location <install-base> ("cp -rp <repo> <install-base>/<name>"). Uninstallation means removing that installation directory. - For shipping scripts: - We simply add <install-base> to Bro's BROPATH. That means one can now put "@load <name>" into local.bro and Bro will look for a __load__.bro inside the top-level container directory. That file can do whatever it wants for loading further scripts located anywhere inside the container. One can also load individual top-level scripts that way through "@load <name>/foo.bro". - If one wants to locate the scripts somewhere else inside the container, optional meta information can set a different BROPATH relative to the top-level directory. For example, to put them into "<repo>/scripts", one would specify as meta information "bropath=scripts". - For shipping binary plugins: - Through meta information, we let the author specify a build command to build all their binary stuff, such as "./configure && make && make test". The command line client runs that command inside <repo>. - Per default, we expect that build command to create a directory <repo>/build that contains a binary plugin. We add <install-base>/<name>/build to BRO_PLUGIN_PATH. - If one wants to locate the plugin elsewhere, optional meta information can set a different BRO_PLUGIN_PATH. For example, to put it into "<repo>/compiled/cool_plugin", one would specify as meta information "pluginpath=compiled/cool_plugin". - In addition, we believe we should go back to require that minimal set of meta information that we discussed earlier: a container would need at least a name, a contact, a version, and a licence. For the optional meta information described above, we preset defaults: bropath=. pluginpath=./build buildcmd= # Empty means: nothing to build. So, examples: 1. A container with just a single script pulled in through "@load foo". <repo>/META name=foo version=1.0 license=bsd contact=f...@.bar.com <repo>/__load_.bro event bro_init() { print "Foo!"; } 2. A container with multiple scripts all loaded through "@load foo". <repo>/META name=foo version=1.0 license=bsd contact=f...@bar.com <repo>/__load_.bro @load ./script1 @load ./script2 <repo>/script1.bro event bro_init() { print "Foo1"; } <repo>/script2.bro event bro_init() { print "Foo2"; } 3. Same as (2), but the scripts now in a subdirectory scripts/: <repo>/META name=foo version=1.0 license=bsd contact=f...@bar.com bropath=scripts <repo>/scripts/__load_.bro <repo>/scripts/script1.bro <repo>/scripts/script2.bro 4. A binary plugin: <repo>/META name=foo version=1.0 license=bsd contact=f...@bar.com buildcmd=./configure && make && make test <repo>/configure <repo>/src/* <repo>/tests/* (The skeleton that init-plugin creates works for this directly already, except for the meta information.) 5. A binary plugin with different build command and location: <repo>/META name=foo version=1.0 license=bsd contact=f...@bar.com buildcmd=build-all-my-stuff.sh pluginpath=compiled/cool_plugin <repo>/build-all-my-stuff.sh <repo>/<any-other-stuff-that-the-shell-scripts-needs> -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev