kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>