make test faliure

[chang liu]

When i downloaded the develop branch and make test ,it show the faliure : The following tests FAILED: 3-testWarp(Failed) Errors while running CTest make:***[test]错误 8

[Mike Sheffler]

Possibly related to #384.

[Mike Sheffler]

@ZhouYu0623 Try pulling now and see if the test still fails.

[chang liu]

I have pulled the newest code , but stii fails yet.

[Mike Sheffler]

Okay, I can reproduce this now. The error is

Test project /home/msheffler/Build/GTSAM/Release
        Start   1: testWrap
  1/230 Test   #1: testWrap ...............................***Failed    0.01 sec
<<< DIFF OUTPUT (if none, white-space differences only):
158c158
<     def __str__(self):
---
>     def __repr__(self):
>>>
/home/msheffler/Source/gtsam/wrap/tests/testWrap.cpp:500: Failure: "files_equal(epath + "geometry.pyx", apath + "geometry.pyx" )" 
There were 1 failures

which is (I think) one of the problems that #382 was having. I haven't built the Python toolbox, so I didn't even try to follow the (Python-related) error in #382.

Let me take a look.

[Mike Sheffler]

I'm not sure when the relevant code sneaked in (the commit was by Duy on 2017-03-18, but I can't follow the history to figure out when his code was merged to develop), but, what appears to be happening is that the test for the cython .pyx files is always happening when GTSAM_BUILD_WRAP is configured -- even if GTSAM_INSTALL_CYTHON_TOOLBOX is not configured.

I checked gtsam/CMakeLists.txt, and I think a similar thing could happen with generated MATLAB code if GTSAM_BUILD_WRAP is configured and GTSAM_INSTALL_MATLAB_TOOLBOX is not configured.

I'm not sure about the best way to handle this. I can introduce a variable in CMakeLists.txt or something to trickle down to the test, but I don't know how clean that will be. Worse, I don't understand how Python / Cython interact very well here, and I don't want to try to build anything Python-related on these machines. I'll try out a fix on my machines. If it works, I'll do a PR, and @dellaert or someone that is building the Cython toolbox can see if my fix screws anything up.

(Side note: There is a line set(GTSAM_INSTALL_CYTHON_TOOLBOX 0) # This will go into config.h in gtsam/CMakeLists.txt that does not appear to be mated to anything in gtsam/config.h.in -- I don't know how this generation stuff works very well, so I don't know if that's a problem)

[Mike Sheffler]

Addressed in PR #329 .

A Cython user needs to check my changes (they're minor) to make sure that adding the #cmakedefine GTSAM_INSTALL_CYTHON_TOOLBOX to config.in.h will result in that variable (GTSAM_INSTALL_CYTHON_TOOLBOX) getting a #define in config.h if the user selects GTSAM_INSTALL_CYTHON_TOOLBOX in CMake configure. The comments in CMakeLists.txt (the very top one) seem to indicate that that sort of behavior was desired, so, if I did it wrong, what I did can probably be tweaked in a minor way to get what is needed.

As I mentioned above, there is a chance that a similar bit of bad behavior is possible if GTSAM_BUILD_WRAP is configured and GTSAM_INSTALL_MATLAB_TOOLBOX is not configured, but I haven't tried that out.

[Frank Dellaert]

So, I saw this and the PR, but the wrap tests don't actually compile the wrapper: they just test the code generation. What I think is really going on here is that (because Jenkins is not up, @jdong37 ) after a small change to the wrapper generation the expected files no longer match. So, the only change needed is to change the expected file geometry.pyx, which became stale. I created PR #330 for you to test and approve if it works.

[Mike Sheffler]

I pulled and this looks like the appropriate fix. I approved PR #330 and denied PR #329.

[Frank Dellaert]

Fixed in PR #330