| mp | index | guide | reference |
an extension (a plugin, in mk/b.sh's own naming) is just a normal mp command script, dropped in plugins/ instead of src/. mk/b.sh installs plugins/<name>.pl as "mp.<name>", exactly the same way it installs src/<name>.pl -- same naming convention, same dispatch. mp itself does not distinguish an extension from a core command at run time; the only difference is plugins.list, generated at build time, which lets mp and mp help list extensions separately under their own heading.
nothing differs from writing a core command in src/. write it exactly the same way:
#!/usr/bin/env perl
use strict;
use warnings;
use FindBin;
use lib "$FindBin::Bin";
use mplib::config qw($CFG);
use mplib::util qw(fail ok);
use mplib::resolve qw(init);
my $flags = mplib::config::parse_flags(@ARGV);
mplib::config::load($flags);
init();
# ... your command, using whatever mplib::* modules you need ...
FindBin::Bin resolves to the directory the installed mp.<name> symlink lives in -- the top-level build output, where mp, mplib, and every other mp.<cmd> also live, not to plugins/ or src/ themselves. this line is identical regardless of which source directory your .pl file lives in.
see hello.pl in the plugins/ directory for a complete, runnable example -- run mp hello after a rebuild.
an extension named the same as an existing core command is skipped at build time. a warning prints, and the core command wins. an extension can never silently shadow a built-in.