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 <stambau...@gmail.com > <mailto:stambau...@gmail.com>> 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@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
