← Back to team overview

kicad-developers team mailing list archive

Re: New Build Dependencies: Lemon + GTK3

 

I think we should just get the updated solution merged that Ian made.
It does not use system lemon and there for not require it as an
external dependency, but addes the source file directly and fixes the
issue with the dirty flag. If someone want to make it be able to
switch to a system lemon if found, they should probably just base
their proposal on top of Ians merge request. Lets get it in and move
forward.

https://gitlab.com/kicad/code/kicad/-/merge_requests/318

On Mon, 3 Aug 2020 at 22:03, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
>
>
> On 8/3/20 3:31 PM, Ian McInerney wrote:
> > *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.
>
> I'm fine with this option as well.  It fits with how we handle images
> where only developers need to use the grammar generator mode.
>
> >
> > 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
> > <mailto: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
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> >     More help   : https://help.launchpad.net/ListHelp
> >
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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


References