[Bro-Dev] Broccoli Python bindings

Jonathan Siwek jsiwek at ncsa.illinois.edu
Fri Nov 5 15:35:51 PDT 2010


I see three major areas to think about (some thoughts may be applicable to more than just Broccoli bindings).  Here's my decomposition:

1) The build system.

I don't see an issue right now with integrating the Python setup.py into CMake -- it should basically involve adding a custom target that delegates the build to setup.py at "make" time and then also delegating to setup.py at "make install" time.

So if we kept broccoli + bindings together, it seems like it's not hard for us to make it so that the bindings are built/installed by default (or selected) which differs from current autotools setup.

Separating bindings would offer a little simplification to its build system -- it can assume that broccoli is already built/installed.

2) The standard package management system per OS.

Seems like it's pretty standard for Debian packages to separate the bindings and library packages.

I don't think it's incredibly harder to generate separate packages even if you're working from a single source tree, but it does seem that if they were separate to begin with, then it simplifies the packaging process a little and makes it easier to add optional bindings for other languages.

3) The git repo organization.

If bindings are kept in their own repos, then don't we gain some flexibility on assigning maintainers that might differ from the broccoli maintainer?  How useful may that be?

The broccoli repo could also reference binding repos via git submodules so it's not like they're totally disconnected.  I think we should plan on using submodules more generally to keep coherence between Bro and subcomponents.

-----

In general, I think the goal is to decouple components that don't necessarily need to be maintained/developed as a whole unit while still appearing like a monolithic/coherent project to users.  The later part is accomplished by "shipping" to users either

a) via software repositories

Here the package dependencies will be set up such that they get the right set of packages for what they want.  (e.g. if they pick 'broctl' they should get 'libbroccoli', 'libbroccoli-python', 'bro-core' ...)

b) via an all source tarball distributed on Bro web site.

Here I think we have to ship source for all components and also supply a glue that makes the build system do the right thing for a user's chosen configuration.  (This is where things might get tricky)

-----

So to summarize: I'm leaning towards having the bindings in it's own repo + RPM/DEB package since there's minor benefits and also fits in with the spirit of what we're doing everywhere else.  Maybe I'll have more thoughts Monday after talking with Adam, but I wanted to get these ramblings out there for others to challenge/discuss.

- Jon



More information about the bro-dev mailing list