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
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
*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
Not to throw a finger at anyone, but it has been quasi-optional for a while.
https://gitlab.com/kicad/code/kicad/-/blob/a146cd9e2e22c2b7100cb3c635f1e7733e346daf/common/CMakeLists.txt#L440-445
Although that just means that you won't see anything dirty if you
don't have lemon available on your
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:
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
Am 03.08.20 um 20:42 schrieb Steven A. Falco:
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?
In my eyes there is only one solution. Always prefer a dependency as
external required
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
Mark,
Am 03.08.20 um 20:19 schrieb Mark Roszko:
But this is also a nightmare.
I don't know what you mean here.
1. The main issue is the tool is not a real independent tool, it is only
maintained within sqlite and everyone using it outside of that are
"welcome to" by sqlite but the global
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
On 8/3/20 2:19 PM, Mark Roszko wrote:
>> 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
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
Just a reminder for developers, this should have happened before any new
dependency was even pulled into KiCad and not resolved after the fact.
If we ran into a situation where we had to spend a lot of time fixing
lemon or could not build it on a given platform, we would be force to
revert all the
On Mon, Aug 3, 2020 at 12:19 PM Mark Roszko wrote:
> > 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
> 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.
>Embedded code is quite in no way
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
Thanks for that Ian - that sounds great! Definitely a much cleaner
solution. Did you create a separate branch for this change or is it in
master?
Thanks.
On Mon, 3 Aug 2020 at 18:40, Ian McInerney wrote:
> I have now updated this so that we bundle the lemon parser code inside
> thirdparty
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
LOL, "lemon" in VCPKG is not Lemon the grammar generator, it's Lemon the
boost graph library.
And lemon grammar itself, isn't a real library. It's a single C file. It's
very unlikely to be accepted into vcpkg.
We may as well just build it on the fly in kicad
MSVC support is a work in progress so it's not that its not supported, it's
just someone needs to fix it ;)
On Sun, Aug 2, 2020 at 6:06 PM Roberto Fernández Bautista <
roberto.fer@gmail.com> wrote:
> Just tried your branch and unfortunately couldn't get it to compile on
> Visual Studio (even
Do you know if is called "lemon.exe" and is on the path by default? If it
isn't on the path, then CMake might have difficulty finding it. You can try
passing "-DLEMON=" in the CMake command line and I believe it will
use that path instead of searching for it. Other than that, I might need
Jon to
Just tried your branch and unfortunately couldn't get it to compile on
Visual Studio (even after a "vcpkg install lemon:x64-windows" and "vcpkg
integrate install")... I got the cmake error "lemon not found"
I know Visual Studio isn't officially supported but any ideas what I could
do to install
Yes, I have a branch on my fork [1] called "im/lemon" that can be used. It
can be found here: https://gitlab.com/imcinerney/kicad/-/tree/im/lemon. If
the build passes with that, it means lemon integration is working. CMake
should error during configuration if the lemon executable can't be found
Is there a branch packages can use to make sure their lemon integration is
working?
On Sun, Aug 2, 2020, 4:00 PM Ian McInerney wrote:
> Two new build-time dependencies are being added to the master branch for
> v6:
> * lemon - The lemon parser generator
> * GTK3 (linux only) - the GTK3
Two new build-time dependencies are being added to the master branch for v6:
* lemon - The lemon parser generator
* GTK3 (linux only) - the GTK3 libraries (only GTK3, not GTK2 - that is not
supported anymore). This is technically also a runtime dependency, but we
also need GTK3 for wxWidgets, so
25 matches
Mail list logo
