Fix loading library when running tests from build directory

[pfultz2]

No description provided.

[amai2012]

That seems to do the job for your use case.

There is a small issue upon increasing the search path always: maybe sometimes many copies of a resource (here library files) exist and it's not longer obvious which set gets actually used. But I guess that may not hurt yet.

[danmar]

The ideal fix is that testrunner does not load the cfg files at all.

It is "improper" behavior to depend on files. there is some ticket/forum where some maintainer wants to change this.

We could generate some minimal hardcoded library data in testrunner that is loaded instead of the real files.

[amai2012]

The ideal fix is that testrunner does not load the cfg files at all.

It is "improper" behavior to depend on files. there is some ticket/forum where some maintainer wants to change this.

Well, testing something and using something else is also improper. IMHO even more. I don't think we can't keep things in sync w/o other than creating the "minimal library" within the buildjob.

And if we don't keep them in sync the automatic testing within testrunner gets less helpful.

[danmar]

the test/cfg/* are supposed to use the real cfg files. and they should test that the cfg files are configured properly.

in testrunner I want to write a test that makes sure for instance <not-null/> element produce proper output but I don't want that we test all functions that have <not-null/> to see they are configured properly. So the minimal std.cfg in testrunner needs at least one function that has <not-null/> configuration. it is irrelevant if the minimal std.cfg is out of sync, that does not affect the testing of the cfg handling.

[pfultz2]

There is a small issue upon increasing the search path always: maybe sometimes many copies of a resource (here library files) exist and it's not longer obvious which set gets actually used. But I guess that may not hurt yet.

Yes, ideally, the tests should only search relative to the exe.

[pfultz2]

Also, I generally, build and run the tests from the build directory with make && ./bin/testrunner, however, this wont load any of the required cfg files. So if I run make && ./bin/testrunner TestOther, it runs no tests due to missing the cfg files.

[pfultz2]

The ideal fix is that testrunner does not load the cfg files at all.

I dont think so. There could be test cfg files just for testing, but we should be testing against the cfg files that will be distributed with cppcheck so we can easily test for regressions. Its too easy to modify the cfg file so many checks will stop working.

[danmar]

The ideal fix is that testrunner does not load the cfg files at all.

I dont think so. There could be test cfg files just for testing, but we should be testing against the cfg files that will be distributed with cppcheck so we can easily test for regressions. Its too easy to modify the cfg file so many checks will stop working.

This is why we have test/cfg/*

We could also auto-generate tests from the cfg files.. and then whenever the cfg files are changed we also need to check if the test changes look good. The xml format is difficult, there are details that can even fool me, so a double check of how the changes effects real code would be good.

The testrunner should contain our unit tests. I want to have good integration tests also but that is a different task and they don't have to be mixed up.

[danmar]

We could also auto-generate tests from the cfg files.. and then whenever the cfg files are changed we also need to check if the test changes look good. The xml format is difficult, there are details that can even fool me, so a double check of how the changes effects real code would be good.

I will look into this.

[pfultz2]

We could also auto-generate tests from the cfg files.. and then whenever the cfg files are changed we also need to check if the test changes look good. The xml format is difficult, there are details that can even fool me, so a double check of how the changes effects real code would be good.

That sounds good, but it would be nice to merge this in for the short-term, so one doesn't have to switch directories to run the tests.