Replace build_ecce with a more standard way of compiling

[ohlincha]

Maybe a ./configure/make(/install?) chain?

It will also help when building binaries for release

[dustinrb]

The following is current as of commit ee5fe2b on the make branch.

I've create a "make" branch which uses CMake to manage the build process. Currently this branch only builds shared libraries, Fortran binaries, and 3rd party dependancies.

This branch follows the standard CMake build process outlined below starting in the ECCE source directory.

mkdir _build; cd _build
cmake ..
make
# make install

Note that the install prefix defaults to /usr but can be changed by using the -DCMAKE_INSTALL_PREFIX=/path/to/install when running CMake; however, this branch has has not reached a point where this is necessary.

What Has Changed

• The build process is defined in the CMakeLists.txt file and the included cmake/*.cmake files.
• Mesa and perl CGI are no longer built. libgl and libglu are now required either through installing mesa or another graphics driver.
• Source for third party dependancies is pulled from external sources (archive.apache.org, and SourceForge). This may be a moot point since the source archives are already in Git.
• The src/ directory has been reorganized by language. The C++ code for shared libraries has been moved to folders corresponding to that library's name.
• Share libraries are not prefixed with "libecce_". Some libraries now used a more verbose identifier. For example "libecceexp.so" is not "libecce_expect.so".

Future Changes

• Build and link the ECCE binaries. (This won't be hard, just tedious.)
• Code the install step such that it creates a directory similar to the one created by the install_ecce.csh bundle. This will require creating some sort of setup.sh script to replace the config file templating done by install_ecce.csh.
• Reconfigure ECCE's launch bootstrapping so it can support a more traditional Linux installation into /usr/lib, /usr/bin, /var/ecce, and /etc/ecce
• Create .dep and .rpm files (CMake may have a tool for this, but I haven't had a chance to look at the details)

[ohlincha]

Dustin,
I'm not sure installing into the usual places is a good idea, but I need to make sure that I understand what's happening here.

1. We're still building packages that are already available in all our target distros?
2. If 1, we need to be careful with installation locations, and naming if creating packages, since we want to avoid conflicts.
3. A 'cheap' way of making .deb packages is by using checkinstall -- it's not as rigorous as doing it the normal way, but it's worked quite well for me in the past (see e.g. http://verahill.blogspot.se/2013/08/497-compiling-wine-17-in-chroot-on.html for an example)
4. Keep in mind that all the job files end up in the file structure of the ECCE server installation, and this easily balloons to many Gbs of data after a bit of usage. For this reason we really do NOT want to install the ECCE server in /usr, which would typically be on the / partition. Somewhere under the /home partition is a better default, with a big fat warning during installation about recommended locations. The current way of installing ECCE, using the csh, is actually IMHO better than using a .rpm or .deb package (which it sounds like we're heading slowly towards)

So,

• what's your plan re dependencies -- distro or included 3rd party src?
• I think building ECCE as an installation executable rather than a .deb/.rpm is preferable as it makes it easier(?) to get people to actively choose sensible installation targets.

[dustinrb]

1. The goal is to move to system provided packages where possible. There are currently four packages which must be bundled:
   • ActiveMQ is not available in CentOS
   • HTTPD will require rewriting the apache config and placing it in /etc/httpd/conf.d (mostly a matter of time. I want to get a working bundle build first).
   • wxWidgets requires an ASCII build (see issue wxWidgets 2.8 Unicode Support #34)
   • Xerces 3 depricates some parts of the 2.8 API
2. Bundled dependancies would live in /opt/ecce to keep them away from system versions
3. I was thinking of using CPack which has generators for .deb, .rpm, and .tar.gz but checkinstall may be a good starting place.
4. Putting the data directory in /var/ecce seems the most canonically linux way, but I'm not married to that idea. Using /home seems odd sense ECCE is a service and not a user. The data directory can be changed in the httpd.conf file after installation. We could also have the .rpm/.dep package prompt the user for a location during installion similar to how installing apache in Ubuntu works.

So, here is why I'm wanting to standardize the install process:

• I'd like to have all the configuration files in one place such as /etc/ecce or /opt/ecce/config. The viewer is fairly good about this, but server configs are bundled with their respective application. I'd also like to segregate the ECCE generated configurations from ones users are allowed to edit.
• I'd like to minimize templating in hard coded paths during the install process
• Adding the ecce executables to the path would prevent user from needing to modify their .bashrc file

@mattasplund suggested storing everything in /opt/ecce and linking to /usr, /var/httpd/conf.d etc. as needed. This seems like a reasonable compromise since it would standardize many paths, but also keep ECCE mostly self-contained.

[ohlincha]

My concern is mainly regarding disk space -- the server/data folder can easily grow very large, and I think it's important that the user is explicitly prompted about where to store it. Sure, it doesn't quite jell with the idea of ECCE running as a service for several users, but I wonder how many ECCE installations are actually used in that way.

Locations on personal linux installs:

• the most basic config is all folders on one partition -- no worries here.
• the second most basic config is a smallish partition for /, and a bigger one for /home. / will quickly run out of space if a lot of user data is kept in /var or /opt
• Separate /, /var, /opt, /home -- but I think this config is somewhat uncommon.

So in most cases /opt and /var would be on the / partition, and that could quickly (or slowly) cause the partition to run out of space.

A better solution would of course be for each user to have their own data dir i.e. the server is installed on e.g. /opt, but the users data files are in ~, but I don't know how much work that would involve implementing.

Either way, for the above reasons I think it's important that users are prompted explicitly about the location of the server (or server/data) location.