If it is the commit I made that Ian points out, I won't be able to debug it
very effectively. I don't have a msys2 build environment, and it seems to
work on all the platforms I do have.
On Wed, Jul 22, 2020 at 6:38 PM Wayne Stambaugh
wrote:
> No problem. I'll file a issue report as soon as I
No problem. I'll file a issue report as soon as I determine the guilty
commit.
On 7/22/2020 6:34 PM, Ian McInerney wrote:
> It was committed on July 3rd. I am not sure which commit is 100 behind
> the current head though, and I really don't want to kill my build
> directory by switching that far
It was committed on July 3rd. I am not sure which commit is 100 behind the
current head though, and I really don't want to kill my build directory by
switching that far back to find out.
-Ian
On Wed, Jul 22, 2020 at 11:27 PM Wayne Stambaugh
wrote:
> I'm running `git bisect` now from HEAD~100.
I'm running `git bisect` now from HEAD~100. Is it further back that
that? Given that mingw debug builds are painfully slow, it's going to
take a while.
On 7/22/2020 6:17 PM, Ian McInerney wrote:
> Try going right before c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first.
> The errors that Brian show
Try going right before c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first. The
errors that Brian showed at the beginning of the thread mention NETCLASS*
and shared_ptr stuff, and it looks like the last commit that touched those
Swig parts was from Jon on June 30th which moved that from pcbnew to the
co
Perhaps what I can try and do is a binary search for the last "working"
master.
I think that is within my abilities.
On 2020-07-22 6:00 p.m., Jon Evans wrote:
If you know a version that builds (you said late June worked) you can
do a git bisect against a commit from back then and eventually th
If you know a version that builds (you said late June worked) you can
do a git bisect against a commit from back then and eventually this
will tell you which commit changed the behavior
On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
wrote:
>
> You can't imagine how happy it makes me feel to know
You can't imagine how happy it makes me feel to know it isn't some
stupid little thing I did.
I don't know how I can help though. I can try building a release version
to confirm.
On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:
I've been playing around with this and there is definetly somethi
I've been playing around with this and there is definetly something
amiss. I don't get the build errors on release builds but I do see them
with debug builds (CMAKE_BUILD_TYPE=Debug). Downgrading swig from
4.0.2-1 to 4.0.1-3 didn't help. Interestingly the 5.1 branch builds
just fine so I suspect
Using this script
cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad
I get the same results
[ 98%] Built target qa_eeschema
C:/msys64/mingw64/bin/../l
Hi
all,
I completed the document to a point where I am unlikely to change it change it
on my own, without your feedback.
What is the usual way for a document to be reviewed, and hopefully to make its
way as a specification document ?
Should I create a MR on gitlab for discussion ?
Here i
I'll try it now but but the makefile generator script I used worked fine
for over a year until now.
On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
Did you try to use the normal makefile generator rather than the
eclipse one?
ons. 22. jul. 2020 01.37 skrev Brian Piccioni
mailto:br...@documen
12 matches
Mail list logo
