Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Hello all,

one question might have drowned a bit: is there any particular reason 
why kicad builds executables and libs into their own private directories 
in first place rather than into a "bin" directory that I should be aware 
off? It will help all considerations when I don't miss the important 
stuff :)


Michael

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

This is what I was looking for.  Thank you for taking the extra effort
to figure this out.

Cheers,

Wayne

On 12/7/2016 1:38 PM, Michael Steinberg wrote:
> Hello,
> 
> sorry for the noise, yes, the test cases can themselves be organized
> into suites inside the test-executable with Boost.Test (Test-trees so to
> say), so we're free to build a gazillion of executables per module or
> collect them inside one executable and add a CTest-test for each suite
> which is then run with the corresponding runtime arguments instead. We
> could use this functionality also for other things. Orson pointed out
> that having multiple executables will help speeding things up in case of
> distributed parallel builds.
> In any case reorganizing stuff will be rather painless due to all the
> freedoms. Since I'm seeing it all only from the viewpoint of a developer
> people running build machines should have the last word to say, how to
> set it up so it blends in nicely.
> 
> Cheers!
> Michael
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

On 12/7/2016 1:05 PM, Michael Steinberg wrote:
> Hello Wayne, and others too of course!
> 
>> I'm fine with copying the binaries to a single directory.  It's not very
>> elegant but it's probably the path of least resistance.  I'm surprised
>> cmake doesn't have a way to temporarily add build libs for testing
>> purposes.  Maybe they do and I'm just not aware of it.  Please make sure
>> you add any necessary hooks to clean up the shared test directory to the
>> cmake config so as not to leave a bunch of orphaned binaries laying
>> around.
> 
> CMake makes it easy to customize the output build directory per target
> or shared. That was the most help I was expecting really. If we set a
> variable this way, we build to a shared directory, otherwise we don't.
> The build system will then figure out if that means to only copy the
> stuff from the intermediate build directories, or a full rebuild is
> necessary. Also see the last paragraph.
> 
>> I would like finer test granularity as well.  It would also be nice if
>> tests could be grouped so that you could run say all of the tests on
>> libcommon as a group or each individual test within the libcommon group.
>>   I don't know if boost::unit_test supports this but if it does that
>> would be a good thing to implement.
> I think we need to differ here on which level the granularity is
> intended to be. There's the CTest-level that works on "command"
> granularity. The executables themselves are linked to Boost.test, so you
> can specify which tests to run inside the executable as well.
> CTest granularity could then be multiple executables:
> "libcommon.string", "libcommon.foo", "libcommon.bar". It could as well
> mean one executable but multiple runs of the same test-executable with
> different command line arguments.
> I will investigate which if any possibilities there are to define suites
> per one executable in Boost.Test, or if test cases are the broadest
> thing there, just to get the picture complete. I only want to mention
> that CTest and Boost.Test are more or less complementing each other
> rather than doing the same thing and there's space to find the best
> combination for us.
> 
> I originally intended to actually build kicad into a shared directory on
> windows in development and test configurations (no need to run an extra
> install if they're directly built into a destination environment, so it
> helps the development cycle as well). So it would probably be a (c)make
> clean operation to purge the build in this case. What are the benefits
> of rather copying them around in a custom build step, since that seems
> so natural to you  that you take it as given?

In the end, I don't care how it is handled but `make clean` should clean
up the test binaries as well.  If it's handled automatically by cmake,
all the better.  If not, then you will have add cmake code to clean up
the test code.

> 
> Michael
> 
> PS: Sorry that the citing is not perfect, I copied from multiple sources.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Hello,

sorry for the noise, yes, the test cases can themselves be organized 
into suites inside the test-executable with Boost.Test (Test-trees so to 
say), so we're free to build a gazillion of executables per module or 
collect them inside one executable and add a CTest-test for each suite 
which is then run with the corresponding runtime arguments instead. We 
could use this functionality also for other things. Orson pointed out 
that having multiple executables will help speeding things up in case of 
distributed parallel builds.
In any case reorganizing stuff will be rather painless due to all the 
freedoms. Since I'm seeing it all only from the viewpoint of a developer 
people running build machines should have the last word to say, how to 
set it up so it blends in nicely.


Cheers!
Michael

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Hello Wayne, and others too of course!


I'm fine with copying the binaries to a single directory.  It's not very
elegant but it's probably the path of least resistance.  I'm surprised
cmake doesn't have a way to temporarily add build libs for testing
purposes.  Maybe they do and I'm just not aware of it.  Please make sure
you add any necessary hooks to clean up the shared test directory to the
cmake config so as not to leave a bunch of orphaned binaries laying around.


CMake makes it easy to customize the output build directory per target or 
shared. That was the most help I was expecting really. If we set a variable 
this way, we build to a shared directory, otherwise we don't. The build system 
will then figure out if that means to only copy the stuff from the intermediate 
build directories, or a full rebuild is necessary. Also see the last paragraph.


I would like finer test granularity as well.  It would also be nice if
tests could be grouped so that you could run say all of the tests on
libcommon as a group or each individual test within the libcommon group.
  I don't know if boost::unit_test supports this but if it does that
would be a good thing to implement.
I think we need to differ here on which level the granularity is 
intended to be. There's the CTest-level that works on "command" 
granularity. The executables themselves are linked to Boost.test, so you 
can specify which tests to run inside the executable as well.
CTest granularity could then be multiple executables: 
"libcommon.string", "libcommon.foo", "libcommon.bar". It could as well 
mean one executable but multiple runs of the same test-executable with 
different command line arguments.
I will investigate which if any possibilities there are to define suites 
per one executable in Boost.Test, or if test cases are the broadest 
thing there, just to get the picture complete. I only want to mention 
that CTest and Boost.Test are more or less complementing each other 
rather than doing the same thing and there's space to find the best 
combination for us.


I originally intended to actually build kicad into a shared directory on 
windows in development and test configurations (no need to run an extra 
install if they're directly built into a destination environment, so it 
helps the development cycle as well). So it would probably be a (c)make 
clean operation to purge the build in this case. What are the benefits 
of rather copying them around in a custom build step, since that seems 
so natural to you  that you take it as given?


Michael

PS: Sorry that the citing is not perfect, I copied from multiple sources.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

On 12/7/2016 4:29 AM, Maciej Sumiński wrote:
> Hi Michael,
> 
> On 12/06/2016 05:35 PM, Michael Steinberg wrote:
>> Hello,
>>
>> I played around a bit and settled on a quick solution. For running
>> the tests on windows binding to the shared libs is a problem with our
>> default build, because we have separate output directories per target.
>> Only after an install operation are they in one directory for proper
>> library lookup. So I added an option to the kicad cmake script to output
>> all targets to a single shared directory, this option is implicitly
>> activated when unit tests are enabled on windows. It then also adds the
>> boost.test dependency.
> 
> It sounds ok, I do not know how else it could be solved on Windows, at
> least to be able to easily set up automatic testing.
> 
>> Everything else is just like I described in the last message: CTest can
>> be used to run all the test executables, if you want boost.test
>> verbosity, you can always run the tests from the command prompt.
>>
>> Problem left would then be, how we set up the test targets. My initial
>> thought would be to have one target per lib/executable. All tests
>> related to the common library would then be combined to the
>> "common-test" target for example.
> 
> I used to work with projects that had multiple small unit tests and it
> was quite neat solution. Do you think it would be much harder to apply
> the same rules here? If so, I would not mind having one-to-one relation
> between targets and tests, especially that one can easily separate tests
> using boost.test judging from the screenshot you posted.

I would like finer test granularity as well.  It would also be nice if
tests could be grouped so that you could run say all of the tests on
libcommon as a group or each individual test within the libcommon group.
 I don't know if boost::unit_test supports this but if it does that
would be a good thing to implement.

> 
> Regards,
> Orson
> 
>> Here's a screenshot for the targets, RUN_TESTS (CTest) output,
>> boost.test output and the shared stage dir:
>> https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png
>>
>> Am I making any sense? I might not be aware of all the things you expect
>> from this.
>>
>> Michael
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

On 12/6/2016 11:35 AM, Michael Steinberg wrote:
> Hello,
> 
> I played around a bit and settled on a quick solution. For running
> the tests on windows binding to the shared libs is a problem with our
> default build, because we have separate output directories per target.
> Only after an install operation are they in one directory for proper
> library lookup. So I added an option to the kicad cmake script to output
> all targets to a single shared directory, this option is implicitly
> activated when unit tests are enabled on windows. It then also adds the
> boost.test dependency.

I'm fine with copying the binaries to a single directory.  It's not very
elegant but it's probably the path of least resistance.  I'm surprised
cmake doesn't have a way to temporarily add build libs for testing
purposes.  Maybe they do and I'm just not aware of it.  Please make sure
you add any necessary hooks to clean up the shared test directory to the
cmake config so as not to leave a bunch of orphaned binaries laying around.

> Everything else is just like I described in the last message: CTest can
> be used to run all the test executables, if you want boost.test
> verbosity, you can always run the tests from the command prompt.
> 
> Problem left would then be, how we set up the test targets. My initial
> thought would be to have one target per lib/executable. All tests
> related to the common library would then be combined to the
> "common-test" target for example.
> 
> Here's a screenshot for the targets, RUN_TESTS (CTest) output,
> boost.test output and the shared stage dir:
> https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png
> 
> Am I making any sense? I might not be aware of all the things you expect
> from this.
> 
> Michael
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Maciej Sumiński]

On 12/07/2016 10:55 AM, Maciej Sumiński wrote:
> On 12/07/2016 10:35 AM, Michael Steinberg wrote:
>> Hello Orson,
>>
>>
>> Am 07.12.2016 um 10:29 schrieb Maciej Sumiński:
>>> I used to work with projects that had multiple small unit tests and it
>>> was quite neat solution. Do you think it would be much harder to apply
>>> the same rules here? If so, I would not mind having one-to-one relation
>>> between targets and tests, especially that one can easily separate tests
>>> using boost.test judging from the screenshot you posted.
>>>
>>> Regards,
>>> Orson
>> That would absolutely be possible, my intention avoiding that on the
>> first shot was only that I feared having a full executable link process
>> per test/test case might be a bit troublesome in the long run. Did you
>> have no problems with that, how many tests were there, did it slow down
>> the build process at all? No matter how many test targets we produce,
>> CTest will only ever say "passed" or "not passed" for each without any
>> further information of what is the cause, if I'm not completely mistaken.
>>
>> Michael
> 
> Linking against a shared library (e.g. _pcbnew.kiface) should be quick.
> Tom has been testing a similar approach [1], though without using CTest,
> but it shows the idea.
> 
> CTest is able to give extra information once a build fails [2].
> Apparently whatever approach we choose we will have more or less the
> same information available. I do not really see any exceptional benefit
> of one method over the other, so IMHO we can go with whatever is easier
> to set up.
> 
> Regards,
> Orson
> 
> 1.
> https://github.com/twlostow/kicad-dev/commit/bec46081ea3bf0e2862615fc6040a86beda5785f
> 2. https://cmake.org/cmake/help/v2.8.8/ctest.html#opt%3a--output-on-failure

One thing worth checking is whether boost.test continues tests after a
test fails. Full report is a valuable information, sometimes I was able
to tell what went wrong without launching gdb, but simply by looking at
a list of failed tests.

Regards,
Orson



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Maciej Sumiński]

On 12/07/2016 10:35 AM, Michael Steinberg wrote:
> Hello Orson,
> 
> 
> Am 07.12.2016 um 10:29 schrieb Maciej Sumiński:
>> I used to work with projects that had multiple small unit tests and it
>> was quite neat solution. Do you think it would be much harder to apply
>> the same rules here? If so, I would not mind having one-to-one relation
>> between targets and tests, especially that one can easily separate tests
>> using boost.test judging from the screenshot you posted.
>>
>> Regards,
>> Orson
> That would absolutely be possible, my intention avoiding that on the
> first shot was only that I feared having a full executable link process
> per test/test case might be a bit troublesome in the long run. Did you
> have no problems with that, how many tests were there, did it slow down
> the build process at all? No matter how many test targets we produce,
> CTest will only ever say "passed" or "not passed" for each without any
> further information of what is the cause, if I'm not completely mistaken.
> 
> Michael

Linking against a shared library (e.g. _pcbnew.kiface) should be quick.
Tom has been testing a similar approach [1], though without using CTest,
but it shows the idea.

CTest is able to give extra information once a build fails [2].
Apparently whatever approach we choose we will have more or less the
same information available. I do not really see any exceptional benefit
of one method over the other, so IMHO we can go with whatever is easier
to set up.

Regards,
Orson

1.
https://github.com/twlostow/kicad-dev/commit/bec46081ea3bf0e2862615fc6040a86beda5785f
2. https://cmake.org/cmake/help/v2.8.8/ctest.html#opt%3a--output-on-failure



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Hello Orson,


Am 07.12.2016 um 10:29 schrieb Maciej Sumiński:

I used to work with projects that had multiple small unit tests and it
was quite neat solution. Do you think it would be much harder to apply
the same rules here? If so, I would not mind having one-to-one relation
between targets and tests, especially that one can easily separate tests
using boost.test judging from the screenshot you posted.

Regards,
Orson
That would absolutely be possible, my intention avoiding that on the 
first shot was only that I feared having a full executable link process 
per test/test case might be a bit troublesome in the long run. Did you 
have no problems with that, how many tests were there, did it slow down 
the build process at all? No matter how many test targets we produce, 
CTest will only ever say "passed" or "not passed" for each without any 
further information of what is the cause, if I'm not completely mistaken.


Michael

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Maciej Sumiński]

Hi Michael,

On 12/06/2016 05:35 PM, Michael Steinberg wrote:
> Hello,
> 
> I played around a bit and settled on a quick solution. For running
> the tests on windows binding to the shared libs is a problem with our
> default build, because we have separate output directories per target.
> Only after an install operation are they in one directory for proper
> library lookup. So I added an option to the kicad cmake script to output
> all targets to a single shared directory, this option is implicitly
> activated when unit tests are enabled on windows. It then also adds the
> boost.test dependency.

It sounds ok, I do not know how else it could be solved on Windows, at
least to be able to easily set up automatic testing.

> Everything else is just like I described in the last message: CTest can
> be used to run all the test executables, if you want boost.test
> verbosity, you can always run the tests from the command prompt.
> 
> Problem left would then be, how we set up the test targets. My initial
> thought would be to have one target per lib/executable. All tests
> related to the common library would then be combined to the
> "common-test" target for example.

I used to work with projects that had multiple small unit tests and it
was quite neat solution. Do you think it would be much harder to apply
the same rules here? If so, I would not mind having one-to-one relation
between targets and tests, especially that one can easily separate tests
using boost.test judging from the screenshot you posted.

Regards,
Orson

> Here's a screenshot for the targets, RUN_TESTS (CTest) output,
> boost.test output and the shared stage dir:
> https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png
> 
> Am I making any sense? I might not be aware of all the things you expect
> from this.
> 
> Michael
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Hello,

I played around a bit and settled on a quick solution. For running 
the tests on windows binding to the shared libs is a problem with our 
default build, because we have separate output directories per target. 
Only after an install operation are they in one directory for proper 
library lookup. So I added an option to the kicad cmake script to output 
all targets to a single shared directory, this option is implicitly 
activated when unit tests are enabled on windows. It then also adds the 
boost.test dependency.
Everything else is just like I described in the last message: CTest can 
be used to run all the test executables, if you want boost.test 
verbosity, you can always run the tests from the command prompt.


Problem left would then be, how we set up the test targets. My initial 
thought would be to have one target per lib/executable. All tests 
related to the common library would then be combined to the 
"common-test" target for example.


Here's a screenshot for the targets, RUN_TESTS (CTest) output, 
boost.test output and the shared stage dir: 
https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png


Am I making any sense? I might not be aware of all the things you expect 
from this.


Michael


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Hey,

I have worked only on one CMake project that uses CTest and that worked 
like CTest calls the the executable for a test suite and checks the 
return error code. However if there are multiple tests in a executable 
it will just show that any of it failed, but not what exactly failed, so 
it is really not helpful for the developer. Linking an executable per 
test is imho prohibitive. So my workflow was coding the tests units with 
google test (or boost.test, whatever fits) and use CTest only as a 
validation if all tests-suites pass. If any fails I go ahead and run 
that test from the prompt to get the detailed unit-test-lib output.
Another option would be to use extended add_test to run the executables 
with arguments identifying the specific test to run, but that is not 
really developer friendly either, right?
Does anyone have experience with a nice CTest workflow or an example I 
could have a look at?


Michael


Am 05.12.2016 um 14:43 schrieb Wayne Stambaugh:

I would be more than happy if you wanted to take on the task of getting
the c++ unit testing framework set up.  Maybe once the infrastructure is
in place, developers would be more likely to write unit tests.  I would
also prefer if you used CTest for running the test suites rather than
using CMake custom targets.  This is what CTest was designed to handle.

On 12/5/2016 8:38 AM, Michael Steinberg wrote:

Thank you Wayne,

I'd be really highly interested in getting unit tests sorted out for the
C++ part. Each time I write something without a set of tests for a
project of this size I feel miserable :( Is there anything I can help
with, sort out, think about?

Michael


Am 05.12.2016 um 14:19 schrieb Wayne Stambaugh:

On 12/4/2016 8:53 AM, Michael Steinberg wrote:

Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:

On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:

On 08.09.2016 18:49, Wayne Stambaugh wrote:

Hey Tom,

Here is the patch that fixes the linking as well.  I linked
against the
static libraries.  That shouldn't be an issue.


Hi Wayne,

Thanks for the patch. It looks like the config.h file is generated in
the build directory, not the source one. I was building in-tree so I
didn't notice the problem.

Concerning static linking, I would like to have an option (say,
KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
.kiface DLL. This results in way faster linking times and omits
dependency calculations, which I find very annoying (especially when I
know I didn't change anything that would result in an incompatible DLL
binary).

Linking to the dynamic library in the pcbnew/ build path is
problematic.
On linux, you would have to run ldconfig, on windows you would
have set
the $PATH environment variable, and I believe osx also has some type of
dynamic library loader that would require configuration otherwise the
tests would fail because the os wont be able to find the dynamic
library.  That's why I statically linked it.  I would think that would
be acceptable for unit testing purposes.

Hello all,

what's the status on this? If I'm rewriting lib stuff I could just as
well go ahead and add unit tests for it. I couldn't find the "tests"
folder that would be added by the patch.

Michael


Michael,

The unit tests are in the qa folder.  As of right now there are only
some python tests using the python unit test framework which means any
code you write would have to be built into the python scripting support
to test it.  We have discussed using the boost unit test framework for
testing c++ code directly so that is an option as well.

Cheers,

Wayne

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Mário Luzeiro]

Hi Michael,

Not sure if that is total on the same subject, just an example when I developed 
the 3D-viewer I implemented some C++ test cases with Asserts:
https://git.launchpad.net/kicad/tree/3d-viewer/3d_rendering/test_cases.cpp

It helped a lot in the beginning but in the end I managed to change some of the 
behaviours of the libraries and so the tests I developed no longer apply / 
pass, so I commented it.
So it however need some work to be used as proper test base for future 
developers and validation...

Mario Luzeiro


From: Kicad-developers 
[kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
Michael Steinberg [michste...@gmail.com]
Sent: 05 December 2016 13:38
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

Thank you Wayne,

I'd be really highly interested in getting unit tests sorted out for the
C++ part. Each time I write something without a set of tests for a
project of this size I feel miserable :( Is there anything I can help
with, sort out, think about?

Michael

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Tomasz Wlostowski]

On 05.12.2016 14:19, Wayne Stambaugh wrote:
> On 12/4/2016 8:53 AM, Michael Steinberg wrote:
>>
>> Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:
>>>
>>> On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:
 On 08.09.2016 18:49, Wayne Stambaugh wrote:
> Hey Tom,
>
> Here is the patch that fixes the linking as well.  I linked against the
> static libraries.  That shouldn't be an issue.
>
 Hi Wayne,

 Thanks for the patch. It looks like the config.h file is generated in
 the build directory, not the source one. I was building in-tree so I
 didn't notice the problem.

 Concerning static linking, I would like to have an option (say,
 KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
 .kiface DLL. This results in way faster linking times and omits
 dependency calculations, which I find very annoying (especially when I
 know I didn't change anything that would result in an incompatible DLL
 binary).
>>> Linking to the dynamic library in the pcbnew/ build path is problematic.
>>>   On linux, you would have to run ldconfig, on windows you would have set
>>> the $PATH environment variable, and I believe osx also has some type of
>>> dynamic library loader that would require configuration otherwise the
>>> tests would fail because the os wont be able to find the dynamic
>>> library.  That's why I statically linked it.  I would think that would
>>> be acceptable for unit testing purposes.
>> Hello all,
>>
>> what's the status on this? If I'm rewriting lib stuff I could just as
>> well go ahead and add unit tests for it. I couldn't find the "tests"
>> folder that would be added by the patch.
>>
>> Michael
>>
> 
> Michael,
> 
> The unit tests are in the qa folder.  As of right now there are only
> some python tests using the python unit test framework which means any
> code you write would have to be built into the python scripting support
> to test it.  We have discussed using the boost unit test framework for
> testing c++ code directly so that is an option as well.
> 

Hi Michael,

I'll push my tests branch to github in the evening, sorry but I'm quite
busy right now.

Tom

> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

I would be more than happy if you wanted to take on the task of getting
the c++ unit testing framework set up.  Maybe once the infrastructure is
in place, developers would be more likely to write unit tests.  I would
also prefer if you used CTest for running the test suites rather than
using CMake custom targets.  This is what CTest was designed to handle.

On 12/5/2016 8:38 AM, Michael Steinberg wrote:
> Thank you Wayne,
> 
> I'd be really highly interested in getting unit tests sorted out for the
> C++ part. Each time I write something without a set of tests for a
> project of this size I feel miserable :( Is there anything I can help
> with, sort out, think about?
> 
> Michael
> 
> 
> Am 05.12.2016 um 14:19 schrieb Wayne Stambaugh:
>> On 12/4/2016 8:53 AM, Michael Steinberg wrote:
>>> Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:
 On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:
> On 08.09.2016 18:49, Wayne Stambaugh wrote:
>> Hey Tom,
>>
>> Here is the patch that fixes the linking as well.  I linked
>> against the
>> static libraries.  That shouldn't be an issue.
>>
> Hi Wayne,
>
> Thanks for the patch. It looks like the config.h file is generated in
> the build directory, not the source one. I was building in-tree so I
> didn't notice the problem.
>
> Concerning static linking, I would like to have an option (say,
> KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
> .kiface DLL. This results in way faster linking times and omits
> dependency calculations, which I find very annoying (especially when I
> know I didn't change anything that would result in an incompatible DLL
> binary).
 Linking to the dynamic library in the pcbnew/ build path is
 problematic.
On linux, you would have to run ldconfig, on windows you would
 have set
 the $PATH environment variable, and I believe osx also has some type of
 dynamic library loader that would require configuration otherwise the
 tests would fail because the os wont be able to find the dynamic
 library.  That's why I statically linked it.  I would think that would
 be acceptable for unit testing purposes.
>>> Hello all,
>>>
>>> what's the status on this? If I'm rewriting lib stuff I could just as
>>> well go ahead and add unit tests for it. I couldn't find the "tests"
>>> folder that would be added by the patch.
>>>
>>> Michael
>>>
>> Michael,
>>
>> The unit tests are in the qa folder.  As of right now there are only
>> some python tests using the python unit test framework which means any
>> code you write would have to be built into the python scripting support
>> to test it.  We have discussed using the boost unit test framework for
>> testing c++ code directly so that is an option as well.
>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

On 12/4/2016 8:53 AM, Michael Steinberg wrote:
> 
> Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:
>>
>> On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:
>>> On 08.09.2016 18:49, Wayne Stambaugh wrote:
 Hey Tom,

 Here is the patch that fixes the linking as well.  I linked against the
 static libraries.  That shouldn't be an issue.

>>> Hi Wayne,
>>>
>>> Thanks for the patch. It looks like the config.h file is generated in
>>> the build directory, not the source one. I was building in-tree so I
>>> didn't notice the problem.
>>>
>>> Concerning static linking, I would like to have an option (say,
>>> KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
>>> .kiface DLL. This results in way faster linking times and omits
>>> dependency calculations, which I find very annoying (especially when I
>>> know I didn't change anything that would result in an incompatible DLL
>>> binary).
>> Linking to the dynamic library in the pcbnew/ build path is problematic.
>>   On linux, you would have to run ldconfig, on windows you would have set
>> the $PATH environment variable, and I believe osx also has some type of
>> dynamic library loader that would require configuration otherwise the
>> tests would fail because the os wont be able to find the dynamic
>> library.  That's why I statically linked it.  I would think that would
>> be acceptable for unit testing purposes.
> Hello all,
> 
> what's the status on this? If I'm rewriting lib stuff I could just as
> well go ahead and add unit tests for it. I couldn't find the "tests"
> folder that would be added by the patch.
> 
> Michael
> 

Michael,

The unit tests are in the qa folder.  As of right now there are only
some python tests using the python unit test framework which means any
code you write would have to be built into the python scripting support
to test it.  We have discussed using the boost unit test framework for
testing c++ code directly so that is an option as well.

Cheers,

Wayne

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Thank you Wayne,

I'd be really highly interested in getting unit tests sorted out for the 
C++ part. Each time I write something without a set of tests for a 
project of this size I feel miserable :( Is there anything I can help 
with, sort out, think about?


Michael


Am 05.12.2016 um 14:19 schrieb Wayne Stambaugh:

On 12/4/2016 8:53 AM, Michael Steinberg wrote:

Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:

On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:

On 08.09.2016 18:49, Wayne Stambaugh wrote:

Hey Tom,

Here is the patch that fixes the linking as well.  I linked against the
static libraries.  That shouldn't be an issue.


Hi Wayne,

Thanks for the patch. It looks like the config.h file is generated in
the build directory, not the source one. I was building in-tree so I
didn't notice the problem.

Concerning static linking, I would like to have an option (say,
KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
.kiface DLL. This results in way faster linking times and omits
dependency calculations, which I find very annoying (especially when I
know I didn't change anything that would result in an incompatible DLL
binary).

Linking to the dynamic library in the pcbnew/ build path is problematic.
   On linux, you would have to run ldconfig, on windows you would have set
the $PATH environment variable, and I believe osx also has some type of
dynamic library loader that would require configuration otherwise the
tests would fail because the os wont be able to find the dynamic
library.  That's why I statically linked it.  I would think that would
be acceptable for unit testing purposes.

Hello all,

what's the status on this? If I'm rewriting lib stuff I could just as
well go ahead and add unit tests for it. I couldn't find the "tests"
folder that would be added by the patch.

Michael


Michael,

The unit tests are in the qa folder.  As of right now there are only
some python tests using the python unit test framework which means any
code you write would have to be built into the python scripting support
to test it.  We have discussed using the boost unit test framework for
testing c++ code directly so that is an option as well.

Cheers,

Wayne

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Michael Steinberg]

Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:


On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:

On 08.09.2016 18:49, Wayne Stambaugh wrote:

Hey Tom,

Here is the patch that fixes the linking as well.  I linked against the
static libraries.  That shouldn't be an issue.


Hi Wayne,

Thanks for the patch. It looks like the config.h file is generated in
the build directory, not the source one. I was building in-tree so I
didn't notice the problem.

Concerning static linking, I would like to have an option (say,
KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
.kiface DLL. This results in way faster linking times and omits
dependency calculations, which I find very annoying (especially when I
know I didn't change anything that would result in an incompatible DLL
binary).

Linking to the dynamic library in the pcbnew/ build path is problematic.
  On linux, you would have to run ldconfig, on windows you would have set
the $PATH environment variable, and I believe osx also has some type of
dynamic library loader that would require configuration otherwise the
tests would fail because the os wont be able to find the dynamic
library.  That's why I statically linked it.  I would think that would
be acceptable for unit testing purposes.

Hello all,

what's the status on this? If I'm rewriting lib stuff I could just as 
well go ahead and add unit tests for it. I couldn't find the "tests" 
folder that would be added by the patch.


Michael

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

On 9/7/2016 5:39 PM, Tomasz Wlostowski wrote:
> On 07.09.2016 21:24, Wayne Stambaugh wrote:
>> Tom,
>>
>> I also forgot to mention there were tabs in the CMakeLists.txt file.
>>
> Hi Wayne,
> 
> Here's a (hopefully) fixed version.
> 
> Cheers,
> Tom

Hey Tom,

Here is the patch that fixes the linking as well.  I linked against the
static libraries.  That shouldn't be an issue.

FYI, I would rather you use CTest[1] add_test()[2] for defining tests
then creating a custom function.  When you use CTest, I believe the
BUILD_TESTING enables building the tests but I've never used this so I'm
not sure how it all fits together but I'm sure it's documented somewhere.

Cheers,

Wayne

[1] https://cmake.org/Wiki/CMake_Testing_With_CTest
[2] https://cmake.org/cmake/help/v3.6/command/add_test.html


> 
>> Cheers,
>>
>> Wayne
>>
>> On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote:
>>> Hi,
>>>
>>> This patch adds possibility to build C++ tests for pcbnew, using
>>> Boost.Test framework. I intended it primarily to make tests for the P,
>>> which I used to develop out-of-tree before.
>>>
>>> Since Kicad's codebase is rather monolithic, testing/refactoring
>>> anything drags in pretty much everything else in the code as a
>>> dependency.  This causes long rebuild and linking times, which I find
>>> very annoying. Also, while developing new features, most of the time is
>>> spent linking pcbnew and clicking in the GUI to trigger the particular
>>> feature.
>>>
>>> For that reason I decided to link all the test cases directly to the
>>> _pcbnew_kiface library and skip pcbnew's dependency scanning when
>>> building tests. I'm also preparing a bare PCB test window for verifying
>>> interactive/graphical operations without rebuilding pcbnew as a whole app.
>>>
>>> I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
>>> There's one trivial unit test included as an example. Let me know if
>>> such solution would be acceptable.
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 6a3abea..7a7ba46 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -1,15 +1,19 @@
-include_directories ( 
-${CMAKE_SOURCE_DIR} 
+include_directories(
+${CMAKE_BINARY_DIR}
 ${CMAKE_SOURCE_DIR}/polygon
 ${CMAKE_SOURCE_DIR}/include
 ${CMAKE_SOURCE_DIR}/pcbnew
 ${CMAKE_SOURCE_DIR}/pcbnew/router )
 
-link_directories ( ${CMAKE_BINARY_DIR}/pcbnew )
+link_directories( ${CMAKE_BINARY_DIR}/pcbnew )
 
 function( add_test_case name )
-add_executable ( ${name} ${name}.cpp )
-target_link_libraries ( ${name} ${wxWidgets_LIBRARIES} _pcbnew_kiface 
${Boost_LIBRARIES} )
+add_executable( ${name} ${name}.cpp )
+target_link_libraries( ${name} ${wxWidgets_LIBRARIES}
+common
+pcbcommon
+pnsrouter
+${Boost_LIBRARIES} )
 endfunction( add_test_case )
 
-add_subdirectory ( pns )
+add_subdirectory( pns )
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

Tom,

Here's a patch against your patch that fixes the compile and some of the
link issues.  It linker still cannot find some of the PNS_NODE code.  I
thought PNS_NODE was in the libpcbcommon.a library but apparently not.
I'm calling it a night.  I'll see if I can get it to build tomorrow.

Cheers,

Wayne

On 9/7/2016 5:39 PM, Tomasz Wlostowski wrote:
> On 07.09.2016 21:24, Wayne Stambaugh wrote:
>> Tom,
>>
>> I also forgot to mention there were tabs in the CMakeLists.txt file.
>>
> Hi Wayne,
> 
> Here's a (hopefully) fixed version.
> 
> Cheers,
> Tom
> 
>> Cheers,
>>
>> Wayne
>>
>> On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote:
>>> Hi,
>>>
>>> This patch adds possibility to build C++ tests for pcbnew, using
>>> Boost.Test framework. I intended it primarily to make tests for the P,
>>> which I used to develop out-of-tree before.
>>>
>>> Since Kicad's codebase is rather monolithic, testing/refactoring
>>> anything drags in pretty much everything else in the code as a
>>> dependency.  This causes long rebuild and linking times, which I find
>>> very annoying. Also, while developing new features, most of the time is
>>> spent linking pcbnew and clicking in the GUI to trigger the particular
>>> feature.
>>>
>>> For that reason I decided to link all the test cases directly to the
>>> _pcbnew_kiface library and skip pcbnew's dependency scanning when
>>> building tests. I'm also preparing a bare PCB test window for verifying
>>> interactive/graphical operations without rebuilding pcbnew as a whole app.
>>>
>>> I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
>>> There's one trivial unit test included as an example. Let me know if
>>> such solution would be acceptable.
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 

diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 6a3abea..cc1254c 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -1,15 +1,21 @@
-include_directories ( 
-${CMAKE_SOURCE_DIR} 
+include_directories(
+${CMAKE_BINARY_DIR}
+${CMAKE_SOURCE_DIR}
 ${CMAKE_SOURCE_DIR}/polygon
 ${CMAKE_SOURCE_DIR}/include
 ${CMAKE_SOURCE_DIR}/pcbnew
-${CMAKE_SOURCE_DIR}/pcbnew/router )
+${CMAKE_SOURCE_DIR}/pcbnew/router
+)
 
-link_directories ( ${CMAKE_BINARY_DIR}/pcbnew )
+link_directories( ${CMAKE_BINARY_DIR}/pcbnew )
 
 function( add_test_case name )
-add_executable ( ${name} ${name}.cpp )
-target_link_libraries ( ${name} ${wxWidgets_LIBRARIES} _pcbnew_kiface 
${Boost_LIBRARIES} )
+add_executable( ${name} ${name}.cpp )
+target_link_libraries( ${name} ${wxWidgets_LIBRARIES}
+${CMAKE_BINARY_DIR}/pcbnew/_pcbnew.kiface
+${CMAKE_BINARY_DIR}/common/libcommon.a
+${CMAKE_BINARY_DIR}/common/libpcbcommon.a
+${Boost_LIBRARIES} )
 endfunction( add_test_case )
 
-add_subdirectory ( pns )
+add_subdirectory( pns )
diff --git a/tests/pns/CMakeLists.txt b/tests/pns/CMakeLists.txt
index b305e1e..2da310b 100644
--- a/tests/pns/CMakeLists.txt
+++ b/tests/pns/CMakeLists.txt
@@ -1,3 +1 @@
 add_test_case( test_node )
-
-
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Tomasz Wlostowski]

On 07.09.2016 21:24, Wayne Stambaugh wrote:
> Tom,
> 
> I also forgot to mention there were tabs in the CMakeLists.txt file.
> 
Hi Wayne,

Here's a (hopefully) fixed version.

Cheers,
Tom

> Cheers,
> 
> Wayne
> 
> On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote:
>> Hi,
>>
>> This patch adds possibility to build C++ tests for pcbnew, using
>> Boost.Test framework. I intended it primarily to make tests for the P,
>> which I used to develop out-of-tree before.
>>
>> Since Kicad's codebase is rather monolithic, testing/refactoring
>> anything drags in pretty much everything else in the code as a
>> dependency.  This causes long rebuild and linking times, which I find
>> very annoying. Also, while developing new features, most of the time is
>> spent linking pcbnew and clicking in the GUI to trigger the particular
>> feature.
>>
>> For that reason I decided to link all the test cases directly to the
>> _pcbnew_kiface library and skip pcbnew's dependency scanning when
>> building tests. I'm also preparing a bare PCB test window for verifying
>> interactive/graphical operations without rebuilding pcbnew as a whole app.
>>
>> I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
>> There's one trivial unit test included as an example. Let me know if
>> such solution would be acceptable.
>>
>> Cheers,
>> Tom
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

>From 287624c8bee0c6d3c05877c41533fc90b3ab2523 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Wed, 7 Sep 2016 17:53:20 +0200
Subject: [PATCH] Initial support for unit tests in pcbnew using Boost.Test

---
 CMakeLists.txt   | 32 ++--
 pcbnew/CMakeLists.txt| 12 
 tests/CMakeLists.txt | 15 +++
 tests/pns/CMakeLists.txt |  3 +++
 tests/pns/test_node.cpp  | 21 +
 5 files changed, 73 insertions(+), 10 deletions(-)
 create mode 100644 tests/CMakeLists.txt
 create mode 100644 tests/pns/CMakeLists.txt
 create mode 100644 tests/pns/test_node.cpp

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bfeaac5..b3371f6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -49,6 +49,9 @@ option( KICAD_USE_OCE
 "Build tools and plugins related to OpenCascade Community Edition (default OFF)"
 )
 
+option( KICAD_BUILD_TESTS
+"Builds C++ tests (default OFF)"
+)
 # when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
 # PYTHON_EXECUTABLE can be defined when invoking cmake
 # ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -69,10 +72,14 @@ option( KICAD_SPICE "Build Kicad with internal Spice simulator." OFF )
 set( KICAD_REPO_NAME "product" CACHE STRING "Name of the tree from which this build came." )
 
 
-# Global setting: exports are explicit
-set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
-set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
-
+# Global setting: exports are explicit by default
+if ( KICAD_BUILD_TESTS )
+set( CMAKE_CXX_VISIBILITY_PRESET "default" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN OFF )
+else()
+set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
+endif()
 
 # Global setting: build everything position independent
 set( CMAKE_POSITION_INDEPENDENT_CODE ON )
@@ -93,11 +100,13 @@ if( POLICY CMP0063 )
 cmake_policy( SET CMP0063 NEW )
 endif()
 else()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
-endif()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
+if( CMAKE_CXX_VISIBILITY_PRESET STREQUAL "hidden" )
+if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
+set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
+endif()
+if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
+set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
+endif()
 endif()
 endif()
 
@@ -503,7 +512,7 @@ find_package( Cairo 1.8.8 REQUIRED )
 #
 # Note: Prior to Boost 1.59, the Boost context library is not built when compiling on windows
 #   with GCC.  You must patch the Boost sources.
-find_package( Boost 1.54.0 REQUIRED COMPONENTS 

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

Tom,

I also forgot to mention there were tabs in the CMakeLists.txt file.

Cheers,

Wayne

On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote:
> Hi,
> 
> This patch adds possibility to build C++ tests for pcbnew, using
> Boost.Test framework. I intended it primarily to make tests for the P,
> which I used to develop out-of-tree before.
> 
> Since Kicad's codebase is rather monolithic, testing/refactoring
> anything drags in pretty much everything else in the code as a
> dependency.  This causes long rebuild and linking times, which I find
> very annoying. Also, while developing new features, most of the time is
> spent linking pcbnew and clicking in the GUI to trigger the particular
> feature.
> 
> For that reason I decided to link all the test cases directly to the
> _pcbnew_kiface library and skip pcbnew's dependency scanning when
> building tests. I'm also preparing a bare PCB test window for verifying
> interactive/graphical operations without rebuilding pcbnew as a whole app.
> 
> I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
> There's one trivial unit test included as an example. Let me know if
> such solution would be acceptable.
> 
> Cheers,
> Tom
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Wayne Stambaugh]

Tom,

It looks like you did not include the build path in the unit test build
configuration.  I'm getting a build error when the unit test is enabled:

[ 33%] Building CXX object
tests/pns/CMakeFiles/test_node.dir/test_node.cpp.obj
In file included from
C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcbnew.h:33:0,
 from
C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/class_track.h:34,
 from
C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_via.h:28,
 from
C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_line.h:33,
 from
C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_segment.h:32,
 from
C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_joint.h:31,
 from
C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_node.h:37,
 from
C:/msys64/home/wstambaugh/src/kicad-trunk/tests/pns/test_node.cpp:7:
C:/msys64/home/wstambaugh/src/kicad-trunk/include/fctsys.h:37:20: fatal
error: config.h: No such file or directory
compilation terminated.
make[2]: *** [tests/pns/CMakeFiles/test_node.dir/build.make:63:
tests/pns/CMakeFiles/test_node.dir/test_node.cpp.obj] Error 1


On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote:
> Hi,
> 
> This patch adds possibility to build C++ tests for pcbnew, using
> Boost.Test framework. I intended it primarily to make tests for the P,
> which I used to develop out-of-tree before.
> 
> Since Kicad's codebase is rather monolithic, testing/refactoring
> anything drags in pretty much everything else in the code as a
> dependency.  This causes long rebuild and linking times, which I find
> very annoying. Also, while developing new features, most of the time is
> spent linking pcbnew and clicking in the GUI to trigger the particular
> feature.
> 
> For that reason I decided to link all the test cases directly to the
> _pcbnew_kiface library and skip pcbnew's dependency scanning when
> building tests. I'm also preparing a bare PCB test window for verifying
> interactive/graphical operations without rebuilding pcbnew as a whole app.
> 
> I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
> There's one trivial unit test included as an example. Let me know if
> such solution would be acceptable.
> 
> Cheers,
> Tom
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [RFC] [PATCH] simple C++ tests

[Tomasz Wlostowski]

Hi,

This patch adds possibility to build C++ tests for pcbnew, using
Boost.Test framework. I intended it primarily to make tests for the P,
which I used to develop out-of-tree before.

Since Kicad's codebase is rather monolithic, testing/refactoring
anything drags in pretty much everything else in the code as a
dependency.  This causes long rebuild and linking times, which I find
very annoying. Also, while developing new features, most of the time is
spent linking pcbnew and clicking in the GUI to trigger the particular
feature.

For that reason I decided to link all the test cases directly to the
_pcbnew_kiface library and skip pcbnew's dependency scanning when
building tests. I'm also preparing a bare PCB test window for verifying
interactive/graphical operations without rebuilding pcbnew as a whole app.

I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
There's one trivial unit test included as an example. Let me know if
such solution would be acceptable.

Cheers,
Tom

>From fb308460da32cb7a30e66f0c114ac3a0a159ef60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Wed, 7 Sep 2016 17:53:20 +0200
Subject: [PATCH] Initial support for unit tests in pcbnew using Boost.Test

---
 CMakeLists.txt   | 34 +++---
 pcbnew/CMakeLists.txt| 12 
 tests/CMakeLists.txt | 10 ++
 tests/pns/CMakeLists.txt |  3 +++
 tests/pns/test_node.cpp  | 21 +
 5 files changed, 69 insertions(+), 11 deletions(-)
 create mode 100644 tests/CMakeLists.txt
 create mode 100644 tests/pns/CMakeLists.txt
 create mode 100644 tests/pns/test_node.cpp

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bfeaac5..0dbd735 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -49,6 +49,9 @@ option( KICAD_USE_OCE
 "Build tools and plugins related to OpenCascade Community Edition (default OFF)"
 )
 
+option( KICAD_BUILD_TESTS
+"Builds C++ tests (default OFF)"
+)
 # when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
 # PYTHON_EXECUTABLE can be defined when invoking cmake
 # ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -69,10 +72,14 @@ option( KICAD_SPICE "Build Kicad with internal Spice simulator." OFF )
 set( KICAD_REPO_NAME "product" CACHE STRING "Name of the tree from which this build came." )
 
 
-# Global setting: exports are explicit
-set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
-set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
-
+# Global setting: exports are explicit by default
+if ( KICAD_BUILD_TESTS )
+set( CMAKE_CXX_VISIBILITY_PRESET "default" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN OFF )
+else()
+set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
+endif()
 
 # Global setting: build everything position independent
 set( CMAKE_POSITION_INDEPENDENT_CODE ON )
@@ -93,12 +100,14 @@ if( POLICY CMP0063 )
 cmake_policy( SET CMP0063 NEW )
 endif()
 else()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
-endif()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
-endif()
+if( CMAKE_CXX_VISIBILITY_PRESET STREQUAL "hidden" )
+		if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
+	set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
+		endif()
+		if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
+		set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
+		endif()
+	endif()
 endif()
 
 
@@ -503,7 +512,7 @@ find_package( Cairo 1.8.8 REQUIRED )
 #
 # Note: Prior to Boost 1.59, the Boost context library is not built when compiling on windows
 #   with GCC.  You must patch the Boost sources.
-find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread )
+find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread unit_test_framework )
 
 # Include MinGW resource compiler.
 include( MinGWResourceCompiler )
@@ -804,6 +813,9 @@ add_subdirectory( kicad )   # should follow pcbnew, eeschema
 add_subdirectory( tools )
 add_subdirectory( utils )
 add_subdirectory( qa )
+if ( KICAD_BUILD_TESTS )
+add_subdirectory( tests )
+endif()
 
 # Resources
 add_subdirectory( demos )
diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index c4aff51..5ce31a0 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -578,6 +578,18 @@ set_target_properties( pcbnew_kiface PROPERTIES
 SUFFIX  ${KIFACE_SUFFIX}
 )
 
+if ( KICAD_BUILD_TESTS )
+if ( UNIX )
+	add_custom_command(TARGET pcbnew_kiface POST_BUILD
+	 COMMAND ln -sf _pcbnew.kiface lib_pcbnew_kiface.so )
+else()
+