[Bro-Dev] Cmake for Bro

Jonathan Siwek jsiwek at ncsa.illinois.edu
Mon Oct 18 19:30:55 PDT 2010

> > CMake is fine with recursing on sub-projects and git can do
> > sub-modules, so I was expecting to leverage that functionality.
> If we can make this work, I'd be happy to do so. How would this look
> like, say for passing options to the sub-project's configure?

Take git out of the equation for now and say we downloaded the 'bro-all' source bundle containing the Bro super-project and all sub-projects.  The super-project's configure wrapper will have to be able to recursively look for additional options provided by any existing sub-projects, but only has to display and maybe validate them.  Setting a sub-project option via the super-project's configure wrapper will end up as a globally scoped CMake variable although only maybe a single sub-project cares about it.

If you consider how this works with git sub-modules, the only thing that's different is how you obtain the source bundle.  Here, cloning the Bro super-project will give you empty sub-module directories that one can init/update as desired:

    git submodule init <path>
    git submodule update <path>

The super-project just maintains sub-module pointers to a particular commit in their repository (probably a release tag).

> how would building separate packages for each module work then?

That stumped me.  After reading around a bit, it seems like CPack does not currently play nice with sub-projects (although it's on someone's TODO list).

So it looks like we can't just do a `make package` at the super-project level and expect it to spit out source & binary packages for independent sub-projects.  But if each module as a standalone works fine with CPack, I don't see why we can't just make a package generating script that iterates over modules, doing an independent out-of-source build and package creation for each.

The 'bro-all' package should still be possible via CPack if sub-projects had some extra logic to disable their own CPack settings when they detect that they're part of a super-project.

Thoughts on those approaches?

- Jon

More information about the bro-dev mailing list