[LSST|dm-users 553] Re: Boost install error in eups on OS X Yosemite

Jim Bosch jbosch at astro.princeton.edu
Tue Feb 10 10:50:21 PST 2015


Here's the script Robert alluded to:

https://dev.lsstcorp.org/cgit/personal/jbosch/bot.git/tree/bin/declare-system-package.py

You'll probably want to first run that with --help to see most of the
options, but here's a quick summary of how it works (you can compare this
to Robert's explanation to see how it checks off his list of things that
need to happen):

 - It downloads a git repo that contains the configuration information for
the external package - the .table and .cfg files (unfortunately this also
downloads a tarball for the external package that you don't need, so it
takes a while).  You'll want to designate a folder where all such repos
should go, and pass it to the script via the --external option.

 - It declares the package to Eups, using those configuration files, and
the directory you pass it using --productDir.  That directory should be a
"PREFIX"-like directory - it should have include/ and lib/ subdirectories.

 - It adds a line to your manifest.remap, which is found via the --remap
option (the location generally should be in the "site" directory you get
when you've installed the pipeline, at least if you're not sharing the
stack).

When you run it, you'll also have to pass the name of the product and a
version (but the version can just be something that describes it, not the
regular version number, like "system" or "homebrew").

If you need to back out any of this and try again, you can just do "eups
undeclare <name> <version>", then run declare-system-package.py again.

Unfortunately, there is a major limitation in doing this on OS X:
frequently, the third-party package you want to use is in the same
directory as a bunch of of other third-party packages (this is what
MacPorts does, at least).  The way we use the DYLD_LIBRARY_PATH variable
will cause other third-party packages in that directory (which you don't
want to be used) to be picked up instead of other versions.  As far as I
know, the only way to work around this is to symlink all of the files that
belong to one package into a different root directory (also with include/
and lib/) subdirectories, and use that as the argument to --productDir.  I
think I've heard that Homebrew creates those per-package directories
itself, which may be one reason it's seems to be preferred by LSST
developers (disclaimer: I'm not a Mac user, so I'm not an expert on these
things).


Hope that helps!

(and if anyone wants to take that script and use it as part of a more
officially-supported build system, please go ahead!)

Jim





On Tue, Feb 10, 2015 at 10:28 AM, Robert Lupton the Good <
rhl at astro.princeton.edu> wrote:

> > Perhaps there is another step that could be added to David's second
> solution to make eups recognize an existing installation of boost
>
> You probably don't really want to know this, but for the masochists...
>
> Unfortunately it's a bit worse than that, as we also use the equivalent of
> pkg-config (the so-called .cfg files).   Should we?  Maybe not, that's a
> different question and one that we could profitably discuss.
>
> To use a pre-existing installation you need to:
>         1.  Find the proper .table and .cfg files
>         2.  Declare your version (say XXX) to eups
>         3.  Install the .cfg files in a visible place
>         4.  Tell the lsst distribution mechanisms about your choice.
>
> We're addressing three separate things here:
>         Eups itself only requires the .table file and declaration [part of
> 1 and 2]
>         The way we use scons (sconsUtils) requires the .cfg steps [part of
> 1 and 3]
>         The way we distribute code (eups distrib, which is distinct from
> eups) requires the "tell the distro mechanism" step [4]
>
> The first step requires pulling a tarball and I don't remember the URL
> I'll address the second ("declare") step below
> The fourth means adding a line to a "manifest.remap" file like:
>         boost:1.57      XXX
> I.e. "when eups distrib thinks it wants 'boost 1.57' tell it to use 'boost
> XXX'"
>
> I believe that Jim Bosch has a script to do all of this.
>
>                                                 R
>
> Here's the answer to, "how do I declare a project to eups":
>
> What's the layout of the pre-existing boost?  If it's
>         /foo/bar/lib
>         /foo/bar/include
> (and I think it is), then all you need to find the proper table file
> somewhere, put it in tmp.table, and say:
>         eups declare -r /foo/bar -M tmp.table boost XXX
>
> i.e.  "Declare a version of boost called 'XXX' with directory /foo/bar and
> table file tmp.table.  Make a copy of tmp.table and squirrel it away".  If
> you want to know where the squirrel caches its nuts, say
>         eups list boost XXX -m
> (why -m?  I don't know -- ask FNAL.  But -m is the standard abbreviation
> for --table and -M is the "use a tmp file" version)
>
> If you want to make it current, add "-c" or say
>         eups declare -c boost XXX
>
> In this case, it's probably sufficient to fake a table file with:
>         echo "pathPrepend(LD_LIBRARY_PATH, ${PRODUCT_DIR}/lib)" > tmp.table
> (or in one line
>         echo "pathPrepend(LD_LIBRARY_PATH, ${PRODUCT_DIR}/lib)" | eups
> declare -r /foo/bar -M - boost XXX
> )
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lsst.org/pipermail/dm-users/attachments/20150210/3459df01/attachment.html>


More information about the dm-users mailing list