I believe the culprit here is the CMake revamp removing support for BRO_PLUGIN_BASE, but opening a ticket in the template repo as I'm not sure we want to reintroduce that and/or maybe there's a better idea how to go about that.

Today, when creating a package with a plugin feature, there's two scripts directories - top-level and plugin specific.

~/foobar$ tree scripts/ ./plugin
scripts/
├── __load__.zeek
└── main.zeek
./plugin
├── scripts
│   ├── __load__.zeek
│   ├── __preload__.zeek
│   └── types.zeek
└── src
    ├── config.h.in
     ...

When running zkg install (or make install within build), the scripts/ directory next to the installed lib/ directory contains the content of the top-level ./scripts directory rather than ./plugin/scripts (which would have the __preload__.zeek or types.zeek files). This seems wrong: The plugin/scripts should've been sued for this.

Concretely, after a make install within ./build:

/opt/zeek-6.2/lib/zeek/plugins/Zeek_FooBar/
├── COPYING
├── lib
│   ├── bif
│   │   ├── foobar.bif.zeek
│   │   └── __load__.zeek
│   └── Zeek-FooBar.linux-x86_64.so
├── README
├── scripts
│   ├── __load__.zeek
│   └── main.zeek
├── VERSION
└── __zeek_plugin__

So 1) we won't have and load the right __load__.zeek, __preload__.zeek and types.zeek files automatically when the shared library is loaded and also 2) Zeek automatically attempts to load the top-level ./scripts directory instead (which should require an explicit @load).

$ zeek -e 'event zeek_init(){}'
Hello world!

@ckreibich - thoughts? Bringing back BRO_PLUGIN_BASE could work, but its usage seems brittle (as this ticket proofs).

I don't know. Chatting with @bbannier and @J-Gras this is pretty messy. Given there have been no complaints so far, I wonder if we can do some more drastic changes rather than trying to fix anything up.