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
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
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
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
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
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
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'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
Did you try to use the normal makefile generator rather than the eclipse
one?
ons. 22. jul. 2020 01.37 skrev Brian Piccioni :
> FWIW, I re-cloned Kicad master into an empty directory, created a new
> build directory, ran the standard build script
>
> cmake -DCMAKE_BUILD_TYPE=Debug \
> -G
13 matches
Mail list logo
