[Bro-Dev] Configure Wrapper (Cmake for Bro)

Jonathan Siwek jsiwek at ncsa.illinois.edu
Mon Nov 1 14:25:04 PDT 2010


I wanted to revisit wrapping the Bro CMake configuration into an autotools-like configure script:

> > * require build options to be set via a BuildOptions.cmake file, to
> > be copied into build directory by user and edited as desired. If
> > non-existent in build directory, the top-level one can be copied
> > automatically.
> 
> Would that mean that setting any build option (even just --prefix)
> involves editing the BuildOptions.cmake and copying it to the right
> place? If so, I'm not sure I really like that, it sounds cumbersome
> and quite non-standard.
> 
> One alternative which I think wasn't discussed but I have seen with
> other cmake-based projects is providing a "configure" wrapper script
> with a standard autotools-like interface that then sets up the build
> accordingly for cmake. I'm not quite sure how others are doing that,
> but can't we just have such a wrapper *create* the
> BuildOptions.cmake? The wrapper would essentially be just a big
> switch-statement printing out the right values.

As a developer testing different build configurations I definitely found it to be cumbersome to have to edit a file to change settings, so I'll agree that providing the configure wrapper has that added benefit (the major drawback still is that it's extra maintenance).

But I've come to realize that having the wrapper write build options to an intermediate file is an unnecessary indirection and redundant since the CMakeCache.txt (CMake automatically generates this) serves pretty much the same purpose.  Instead the wrapper can just directly interface with CMakeCache.txt by invoking `cmake -D <var>:<type>=<value>`

So I'm going to remove the intermediate BuildOptions.cmake file unless someone can think of legitimate uses for it.  Leaving it seems like it will just add an extra point of confusion.

- Jon



More information about the bro-dev mailing list