Bug 242442 - cad/kicad: Attempt to open a .lib file causes asserts
Summary: cad/kicad: Attempt to open a .lib file causes asserts
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Christoph Moench-Tegeder
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-05 05:31 UTC by Yuri Victorovich
Modified: 2019-12-05 22:26 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (cmt)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer 2019-12-05 05:31:40 UTC
> $ 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.
Comment 1 Yuri Victorovich freebsd_committer 2019-12-05 05:32:29 UTC
kicad-5.1.5,2
Comment 2 Christoph Moench-Tegeder freebsd_committer 2019-12-05 22:26:08 UTC
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.