On Mon, Jan 22, 2018 at 12:38 PM, Jan Grashöfer <[email protected]> wrote:
> packaging some POC-seen scripts for the intel framework I was wondering > what would be the preferred granularity of Bro packages. In case of seen > scripts, it feels extreme to generate a package for every script. Might depend largely on the judgement of the packager, though I think the train of thought will end up being similar enough to provide guidelines like the following: If you think other packagers would depend on your scripts: it probably is better to provide separate packages where each offers the minimal feature set that one would expect to depend upon. If you don't think other packagers would depend on your scripts, then it may make sense to start with a single monolithic package, depending on what you think would be the best thing for your users. A deciding factor/question here could be "does the package have a performance impact by default". If no, a single package for multiple different APIs/features could work alright. If there are performance hits just by installing/loading the package, then it may be easiest for you to separate out those areas that require extra cpu utilization into distinct packages, or else you'd need to provide a user with a set of options (&redef's) that they can use to toggle different features of the monolithic package. > case it would be nice if one could check either for the availability of > certain identifiers (lookup_ID didn't work for me due to type clash in > comparison) or a package. Would the @if, @ifdef, @ifndef directives (e.g. for preprocessing away whole chunks of code) work for what you were trying to do? There's also maybe the `bro_script_loaded` event you could use to set a global flag and then branch on that in later code paths. - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
