[OPEN-ILS-DEV] ***SPAM*** Building/installing Everygreen (Open ILS) staff client under CentOS 5

[Dan Scott]

Hi Robert:

I should start by saying that Red Hat / CentOS / Fedora 13 support
actually works as of OpenSRF 1.6 / Evergreen 2.0 (both of which we just
pulled together in alpha releases in the past week, but which aren't to
my knowledge linked anywhere yet).

OpenSRF 1.6.0 alpha:
http://open-ils.org/downloads/OpenSRF-1_6_0-alpha.tar.gz

Evergreen 2.0 alpha1:
http://open-ils.org/downloads/Evergreen-ILS-2.0-alpha1.tar.gz 

Before those releases, the Red Hat / CentOS support was a work in
progress - which is why you would find warnings about that in the
Makefile.install, and no claims of support or documented install steps
for those distributions, and really terrible autotools attempt.

Please give these new alpha releases a shot and let us know when you run
into a road block, there are a few people who have been down the CentOS
path that should be able to help you out.

More inline below:

On Wed, 2010-09-01 at 11:37 -0400, Jason Etheridge wrote:
> Hi Robert,
> 
> I can address some of this.
> 
> > 1) Do I have to build and install OpenSRF in order to build *only* the
> > staff client?  If so, why?  The only dependency the the configure file
> > for Everygreen checks for that *seems* to be needed for the staff client
> > is OpenSRF, and it seems it just wants to copy some JavaScript code
> > over. Is there some way to avoid having to build and install OpenSRF,
> > *just to build* the staff client?
> 
> I haven't tried it in a while, but there used to be a make target for
> OpenSRF for installing just the Javascript libs.  Does anyone know if
> this is still the case?  I didn't see any just skimming.  With the
> staff client Makefile, you can also override the OPENSRF_JSLIBS
> variable to point to those libs.

It's not in the Makefile, it's an option you pass to configure, like
most projects that use autotools:

./configure --disable-core --enable-javascript
make
make install

Newer versions of OpenSRF have better support (e.g. not trying to detect
dependencies that aren't required for the enabled components) than older
ones. OpenSRF 1.2 is definitely in the 'old' camp.

> > 2) Do I have to build Everygreen (OpenILS) itself in order to build the
> > staff client?  I hope not.
> 
> Assuming the OpenSRF javascript libs are installed, you could do
> something similar to this to avoid building all of Evergreen:
> 
> wget http://evergreen-ils.org/downloads/Evergreen-ILS-1.6.0.4.tar.gz
> tar xvf Evergreen-ILS-1.6.0.4.tar.gz
> cd Evergreen-ILS-1.6.0.4/
> ./configure --disable-core --disable-web --disable-reporter
> cd Open-ILS/xul/staff_client/
> make STAFF_CLIENT_BUILD_ID=rel_1_6_0_4 build
> rm -rf build/server/

Technically you don't actually need the "rm" step, right? And if a
"build_client" target was added to the top-level makefile, then you
wouldn't need the second "cd" step, either, which would leave you with:

wget http://evergreen-ils.org/downloads/Evergreen-ILS-1.6.0.4.tar.gz
tar xvf Evergreen-ILS-1.6.0.4.tar.gz
cd Evergreen-ILS-1.6.0.4/
./configure --disable-core --disable-web --disable-reporter
make STAFF_CLIENT_BUILD_ID=rel_1_6_0_4 build_client

(note that you would want "build_client" at the top level rather than
"build" to identify the actual target of the build). And that would be
exactly as many steps as would be required as pretty much any other
project in existence.

> It used to be easier before the Makefile was taken over by autotools.
> *laments*  :)

And all that any new person had to do was figure out how our custom
shell scripts and Makefile targets worked (and remember, there was no
documentation at the time), rather than have a chance of following the
standard autotools approach. Oh, it was heaven! And fragile, and more
Debian-specific. Let's not get too carried away in our reminiscing.

We do need to improve the autotools setup - it has come a long way in
the OpenSRF 1.6 and Evergreen 2.0 branches, but has further to go. I'd
love to see some patches on that front.

> > 3) Exactly *why* isn't there a "built" version of the *staff client for
> > Linux available for download?
> 
> We can start providing one.  In the past it's just been developers
> using Linux clients.  In trunk, the build situation for the staff
> client has been much improved thanks to Thomas Berezansky.  We can
> easily build Windows clients cross-compiled from Linux environments,
> as well as Firefox extensions  and generic XPI files, and Linux
> clients (complete with bundled xulrunner runtimes).  So we'll
> eventually be pushing out all of those as a matter of course, though
> any given library's support staff may wish to restrict what they
> support.

Linux x86 (and maybe x86_64) as a tarball? Or debs / rpms? I don't think
we should expect any Itanium, SPARC, or DEC Alpha Linux builds, right?