The install works but some unit tests are failing.

Added Peter as a watcher - he was doing this himself (reported problem with ROOT build). Is this assigned to Tunnell?

This is a abandoned feature request since I don't have a Mac that can install MAUS. If somebody picks it up and can prove that their branch passes all the unit tests, I'll include it in the trunk. But I'm not going to work to get it done.

Matt's instructions worked for getting thigns installed. It was just the unit tests that were flagging things so maybe it was issues with MAUS code and MACs? Not sure.

See Matt's previous comments:

http://micewww.pp.rl.ac.uk/projects/maus/wiki/InstallMacOSX/history

I've figured out the real root of the problem (no pun intended) building on OS X. Python needs to be built as a "framework" in order to load shared libraries on OS X. I've reworded the current installation instructions to indicate they are a hack for MAUS 0.0.5. I've committed a "real" fix in my branch and hope to merge it once it's tested on the test server to make sure I didn't break non-OS X builds.

The changes involve an alternate location for Python when building on OS X (blame the Python build):

${MAUS_ROOT_DIR}/third_party/install/Python.framework/Versions/2.7/

As a result I've modified configure and some install scripts to take note of this. SConstruct needed to be modified slightly (from the trunk version) in order to force the use of .so suffixes instead of .dylib (common on OS X) so that Python can find them when invoking "import".

Are you putting python in install/Python.framework/Versions/2.7/ for standard linux also? I think it's better to have it in the same place for everyone...

No, that directory was dictated by the Python build. Certainly I could rework things to have Python put there for all systems, but it would look a little funny since only OS X is a framework build (i.e. "Python.framework" in the name). If that doesn't offend anyone then I'll make it homogeneous.

I don't think it matters either way. I think Mac sounding names on Linux sounds ugly. But I'll try to continue getting you a Mac test server setup so we just test it which is the thing that does matter.

I updated the install instructions to have the user simply checkout a copy of my development branch. Aside from making sure one's Mac has the prerequisites, the normal build procedure applies. Once the code is merged and distributed with a release I will update the instructions again.

Linux builds were flagging issues with global variable names that the mac build were not. I still don't understand why, but that's fine since the complaints were valid. I tried to assert the offending variable's "globalness", but that didn't work. I changed tactics and created a custom SCons builder which simply copies the .dylib files to .so files to make Python happy (still don't understand why that's necessary either).

Other than that I just had some issues with typos that weren't expressing themselves on my personal "unclean" system (i.e. they showed up when I tried to build on rgma16).

I'm going to do one more fresh checkout and build on rgma16 for sanity. Once that's done I'll submit a request to merge.

So in summary, the tasks left before this issue can be closed are
1) finish final test build on rgma16,
2) submit a merge request through the issue tracker, and
3) update the installation instructions after the 1.0.0 release.

I successfully executed the install_then_build_then_test.bash script on rgma16 out of my development branch. I will create a new issue requesting it be merged with the trunk.

Merge request is #692.

Updated the install doc to reflect that the mods have been merged.

The discussion on #692_ has suggested that there are problems on 64-bit Snow Leopard. I've changed the build instructions to say that 64-bit and Lion systems haven't been tested and are thus unsupported.

Can we close this?

I couldn't get it to work in Jenkins. I think I sent an email that may have been missed by Peter. But not close until it works on the test server.