Custom build of ice 3.5.1: test failures

in Help Center
Hi,
The openmicroscopy codebase is still using Python 2 and so we aren't currently able to use the ZeroC windows packages directly due to them being built against Python 3. For this reason most of our Windows users are currently using Ice 3.4. I'm in the process of setting up local builds of Ice 3.5.1 so that we can provide a version of Ice built against Python 2.7 using VS2010. I've followed your instructions for doing so to create a jenkins job to automate the build.
An example build is here:
ICE35-WIN » x86,Release,vc100 #54 Console [Jenkins]
(I'm still working on getting all the build variants going.) This is building fine. However, I am getting some test failures (search: "fatal error U1077") in the above log. The cpp failure is shown below when run by hand; the py and cs tests of the same type also fail:
Have you encountered this error before? If so, I'd be grateful if you could let me know what's making my build environment different to how you have yours set up. Does it require a particular locale or anything custom doing to make it work?
I'm using VS2010 on a WS2008R2 server with python 2.7 in a virtualenv and the current ThirdParty sources are installed. I'm doing x86 and x64 debug and release variants; the above is the x86 release variant.
Also, if I do my own custom python 2.7 build with VS2012, should ice and its tests build and pass using VS2012? (After hacking out the check which prevents it building py with this combination.)
Many thanks,
Roger
The openmicroscopy codebase is still using Python 2 and so we aren't currently able to use the ZeroC windows packages directly due to them being built against Python 3. For this reason most of our Windows users are currently using Ice 3.4. I'm in the process of setting up local builds of Ice 3.5.1 so that we can provide a version of Ice built against Python 2.7 using VS2010. I've followed your instructions for doing so to create a jenkins job to automate the build.
An example build is here:
ICE35-WIN » x86,Release,vc100 #54 Console [Jenkins]
(I'm still working on getting all the build variants going.) This is building fine. However, I am getting some test failures (search: "fatal error U1077") in the above log. The cpp failure is shown below when run by hand; the py and cs tests of the same type also fail:
(27-x86) C:\jenkins\workspace\ICE35-WIN\VSARCH\x86\VSCONFIG\Release\VSVERSION\vc100\src\Ice-3.5.1\cpp>nmake /f Makefile.mak OPTIMIZE=no test *** running tests 12/86 in C:\jenkins\workspace\ICE35-WIN\VSARCH\x86\VSCONFIG\Release\VSVERSION\vc100\src\Ice-3.5.1\cpp\test\Ice\properties *** configuration: Default *** test started: 04/17/14 17:16:59 starting client... ok testing load properties from UTF-8 path... PropertiesI.cpp:407: Ice::FileException: file exception: The system cannot find the file specified. path: ./config/õ©¡Õø¢_client.config unexpected exit status: expected: 0, got 1 ('test in C:\\jenkins\\workspace\\ICE35-WIN\\VSARCH\\x86\\VSCONFIG\\Release\\VSVERSION\\vc100\\src\\Ice-3.5.1\\cpp\\test\\Ice\\properties failed with exit status', 1) NMAKE : fatal error U1077: 'C:\jenkins\venv\27-x86\Scripts\python.EXE' : return code '0x1' Stop.
Have you encountered this error before? If so, I'd be grateful if you could let me know what's making my build environment different to how you have yours set up. Does it require a particular locale or anything custom doing to make it work?
I'm using VS2010 on a WS2008R2 server with python 2.7 in a virtualenv and the current ThirdParty sources are installed. I'm doing x86 and x64 debug and release variants; the above is the x86 release variant.
Also, if I do my own custom python 2.7 build with VS2012, should ice and its tests build and pass using VS2012? (After hacking out the check which prevents it building py with this combination.)
Many thanks,
Roger
0
Comments
The test run.py script needs a minor fix to work with Windows and Python 2.7
Replace this
By
I don't see any reason why VS2012 shouldn't work, but we haven't tested this.
Our last (I hope!) remaining problem is in getting the debug (OPTIMIZE=no) builds to work. They are failing as shown below and in ICE35-WIN » x86,Debug,vc100 #61 Console [Jenkins]
I'm invoking the build with
It looks like this is because OPTIMIZE=yes is hardcoded in py/config/Make.rules.mak unconditionally so that you can't override it easily and it can't be inherited. Same in vsaddin. cpp is handling it properly. Just as a general suggestion, it would be really great if OPTIMIZE, prefix and x64suffix could be overridden easily with the Make.rules.mak files only setting them if unset externally on the nmake command-line.
I've updated our builds to run sed over the Make.rules.mak files to set OPTIMIZE, prefix and x64suffix by updating the hardcoded values, but it would be ideal if we didn't need to mangle them this way.
Regards,
Roger
We hard-coded OPTIMIZE as yes because Python Windows installers doesn't provide debug libraries, and doing a custom python build isn't that common.
Why do you need to update x64suffix? note that the test suite expects to found x64 binaries in bin\x64 so changing this could affect the test suite when run with --x64 option.
For OPTIMIZE and PREFIX will not harm to do as you say and we will probably get those fixed in next release.
Thanks for bring that to our attention.
Best Regards,
José
Our overriding of the x64 suffix is because we're doing separate 32- and 64-bit builds, and so the prefix is kept in the top-level package name rather than in individual subdirectories; the directory layout is identical between 32- and 64-bit builds.
One additional question here is if it's still possible to build against python 2.6? Building with your patch works fine for python 2.7. However, with python 2.6 I get a test failure here:
Looks like the failure is in the python test runner. Is some additional tweaking required here to make it work with Python 2.6?
Many thanks,
Roger