Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 5 Aug 2010 16:41:30 -0500

Hi Gary,

On Thursday 05 August 2010 15:18:25 Gary V. Vaughan wrote:
> > Sorry for the discouraging remark, but setting "INSTALL_LOCATION" didn't
> > work for me, when I built things for Darwin.
>
> I have the same problem.

Make sure you have applied the patch which is linked from the Base 3.14.11 
Known Problems page.  We don't put fully-patched tarfiles in our download 
area, although we probably should as this does trip people up quite often.

> My choices seem to be either building as root in the install tree, and
> then deleting the sources, or else relinking at install-time while I
> copy the libraries and binaries into their final location in order
> to make sure the RPATHs are set correctly.

Try applying the patch, and report any problems here if that doesn't work.

> Really, I'm just trying to avoid putting all the sources into
> a runtime package, and to facilitate installing the final package
> into it's own subtree, say /usr/packages/EPICS-3.14.11/, where the
> /usr/package/EPICS-3.14.11/bin might be usefully added to a users
> PATH to use epics base.  And where linking with the development
> libraries can be done by adding -I/usr/package/EPICS-3.14.11/include
> and -L/usr/packages/EPICS-3.14.11/lib to match the use of the many
> other packages we produce.

That you should be able to manage with INSTALL_LOCATION, that's what it was 
designed for.  If your customers are not using the EPICS build system they 
need the include directory /usr/package/EPICS-3.14.11/include/os/<os-class> as 
well, where os-class is something like Solaris or Linux.  That's where we 
install OS-specific header files.

> The details of the directories underneath /usr/packages/EPICS-3.14.11/
> won't spoil that scheme overly much.

Then it will probably make your life easier if you leave them as they are.

> Is it because of the bespoke build system that cross builds require
> the configure tree and sources?  I'm only familiar with the way
> GNU does cross compilation, and while it too requires a cross compile
> environment with binaries and libraries for the target machine,
> there's no need to move the host environment into subdirectories for
> that to work.

Our build system is very different to the way that GNU does things.  If you 
wanted to support cross-build targets you'd probably want to package up the 
cross-built products for each target architecture separately.  If you do that 
there would be no need to include the source tree.  However even without the 
cross-build stuff your users will still need the configure tree if they want 
to create an IOC or other EPICS-related tool to run on the host, the sample 
templates that we provide need configure.

> Really, I'm mostly interested in getting the python epicsca APIs
> working for which EPICS base is a prerequisite.  In that case I
> think it's okay to ignore cross compilation issues I think?  If
> not, what directories do I need to have in the EPICS base install
> tree for epicsca to be useful?

If your users are only wanting to run Channel Access (CA) client applications 
then you can ignore the cross-build stuff.  I would still recommend staying 
with the normal Base install structure, but you could leave out many of the 
libraries and header files.  Unfortunately our current build doesn't neatly 
separate out the parts you need from those you don't, although it occurs to me 
that it would be fairly easy to do that in a future release.

> That makes sense, and I'm happy to put a copy of the configure
> tree in the install package. Although I suppose I'll also
> need to mangle some of the directory settings in the CONFIG
> files to make sure they will work with the install tree directory
> locations rather than the (not packaged) bulid tree?

I don't think the mangling should be necessary, as long as your packages 
install everything into the same path as INSTALL_LOCATION I think it should 
Just Workâ.

> On the contrary, RPATH entries are essential to the way our
> packages are installed each to their own directory, otherwise
> each user would have to maintain an insanely long LD_LIBRARY_PATH.
> However, RPATHs pointing back to the build tree are not good,
> which is why I took to the hack of installing each library and
> binary in order and relinking it against the installed dependencies
> with appropriate install tree RPATH settings (as opposed to
> build tree RPATH settings).

I think INSTALL_LOCATION is your solution then because that sets RPATH to the 
right place and installs all the files you need.

HTH,

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System