[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