kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Not to throw a finger at anyone, but it has been quasi-optional for a while.

https://gitlab.com/kicad/code/kicad/-/blob/a146cd9e2e22c2b7100cb3c635f1e7733e346daf/common/CMakeLists.txt#L440-445

Although that just means that you won't see anything dirty if you
don't have lemon available on your system, but will unconditionally
use lemon if it is available and that will of course cause a diff for
the developer that may have it installed.

Also it looks like it has been commed in and out a couple of times before.

On Mon, 3 Aug 2020 at 21:00, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> On 8/3/20 2:55 PM, Steven A. Falco wrote:
> > On 8/3/20 2:47 PM, Wayne Stambaugh wrote:
> >> On 8/3/20 2:42 PM, Steven A. Falco wrote:
> >>> On 8/3/20 2:37 PM, Wayne Stambaugh wrote:
> >>>> On 8/3/20 2:01 PM, Carsten Schoenert wrote:
> >>>>> Hello Ian,
> >>>>>
> >>>>> Am 03.08.20 um 19:39 schrieb Ian McInerney:
> >>>>>> I have now updated this so that we bundle the lemon parser code
> >>>>>> inside
> >>>>>> thirdparty and build it for ourselves (it is only 1 main c file that
> >>>>>> was released into the public domain). CMake then takes care of all
> >>>>>> the
> >>>>>> pathing for the template and executable file for the targets. This
> >>>>>> should work on all platforms now with no extra steps. It also means
> >>>>>> that there is no need to install lemon on dev computers anymore.
> >>>>>
> >>>>> unfortunately that is a typical thing how problems are getting
> >>>>> "solved",
> >>>>> simply embed the required third party code. From a security
> >>>>> perspective
> >>>>> this is mostly a nightmare as also typically nobody ever touches such
> >>>>> code again as it "works" for all times.
> >>>>> Please try to avoid this when *ever* possible and look for
> >>>>> alternatives.
> >>>>> For package maintainers a good alternative is to make the use of the
> >>>>> third party code optional. Means that a configure switch should be
> >>>>> available to so on the Linux side we can use the package versions.
> >>>>>
> >>>>> Embedded code is quite in no way traceable and make the work of
> >>>>> package
> >>>>> maintainers and of the security teams within Linux distribution even
> >>>>> more harder [1].
> >>>>>
> >>>>> So if not already the use of the lemon parser is configured in a way I
> >>>>> can chose to use a packaged version please consider to do so. Thank
> >>>>> you.
> >>>>>
> >>>>> [1] https://wiki.debian.org/EmbeddedCopies
> >>>>>
> >>>>
> >>>> I could not have said it better myself.  We now have programmed
> >>>> ourselves into a third party library maintenance issue.  In the future,
> >>>> all new dependencies should be run by the lead development team for
> >>>> discussion so we can plan how we want to handle them.
> >>>
> >>> What is the resolution?  Do I undo the dependency on the lemon parser
> >>> generator?  Or will there be a flag to select whether to generate or use
> >>> the canned one?
> >>>
> >>> I really don't like having this potentially work two different ways.
> >>> Then there could be bugs that only show up when using a newer lemon, or
> >>> that show up when using the pregenerated code.  It is best to have
> >>> exactly one way that this works.
> >>>
> >>>      Steve
> >>>
> >>
> >> Would the solution proposed in my last post be sufficient?
> >
> > It would avoid adding a flag, but you'd still have the potential problem
> > that different platforms could end up behaving differently, because some
> > are using an older (canned) parser, and some are using a newer
> > (generated) parser.  The risk in this instance is probably small, but as
> > a general principle, it is not good to have avoidable differences
> > between platforms.
> >
> > That said, I'll be happy to adapt to whatever the lead devs decide.
> >
> >     Steve
> >
>
> I wasn't suggesting a flag.  I was suggesting that if CMake cannot find
> an acceptable version of lemon on the system during configuration, fall
> back to building lemon from source.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp