On Mon, Aug 3, 2020, 10:48 AM Wayne Stambaugh wrote:
> I'm not ready to drop 32 bit builds for V6. I still think there are
> enough 32-bit users to warrant supporting it for one more release. It's
> something we can discuss for V7.
>
If we keep 32 bit builds on mingw2, does that mean that we
I think it has always been like this. But there is only one user grid
selection, so I am not sure it is a real issue.
On Mon, 3 Aug 2020 at 17:02, Brian Piccioni wrote:
>
> Hello
>
> While working on geographic annotation I note that it is possible to set
> different x and y for the user grid
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'm not ready to drop 32 bit builds for V6. I still think there are
enough 32-bit users to warrant supporting it for one more release. It's
something we can discuss for V7.
On 8/1/20 10:20 PM, Mark Roszko wrote:
> Only just noticed this
>
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
Hello
While working on geographic annotation I note that it is possible to set
different x and y for the user grid but the choice menu only shows one
(I think the x).
I also notice that in footprint_preview_panel.cpp it only takes one of
the values.
It seems the user grid setting menu is
21 matches
Mail list logo
