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?

and is this the trunk or a release?

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

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?

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

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

#248 is what I was talking about

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.

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!

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.

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.

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!