I know I need something else so It all compiles and installs into the correct path. I don't know what that is. I also would like if the whole thing was verbose. Any help in the correct direction would be awesome. Thanks for reading.

Ideally what you'd do is learn about packaging and create your own rpm containing your app. If you distribute this in the way that you are now you'll end up with a development environment on all the boxes you install it on. With a package you'll have that on your build machine and nowhere else.

CentOS 5 died in March 2017 - migrate NOW!
Full time Geek, part time moderator. Use the FAQ Luke

TrevorH wrote:Ideally what you'd do is learn about packaging and create your own rpm containing your app. If you distribute this in the way that you are now you'll end up with a development environment on all the boxes you install it on. With a package you'll have that on your build machine and nowhere else.

I didn't know that was a possibility and I can work on that. I need a short term patch for now while I learn packaging. I have the kickstart file setup to provide all the proper dev packages on install.

I used vim and set the commands into xmr.install.sh with chmod +x
I think, but I'm not sure, the cmake3 command on line 3 isn't correct. Same with make install on line 4.

Yes, you do have an issue there.

Line 1 executes bash in devtoolset-4 environment. (Why the 4? That is old by now.)
In the script, once the bash completes,
Line 2 executes cmake3 in system default environment.
Line 3 executes make in system default environment.

If you do want to run SCL version of cmake3 and make, then you either make that bash run the commands,
or

Edit:
Sourcing SCL environment in .bashrc can turn fatal.
For one, prepending to PATH will reoccur on every shell instance, not just in the login shell.

More importantly, you will always hide system default versions for your user. That might be tolerable with devtoolset, but imagine the consequences of enabling, say rh-python36. The 'yum' requires python 2.7. It does run /usr/bin/python, which is 2.7, but the rh-python36 prepends python 3.6's path to mess things up.

Edit:
Sourcing SCL environment in .bashrc can turn fatal.
For one, prepending to PATH will reoccur on every shell instance, not just in the login shell.

More importantly, you will always hide system default versions for your user. That might be tolerable with devtoolset, but imagine the consequences of enabling, say rh-python36. The 'yum' requires python 2.7. It does run /usr/bin/python, which is 2.7, but the rh-python36 prepends python 3.6's path to mess things up.

I think (at least in my case) that this is intended for disposable servers. Really the only real need I can see for enabling an scl in a single bash session.