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 Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
