I tried building it on the newest version of debian, and got this error: CMake Error at CMakeLists.txt:2 (cmake_minimum_required): CMake 2.8.12 or higher is required. You are running version 2.8.9
Why does it need version 2.8.12 of cmake? On 10/22/2014 02:39 PM, Siwek, Jon wrote: > If anyone has time/interest, I feel like the main components of Broker are > established now and deserving feedback/critique. Rather than try to detail > how things work here, it’s probably best for people to try figuring things > out from the repo (e.g. source code comments and unit test examples) and ask > questions about what's unclear. > > But it would be helpful to start a discussion on some of the planned features > and open questions. I’ll try literally pasting my TODO list and hope it’s > readable. The items are roughly ordered from most-certainty to > least-certainty. Feedback welcome generally, but particularly where > questions are posed. > > Broker TODO > =========== > > - C API > > - Python bindings > > - Persistent storage backend > > - SSL/IPv6 (dependent on actor-framework support) > > - Need/want overload or flow-control mechanisms? > > E.g. a simple policy for handling overload is to let a user specify > a threshold for how many items are allowed in a queue before new > messages are dropped. > > - In-place data store value modifications > > Plan to support increment/decrement on integral values. > Need any other operations? > > What to do when applying an operation to invalid data type? > Plan to just send error message back to sender and leave further > decisions up to them. > > - Data store support for optional expiry model > > What are the desired mechanims? Options: > > (1) Inserter may specify "expire this entry at time X" ? > > (2) Inserter may specify "expire this entry based on > create/read/modification access time" ? Going this route, > seems read access times would need to be shared across > clones (contradicts goal of lightweight, local read-access)? > > (3) Other hooks to make expiry conditional? > > - Data typing model > > Currently data in Broker is similar to Bro's threading::Value in > that full type info (from Bro's perspective) isn't available, just > the raw storage required for the types. Broker currently differs in > that it doesn't use any tag to distinguish between primitives that > share the same storage (e.g. enum/string or double/interval). > Interpretation of types is left entirely up to the receiver. > > Do we need more strict typing than this? Options: > > (1) Data holds additional type tag to suggest how to interpret > > (2) Fully implement separate Bro-types. > > Planning to try integrating w/ Bro as it is and see what specific > problems arise. I think (1) may end up being helpful, but maybe not > required and I'd like to avoid (2) if possible. > > - Bro integration > > Is Broker the default in Bro 2.4 ? That implies requiring C++11. > Also I'm requiring CMake 2.8.12+ and may be hard to go below 2.8. > Bro is still happy with 2.6.3. > > _______________________________________________ > bro-dev mailing list > [email protected] > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
