> $ kicad boosterpack.lib
> /wrkdirs/usr/ports/cad/kicad/work/kicad-source-mirror-5.1.5/common/project.cpp(83): assert "m_project_name.GetExt() == ProjectFileExtension" failed in SetProjectFullName().
Same message containing "/wrkdirs/usr/ports/cad/kicad/work" is also displayed in the popup.
The build directory "/wrkdirs/usr/ports/cad/kicad/work" should never be memorized and used during the runtime in any way.
I'm not sure if it's in some documentation somewhere, but kicad's (rather rudimentary) command line handling only expects project files on the command line, not library files. Further, file name extensions are strictly enforced by using asserts (methinks this is an abuse of run time assertions and demonstrates lack of effort in error handling and reporting), which looks like a dubious design decision (hey, names are .. just names. Use magic markers for content). I won't change that in our builds, as deviation from intended upstream behaviour is a can of worms to be avoided.
(In reply to Yuri Victorovich from comment #0)
> The build directory "/wrkdirs/usr/ports/cad/kicad/work" should never be memorized and used during the runtime in any way.
That's not "used" - it's brought to you by the powers of wxWidget's wxASSERT() ("... abuse of assertions and ... lack of effort in ... error reporting") harnessing C's __FILE__, which holds the name of the current compilation unit as known to the compiler at compile time.
Alltogether, this is not a bug we can or should fix here, but "works as intended by upstream", even if those intentions are arguably shortsighted.