Currently Bro defines it's own integer types (uint32, uint64,
bro_int_t, etc.) with the help of ifdefs and autoconf. Furthermore, Bro
uses ifdef to decide which printf format to use for formatting 32 and 64
As part of the planned event engine cleanup, I suggest that we
a) make sure that everything that can potentially overflow (counters)
are 64 bit wide (in addition to enabling --enable-int64)
b) use the standard type uint64_t, int32_t, etc. from inttypes.h (*)
c) use the PRI* macros for *printf formatting (also from inttypes.h)
(*) inttypes.h is part of both, C99 and POSIX. See
Gregor Maier gregor(a)icir.org
Int. Computer Science Institute (ICSI) gregor(a)icsi.berkeley.edu
1947 Center St., Ste. 600 http://www.icir.org/gregor/
Berkeley, CA 94704
I'm including the Apple "Pages" file and a rendered PDF for those without Pages. I split all of the comments intended for the script author out into comments along the left side and left the comments that the script author might write for the benefit of the script user or future developer inline in the script.
I still have not addressed a style for variable and function documentation to be auto parsed yet.
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.