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

[Robert Heller]

At Wed, 01 Sep 2010 13:36:51 -0300 Evergreen Development Discussion List 	<open-ils-dev at list.georgialibraries.org> wrote:

> 
> 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? 

All *I* would need would be a generic tarball, containing just the xul,
js, etc. files.  This would work on *any UNIX/Linux* system with the
xulrunner runtime separately installed -- xulrunner gets installed as a
dependency of Firefox and Thunderbird.  It is pretty much a given that
any *desktop* install will get Firefox installed.  I believe all the
tarball would need would be the 'build' tree (that can be installed
under /usr/local/share/Everygreen/ or someplace like that).  Having an
actual RPM would be nice, but I can live without it.



> 
>                                       

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Download the Model Railroad System
http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
heller at deepsoft.com       -- http://www.deepsoft.com/ModelRailroadSystem/