On 10/24/2018 11:52 AM, John Beard wrote:
> On Wed, Oct 24, 2018 at 4:21 PM Wayne Stambaugh wrote:
>>
>> Does this mean that I do not have to merge 0001-CMake-tools-after-qa.patch?
>
> Correct. That patch does *not* need to be merged. master currently
> appears to build correctly.
>
>> I'm
On Wed, Oct 24, 2018 at 4:21 PM Wayne Stambaugh wrote:
>
> Does this mean that I do not have to merge 0001-CMake-tools-after-qa.patch?
Correct. That patch does *not* need to be merged. master currently
appears to build correctly.
> I'm wondering if it be more prudent to just move the
John,
Does this mean that I do not have to merge 0001-CMake-tools-after-qa.patch?
I'm wondering if it be more prudent to just move the tools/io_benchmark
tests into qa to prevent the build dependency issues.
On 10/24/2018 11:16 AM, John Beard wrote:
> Hi,
>
> It looks that was actually caused
Hi,
On 24.10.2018 13:48, John Beard wrote:
> In which case does flipping the CMake add_subdirectory order work
> (attached patch).
It may appear to work.
> If this *does* work, any clues as to why only MSVC cares?
The MSVC build had the qa subdirectory removed completely, because the
mock
Hi,
It looks that was actually caused by /qa being ignored in MSVC. This
has been undone, and now MSVC builds, so looks like we have all green
builds!
This probably works now because the following are, recently, commented out:
# add_subdirectory( pcb_test_window )
# add_subdirectory(
Hi all,
There's also (groan) an MSVC failure here. The includes for the file
in the new qa_utils lib aren't picked up, so it fails. The includes
*are* in my Linux build and are evidently also in the Mac/Mingw builds
as they work too. Could this be related to the top-level CMakeLists,
which goes
The Mac build was broken last night, a rebuild this morning didn't help,
but I'll trigger another one now and see how it goes.
Thanks folks!
On Tue, Oct 23, 2018, 5:44 PM Wayne Stambaugh wrote:
> Fixes the linux build. Yeah!!
>
> On 10/23/18 6:37 PM, Seth Hillbrand wrote:
> > Am 2018-10-23
Fixes the linux build. Yeah!!
On 10/23/18 6:37 PM, Seth Hillbrand wrote:
Am 2018-10-23 17:48, schrieb Jeff Young:
… Let's just hope the macos build doesn't choke.
He he. And it did. :)
I think I fixed it but someone might want to check that I didn’t do
something stupid.
Am 2018-10-23 17:48, schrieb Jeff Young:
… Let's just hope the macos build doesn't choke.
He he. And it did. :)
I think I fixed it but someone might want to check that I didn’t do
something stupid.
https://git.launchpad.net/kicad/commit/?id=4061f1cce3b177ceca894fd2f01e0eedd928273b
Just
On 10/23/18 5:48 PM, Jeff Young wrote:
> … Let's just hope the macos build doesn't choke.
He he. And it did. :)
I think I fixed it but someone might want to check that I didn’t do
something stupid.
https://git.launchpad.net/kicad/commit/?id=4061f1cce3b177ceca894fd2f01e0eedd928273b
> … Let's just hope the macos build doesn't choke.
He he. And it did. :)
I think I fixed it but someone might want to check that I didn’t do something
stupid.
https://git.launchpad.net/kicad/commit/?id=4061f1cce3b177ceca894fd2f01e0eedd928273b
Hey John,
Finally! That was easy. I'm guessing this is ready to merge or is
there anything else that needs to be done?
Cheers,
Wayne
On 10/22/2018 12:19 PM, John Beard wrote:
> Hi Wayne,
>
> Hmm, didn't expect that to be an issue! Try a ToStdString() for size?
>
> Cheers,
>
> John
> On
No problem. I have gone through this exercise a few times myself.
Let's just hope the macos build doesn't choke.
On 10/22/2018 1:30 PM, John Beard wrote:
> Thanks, Wayne! Sorry for all the drama with it. Hopefully I can learn
> from it for the libcommon tests.
>
> Cheers,
>
> John
> On Mon,
Thanks, Wayne! Sorry for all the drama with it. Hopefully I can learn
from it for the libcommon tests.
Cheers,
John
On Mon, Oct 22, 2018 at 6:14 PM Wayne Stambaugh wrote:
>
> It's merged. Thanks John.
>
> On 10/22/2018 1:09 PM, John Beard wrote:
> > Hi Wayne,
> >
> > Hurray!
> >
> > No extras
It's merged. Thanks John.
On 10/22/2018 1:09 PM, John Beard wrote:
> Hi Wayne,
>
> Hurray!
>
> No extras needed, this should be ready to merge. There are additional
> things we can do to enable testing of PLUGINs as opposed to the PCB
> parser, but this at least provides the base to build on.
Hi Wayne,
Hurray!
No extras needed, this should be ready to merge. There are additional
things we can do to enable testing of PLUGINs as opposed to the PCB
parser, but this at least provides the base to build on. This commit
is self-contained and includes the fuzzing documentation.
Cheers,
Hi Wayne,
Hmm, didn't expect that to be an issue! Try a ToStdString() for size?
Cheers,
John
On Mon, Oct 22, 2018 at 2:39 PM Wayne Stambaugh wrote:
>
> Hey John,
>
> You not giving up on this are you ;). I builds fine for mingw32 and
> passes all of the tests. However, the mingw64 build
Hey John,
You not giving up on this are you ;). I builds fine for mingw32 and
passes all of the tests. However, the mingw64 build fails with:
C:/msys64/home/wstambaugh/src/kicad-trunk/qa/pcb_parse_input/main.cpp:
In function 'int main(int, char**)':
Hi Wayne,
Since I'm out of better ideas and can't replicate the link failure on
Jenkins, here's a patch that uses the long list from pcb_test_window.
Presumably it's there for some reason, though there is no comment or
Git log clue that I can see.
Could you see if that works for you?
Cheers,
Hi Wayne,
That's pretty odd, the incantations are practically the same.
The only other difference between this and the other pcb-based
programs is this line:
add_dependencies( pnsrouter pcbcommon pcad2kicadpcb
${GITHUB_PLUGIN_LIBRARIES} )
Which I can't really see making the difference (I
Hey John,
Below is the verbose output. I hope it helps.
[ 98%] Linking CXX executable qa_pcb_parse_input.exe
cd
/C/msys64/home/wstambaugh/build32/kicad/trunk-release/qa/pcb_parse_input
&& /C/msys64/mingw32/bin/cmake.exe -E remove -f
CMakeFiles/qa_pcb_parse_input.dir/objects.a
cd
Hi Wayne,
Could you try to build with VERBOSE=1 so I can see what the failed link command
line looks like and compare to Jenkins?
Cheers,
John
On 17 October 2018 13:17:34 BST, Wayne Stambaugh wrote:
>Hey John,
>
>Close but no cigar. I'm still getting a single link error.
>
Hey John,
Close but no cigar. I'm still getting a single link error.
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe:
../../common/libcommon.a(marker_base.cpp.obj):marker_base.cpp:(.text+0xee9):
undefined reference to
Hi Wayne,
I think I might have fixed the ordering in the link libraries (at
least, it now builds on Jenkins).
This is just the first patch to focus on the build error, I'll rebase
the other docs stuff later if/when it works.
Cheers,
John
On Fri, Oct 12, 2018 at 7:58 PM Wayne Stambaugh wrote:
John,
This patch fails to link on windows. I've attached the build error.
Wayne
On 10/9/2018 9:53 AM, John Beard wrote:
> Hi,
>
> Here is an update patch that rebases over the commenting out of
> pcb_test_window, polygon_triangulation and polygon_generator and fixes
> a link error to do with
Hi,
This is an updated path sets that includes some extras on top of the
previously mentioned:
* TOC for the testing docs
* Update the io_benchmark tool to work with full paths.
* Add an in-memory io_benchmark case, which gives an approximate
baseline for how fast it could be without any IO
Hi,
Here's a quick patch to add some documentation about print-debugging
and trace. It's a follow-up to the fuzz tool, as there would be a
conflict in the MD file, as one section follows the other, so it needs
to go in afterwards, or otherwise be manually resolved.
Also includes a handy list of
Hi,
Here is an update patch that rebases over the commenting out of
pcb_test_window, polygon_triangulation and polygon_generator and fixes
a link error to do with base_screen.cpp.
Cheers,
John
On Mon, Oct 8, 2018 at 5:27 PM John Beard wrote:
>
> Sorry,
>
> I wrote "ms", I meant "us" - the
Sorry,
I wrote "ms", I meant "us" - the times are in the handful-of-millsecond range.
Cheers,
John
On Mon, Oct 8, 2018 at 5:24 PM John Beard wrote:
>
> Hi,
>
> This is a patch to add a test program that allows to parse a Pcbnew
> file from command line params or stdin. This means you can use
Hi,
This is a patch to add a test program that allows to parse a Pcbnew
file from command line params or stdin. This means you can use it for
fuzz testing.
I have done a little bit of fuzz testing so far (8 million execs,
about 70% of a cycle), and have not found any crashes, but I can make
it
30 matches
Mail list logo
