=== vrruiz_ is now known as rvr [19:00] elopio, remember this old branch? https://code.launchpad.net/~dpm/ubuntu-filemanager-app/run-ap-from-out-of-source-build/+merge/217510 We've hit the problem again about the best way to run tests inside the build environment as a developer. [19:01] I think I'm coming around to the mp's way of doing it.. [19:03] balloons: I'm not sure what you mean, that's an english phrase I don't fully understand. [19:03] do you mean you like the idea of searching for the build dir, or that you like the idea of passing it as a parameter ? [19:03] elopio, hehe.. sorry about that. I'm trying to say, I think what david originally suggested, using the cmakepluginparser, is the way to go [19:05] I still don't agree. I think that while developing things we should always call the cmake autopilot task to run the tests. [19:05] but we always can do both. [19:06] if there's a BUILD_DIR environment variable, use it. [19:06] if there is not, then we can try to find it or run the installed one. Of that part I'm not really worried atm. [19:06] balloons: out of curiosity, what are the problems you are facing now? [19:08] elopio, well I'm running into the old hardcoded local source path issue.. It's a bit of the setup code we've copied about everywhere, but never really standardized beyond, you should build in tree and layout your project this way [19:08] folks are using make and building out of tree.. it fails in this case [19:10] elopio, is there a project that uses cmake autopilot successfully atm? [19:10] balloons: I've started following dobey's advice about CMake passing the build path on unity-click-scope [19:11] I like the way it works. But we still need some more fancy things, like being able to select which tests to run. [19:11] my concern with shoving it into cmake now is cmake build configs are reserved for mad scientists :-) [19:12] lol.. but seriously, I'll go check out what you did [19:13] balloons: it's really simple in this case, a lot more than querying the file. [19:13] http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/autopilot/CMakeLists.txt#L16 [19:14] BUILD_DIR=${CMAKE_BINARY_DIR} [19:15] then the logic on the launch method is also simplified [19:15] http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/autopilot/unityclickscope/test_click_scope.py#L135 [19:15] if BUILD_DIR exists, use the binaries from that dir. [19:15] if it doesn't, just call the installed ones. [19:16] well, I think it's simpler than dpm's solution. But that might be because I like it best and not being impartial. [19:23] * balloons looks [19:24] elopio, hmm.. \ [19:25] I do like setting / reading a builddir env var [19:25] ok, I'll try this [19:27] balloons: I would prefer to pass arguments to autopilot instead of env vars, but this works for now for me. [19:28] what I would like to do is to standardize the way we launch apps. But it's a little hard if we are not able to stabilize the tests. [19:28] now that dialer app is going to be python3, that's going to be my sample app. [19:37] balloons: would you help me to set up autopkgtests for dialer-app? [20:21] elopio, yes should be REALLY simple to do so [20:21] yes, we mentioned in david's original mp my preference for passing an arg to autopilot, but I digress