<div dir="ltr">Here's the script Robert alluded to:<div><br></div><div><a href="https://dev.lsstcorp.org/cgit/personal/jbosch/bot.git/tree/bin/declare-system-package.py" target="_blank">https://dev.lsstcorp.org/cgit/personal/jbosch/bot.git/tree/bin/declare-system-package.py</a><br></div><div><br></div><div>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):</div><div><br></div><div> - 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.</div><div><br></div><div> - 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.</div><div><br></div><div> - 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).</div><div><br></div><div>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").</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div><br></div><div>Hope that helps!</div><div><br></div><div>(and if anyone wants to take that script and use it as part of a more officially-supported build system, please go ahead!)</div><div><br></div><div>Jim</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 10, 2015 at 10:28 AM, Robert Lupton the Good <span dir="ltr"><<a href="mailto:rhl@astro.princeton.edu" target="_blank">rhl@astro.princeton.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Perhaps there is another step that could be added to David's second solution to make eups recognize an existing installation of boost<br>
<br>
</span>You probably don't really want to know this, but for the masochists...<br>
<br>
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.<br>
<br>
To use a pre-existing installation you need to:<br>
1. Find the proper .table and .cfg files<br>
2. Declare your version (say XXX) to eups<br>
3. Install the .cfg files in a visible place<br>
4. Tell the lsst distribution mechanisms about your choice.<br>
<br>
We're addressing three separate things here:<br>
Eups itself only requires the .table file and declaration [part of 1 and 2]<br>
The way we use scons (sconsUtils) requires the .cfg steps [part of 1 and 3]<br>
The way we distribute code (eups distrib, which is distinct from eups) requires the "tell the distro mechanism" step [4]<br>
<br>
The first step requires pulling a tarball and I don't remember the URL<br>
I'll address the second ("declare") step below<br>
The fourth means adding a line to a "manifest.remap" file like:<br>
boost:1.57 XXX<br>
I.e. "when eups distrib thinks it wants 'boost 1.57' tell it to use 'boost XXX'"<br>
<br>
I believe that Jim Bosch has a script to do all of this.<br>
<br>
R<br>
<br>
Here's the answer to, "how do I declare a project to eups":<br>
<br>
What's the layout of the pre-existing boost? If it's<br>
/foo/bar/lib<br>
/foo/bar/include<br>
(and I think it is), then all you need to find the proper table file somewhere, put it in tmp.table, and say:<br>
eups declare -r /foo/bar -M tmp.table boost XXX<br>
<br>
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<br>
eups list boost XXX -m<br>
(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)<br>
<br>
If you want to make it current, add "-c" or say<br>
eups declare -c boost XXX<br>
<br>
In this case, it's probably sufficient to fake a table file with:<br>
echo "pathPrepend(LD_LIBRARY_PATH, ${PRODUCT_DIR}/lib)" > tmp.table<br>
(or in one line<br>
echo "pathPrepend(LD_LIBRARY_PATH, ${PRODUCT_DIR}/lib)" | eups declare -r /foo/bar -M - boost XXX<br>
)<br>
<br>
</blockquote></div><br></div>