[
https://bro-tracker.atlassian.net/browse/BIT-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20509#comment-20509
]
jiamo commented on BIT-1317:
----------------------------
Hi, after I build a base one I want build plugin, but goto the aux/plugins and
make get error:
make -C dataseries
make[1]: Entering directory '/home/ikfb/Git/bro/aux/plugins/dataseries'
Build Directory : build
Bro Source Directory : /home/ikfb/Git/bro
-- Bro executable : /home/ikfb/Git/bro/build/src/bro
-- Bro source : /home/ikfb/Git/bro
-- Bro build : /home/ikfb/Git/bro/build
-- Bro install prefix : /usr/local/bro
-- Bro plugin directory: /usr/local/bro/lib/bro/plugins
-- Bro debug mode : false
-- Could NOT find Lintel (missing: Lintel_LIBRARIES Lintel_INCLUDE_DIR)
-- Could NOT find DataSeries (missing: DataSeries_LIBRARIES
DataSeries_INCLUDE_DIR)
CMake Error at CMakeLists.txt:32 (message):
DataSeries not found.
Do we have a docement how to build extern plugins and install them now?
> Integrate standard plugin into Bro's build and install process
> --------------------------------------------------------------
>
> Key: BIT-1317
> URL: https://bro-tracker.atlassian.net/browse/BIT-1317
> Project: Bro Issue Tracker
> Issue Type: New Feature
> Components: Bro
> Reporter: Robin Sommer
> Fix For: 2.5
>
>
> Right now, plugins in aux/plugins/* need to be build and installed manually.
> That's fine for those currently there (netmap, elastic search, data series),
> as they are quite specific. However, once we start moving more standard
> functionality over into plugins (say, GeoIP support), that will get more
> cumbersome, as now everybody wanting that stuff will need to do the
> additional step, which is easy to miss.
> However, it's not clear to me right now what's a good way of integrating the
> plugins more tightly would be. We could turn a few (or all?) on by default
> and build them along with Bro if their dependencies are satisfied. But that's
> tough to implement, as the plugin build process is really completely separate
> from Bro's. So we would need to pass configure parameters over, run their
> builds, run their installs, run their tests, and catch any errors along the
> way.
> I'm setting this to 2.4 in case we can still come up with a good strategy
> here. But more likely this is something to punt on right now, as we don't
> have a pressing use case anyways. There's also the related topic of a broader
> notion of modules that a future CPAN might manage, and how we combine all
> that.
--
This message was sent by Atlassian JIRA
(v6.5-OD-01-120#65000)
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
