kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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.