Subject: |
Re: How do I install to $prefix/EPICS/bin, $prefix/EPICS/lib etc.? |
From: |
Andrew Johnson <[email protected]> |
To: |
[email protected] |
Date: |
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
- References:
- Re: How do I install to $prefix/EPICS/bin, $prefix/EPICS/lib etc.? Andrew Johnson
- Re: How do I install to $prefix/EPICS/bin, $prefix/EPICS/lib etc.? David Dudley
- Re: How do I install to $prefix/EPICS/bin, $prefix/EPICS/lib etc.? Gary V. Vaughan
- Navigate by Date:
- Prev:
Re: How do I install to $prefix/EPICS/bin, $prefix/EPICS/lib etc.? David Dudley
- Next:
Re: How do I install to $prefix/EPICS/bin, $prefix/EPICS/lib etc.? Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: How do I install to $prefix/EPICS/bin, $prefix/EPICS/lib etc.? J. Lewis Muir
- Next:
Re: How do I install to $prefix/EPICS/bin, $prefix/EPICS/lib etc.? Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|