Project

General

Profile

Bug #613

Root not being installed

Added by Lane, Peter about 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tunnell, Christopher
Category:
Build System
Target version:
Start date:
04 August 2011
Due date:
% Done:

100%

Estimated time:
Workflow:

Description

The ${MAUS_ROOT_DIR}/third_party/bash/21root.bash script is not installing root properly. It does "configure" and "make" but does not perform "make install". To do this the configure command needs to include a --prefix option to set the installation location to ${MAUS_ROOT_DIR}/third_party/install.

#1

Updated by Tunnell, Christopher about 10 years ago

what's the output from:

tests/integration/install_then_build_then_test.bash

? Why do you say it's not installing properly? There should be a command that tells it to install within the MAUS directory in the bash script. From a new terminal, sourcing env.sh it doesn't find root?

#2

Updated by Tunnell, Christopher about 10 years ago

and is this the trunk or a release?

#3

Updated by Tunnell, Christopher about 10 years ago

Sorry, I was wrong (bad memory). So at:

http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/third_party/bash/21root.bash#L42

it builds ROOT. We never install ROOT but instead just source the 'thisroot.sh' that comes within the ROOT build directory:

http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/configure#L204

so after installing root, you have to source env.sh again. It's stupid I know but there are weird errors we were getting with installing root into our 'bin' and 'lib' directories. Mainly when we would install patch releases of ROOT.

Is that clear? We could do this better but I think it's good enough for the moment (we need a maintainer honestly).

#4

Updated by Lane, Peter about 10 years ago

it builds ROOT. We never install ROOT but instead just source the 'thisroot.sh' that comes within the ROOT build directory:

http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/configure#L204

It doesn't seem that this is doing anything. One runs configure before building anything, so it will never find the script.

so after installing root, you have to source env.sh again.

Ok, I see that the blurb in configure is also in env.sh. I'd like to see it fixed (can I help?), but until then could this extra step be added to the installation instructions? My "scons build" stops without error after "Checking for C++ library recpack... no".

It's stupid I know but there are weird errors we were getting with installing root into our 'bin' and 'lib' directories. Mainly when we would install patch releases of ROOT.

Could I trouble you to elaborate? This seems rather bizarre. Unless "make install" overwrites files from other software it shouldn't matter where the files are.

Is that clear? We could do this better but I think it's good enough for the moment (we need a maintainer honestly).

A maintainer of what specifically?

#5

Updated by Tunnell, Christopher about 10 years ago

Lane, Peter wrote:

It doesn't seem that this is doing anything. One runs configure before building anything, so it will never find the script.

What? it runs make at the end... Confused.

so after installing root, you have to source env.sh again.

Ok, I see that the blurb in configure is also in env.sh. I'd like to see it fixed (can I help?), but until then could this extra step be added to the installation instructions? My "scons build" stops without error after "Checking for C++ library recpack... no".

What do you mean by fixed? Does the instruction here work though?

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

Could I trouble you to elaborate? This seems rather bizarre. Unless "make install" overwrites files from other software it shouldn't matter where the files are

It is bizarre. If you run through the ROOT and geant4 install scripts we have to do some weird stuff to get it to install for you, but we don't maintain those packages. Nobody ever uses 'make install' in the HEP world with ROOT because people switch around their versions of ROOT and normally have many installations of the same version on any given machine. I think the issue had to do with generating reflex dictionaries of the C++ classes but I honestly don't remember. We're just doing it the way everybody else does it since it makes it easier to switch the version of ROOT. It's more historicaly since that's how LHC experiments do it and (I could look it up if you really were interested) I remember having issues trying to do it correctly.

Is that clear? We could do this better but I think it's good enough for the moment (we need a maintainer honestly).

A maintainer of what specifically?

The build system. We have to install a ton of random stuff that count as dependencies to MAUS. The issue is the packages we require are a royal pain to install. We have these scripts which seem to work on a wide range of systems, but keeping up with making sure the dependencies are automatically built is currently something I'm responsible for but could use more attention. For example, it would be nice to not have to reinstall all the depencies per copy of MAUS you want. There are feature requests associated with this that I can show you.

What do you mean by fixed?

Nobody ever does 'make install' for ROOT and they actually don't

#6

Updated by Tunnell, Christopher about 10 years ago

But you're right... I need to update the install instructions.

#7

Updated by Tunnell, Christopher about 10 years ago

#248 is what I was talking about

#8

Updated by Lane, Peter about 10 years ago

Tunnell, Christopher wrote:

Lane, Peter wrote:

It doesn't seem that this is doing anything. One runs configure before building anything, so it will never find the script.

What? it runs make at the end... Confused.

Sorry, I wasn't being clear. In configure it checks for the existence of thisroot.sh in Root's build directory, but that doesn't get created until Root is built. Since Root is built after configure is run that statement will always fail unless one re-runs configure.

so after installing root, you have to source env.sh again.

Ok, I see that the blurb in configure is also in env.sh. I'd like to see it fixed (can I help?), but until then could this extra step be added to the installation instructions? My "scons build" stops without error after "Checking for C++ library recpack... no".

What do you mean by fixed? Does the instruction here work though?

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

I get something strange following this link. I see you updated .../wiki/install. Is that what you meant? I'll have to try it.

Could I trouble you to elaborate? This seems rather bizarre. Unless "make install" overwrites files from other software it shouldn't matter where the files are

It is bizarre. If you run through the ROOT and geant4 install scripts we have to do some weird stuff to get it to install for you, but we don't maintain those packages. Nobody ever uses 'make install' in the HEP world with ROOT because people switch around their versions of ROOT and normally have many installations of the same version on any given machine. I think the issue had to do with generating reflex dictionaries of the C++ classes but I honestly don't remember. We're just doing it the way everybody else does it since it makes it easier to switch the version of ROOT. It's more historicaly since that's how LHC experiments do it and (I could look it up if you really were interested) I remember having issues trying to do it correctly.

Ah, ok. Nevermind then. I'll make sure the new instructions work and report back so you can close this out.

#9

Updated by Tunnell, Christopher about 10 years ago

Ah yeah, made the quick install the regular install. Also: yeah, I see what you mean about the condition about that file existing. Currently you just have to re-source env.sh. If you can think of a better way of doing this that works, we'd love that!

#10

Updated by Lane, Peter about 10 years ago

As expected, the new installation instructions solved the problem. I have an idea for improving the build process, but I'll take that issue up on the dev list when I'm done trying it out.

#11

Updated by Tunnell, Christopher about 10 years ago

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

Sweet.

Feel free to call into meetings and propose it. Or create a 'feature request'

#12

Updated by Tunnell, Christopher about 10 years ago

Did you ever use gentoo? It would be nice to have something like portage (see #307) and have it so you didn't have to reinstall dependencies per copy of MAUS.

#13

Updated by Lane, Peter about 10 years ago

I have not used Gentoo nor Portage, but I'm familiar with some other package management systems. The main concern I have about solely adopting Portage (or something like it) is that users would have to have some port of Portage on their system to install MAUS. So I see it not as an either/or decision. MAUS should at a minimum have an installation procedure that is conducive to creating packages. Then if someone has time to create Portage or Debian or MacPorts packages because they use those systems, great!

#14

Updated by Rogers, Chris about 10 years ago

  • Target version changed from Future MAUS release to MAUS-v0.0.6

Also available in: Atom PDF