New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GSettings Backend: test tests as external project #809

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@raetiacorvus
Contributor

raetiacorvus commented Jun 22, 2016

Add GSettings back end tests as external project to avoid problem with
GPL inside of a BSD licenced project.

Two GSettings back end tests are disabled as they hang when run as root.

Also remove test/org.libelektra.elektrasettings.gschema.xml which was
a leftover of previous manual testing.

raetiacorvus added some commits Jun 22, 2016

GSettings Backend: add tests as external project
Add GSettings back end tests as external project to avoid problem with
GPL inside of a BSD licenced project.

Two GSettings back end tests are disabled as they hang when run as root.

Also remove `test/org.libelektra.elektrasettings.gschema.xml` which was
a leftover of previous manual testing.
@raetiacorvus

This comment has been minimized.

Contributor

raetiacorvus commented Jun 24, 2016

jenkins build mergerequests-unstable please

@raetiacorvus

This comment has been minimized.

Contributor

raetiacorvus commented Jun 24, 2016

jenkins build bindings please

@raetiacorvus

This comment has been minimized.

Contributor

raetiacorvus commented Jun 24, 2016

@markus2330 not sure why it fails on mergrequests-unstable with the memcheck. The memcheck runs fine for me locally.

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jun 27, 2016

About valgrind: You can add set( MEMORYCHECK_COMMAND_OPTIONS "--gen-suppressions=all" ) temporarily in the PR, this should give you the suppressions embedded in the xml file downloadable from the build server. Or I can also give you an account on the buildserver to run valgrind manually.

@raetiacorvus

This comment has been minimized.

Contributor

raetiacorvus commented Jul 2, 2016

I suspect the problem here could be the env -i that is run before the memcheck.
I add the correct environment variables with set_property (TEST test_gsettings PROPERTY ENVIRONMENT "GIO_MODULE_DIR=${binary_dir};GSETTINGS_BACKEND=elektra") and fear that those get discarded.

Edit: No that was a stupid assumption as make run_all also uses env -i

@@ -37,7 +37,7 @@ set (ADDED_DIRECTORIES "" CACHE STRING ${PLUGINS_DOC} FORCE)
remember_for_removal(BINDINGS TO_REMOVE_BINDINGS)
set (BINDINGS_LIST_DEFAULT cpp)
set (BINDINGS_LIST_DEFAULT cpp;glib;gsettings)

This comment has been minimized.

@markus2330

markus2330 Jul 13, 2016

Contributor

thats better in a different PR. Maybe we should even change to ALL, when dependencies are missing they are kicked out anyway.

This comment has been minimized.

@raetiacorvus

raetiacorvus Jul 13, 2016

Contributor

This was just to get the tests running. I would like to postpone adding the module to ALL till it is more stable.

message (WARNING "excluding GSettingsTests: requires GLib >= 2.48")
else ()
include (ExternalProject)
ExternalProject_Add (GSettingsTests GIT_REPOSITORY https://github.com/sirblackheart/gsettings-tests INSTALL_COMMAND "")

This comment has been minimized.

@markus2330

markus2330 Jul 13, 2016

Contributor

The repo should be at least at ElektraInitiative.

Is there no way to use the official repo? I would prefer it to have as normal dependency via package manager, not as CMake ExternalProject. What about building modified GSettingsTests debian packages?

This comment has been minimized.

@raetiacorvus

raetiacorvus Jul 13, 2016

Contributor

The repo should be at least at ElektraInitiative.

Sure but I currently do not have the rights to add repos to ElektraInitiative.

Is there no way to use the official repo? I would prefer it to have as normal dependency via package manager, not as CMake ExternalProject. What about building modified GSettingsTests debian packages?

If we are able to do so would probably be nice. But that comes with its own set of problems. Anyone wanting to run the tests on debian would need the modified debian packages.
One of the reasons the debian packages are missing the gsettings tests is probably that some of the gsettings testcases hang when run as root user (I found some old bug report mentioning it so it is more of a assumption on my side). I explicitly disabled those tests in the external project repo to work around those hangs.

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jul 14, 2016

Thus we had no time to discuss it at the meeting: I assume we (in the narrow sense, so you and me) will be the only people putting any effort into executing the tests. Your way would likely be the only way people would run the tests.

So what about merging it for now and if people experience problems we reconsider? But you need to resolve the conflicts before I can merge it. If the ExternalProject works well, we might want to do the same for gtest, too. (And avoid a copy of it in our repo)

I also created
ElektraInitiative/gsettings-tests
you can push the commits of your gsettings-tests repo into it.

@markus2330 markus2330 changed the title from WIP: GSettings Backend: test tests as external project to GSettings Backend: test tests as external project Nov 23, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment