← Back to team overview

kicad-developers team mailing list archive

Re: New Build Dependencies: Lemon + GTK3

 

*sigh*... do it one way and people don't like it and then do it another way
and get more responses. I should just put it behind a
`KICAD_REGENERATE_LEMON_PARSER` flag that defaults to off to be done with
the damn thing. Then only people who actually want to regenerate the parser
grammars will need it.

The first lemon code was added in 2017, so the ship has sailed on this one.

-Ian

On Mon, Aug 3, 2020 at 8:01 PM 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
>

Follow ups

References