Project

General

Profile

Feature #407

Mac OSX support

Added by Tunnell, Christopher over 10 years ago. Updated almost 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Build System
Target version:
Start date:
06 April 2011
Due date:
% Done:

0%

Estimated time:
Workflow:

Description

Currently we don't support Mac OSX. There appears to be an issue with 'recpack'. Installation instructions for Mac OS X (which will have to be a little trickier than the automatic linux install) should go here:

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

Putting this to Matt for the moment.


Files

SConstruct (20.4 KB) SConstruct Lane, Peter, 10 August 2011 16:30
#1

Updated by Robinson, Matthew over 10 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

It's done.

#2

Updated by Tunnell, Christopher over 10 years ago

  • Target version changed from Future MAUS release to MAUS-v0.0.1
#3

Updated by Tunnell, Christopher about 10 years ago

  • Status changed from Closed to Open
  • Assignee deleted (Robinson, Matthew)
  • % Done changed from 100 to 0

Apparantly this isn't working so reopened...

Flagged the section as dead, see history if want to revive.

#4

Updated by Tunnell, Christopher about 10 years ago

The install works but some unit tests are failing.

#5

Updated by Rogers, Chris about 10 years ago

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

#6

Updated by Tunnell, Christopher about 10 years ago

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.

#7

Updated by Lane, Peter about 10 years ago

  • Assignee set to Lane, Peter
  • Target version changed from MAUS-v0.0.1 to Future MAUS release

I'll take this. I'll have to modify the SConstruct file slightly and at very least document how to get Root to spit out the correct libPyRoot.so. The more complicated solution is to patch the Root build before building it. Other than that the build works fine and passes all of the unit tests.

#8

Updated by Tunnell, Christopher about 10 years ago

#9

Updated by Lane, Peter about 10 years ago

I remade the installation instructions at the location referenced in the original description of this feature request. I'm waiting to see my branch tested on the test server before making it official. Again, all unit tests appear to be passing. So as far as I can tell there are no issues with recpack anymore (at least with OS X 10.6.8). If there are problems with recpack they aren't being revealed by the unit tests.

Attaching my SConstruct so people can get a hold of the changes before the next release.

#10

Updated by Lane, Peter about 10 years ago

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".

#11

Updated by Rogers, Chris about 10 years ago

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...

#12

Updated by Lane, Peter about 10 years ago

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.

#13

Updated by Tunnell, Christopher about 10 years ago

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.

#14

Updated by Lane, Peter about 10 years ago

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.

#15

Updated by Lane, Peter about 10 years ago

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.

#16

Updated by Lane, Peter about 10 years ago

Merge request is #692.

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

#17

Updated by Lane, Peter about 10 years ago

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.

#18

Updated by Rogers, Chris almost 10 years ago

Can we close this?

#19

Updated by Tunnell, Christopher almost 10 years ago

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.

#20

Updated by Rogers, Chris almost 9 years ago

  • Status changed from Open to Rejected

Killed - reopen if you want...

Also available in: Atom PDF