Day 3; not much time to work on this today. Too many meetings. A couple of useful tidbits from Robert
setup scons -v # gives you version number scons -u # searches up the directory tree for an SConstruct file, so I could run this in e.g. $LSST_DEVEL/DC2/scons/src/
I like this email from Robert - read on, people!
When Andy starts learning things about EA, he should add them to
the [wiki:EnterpriseArchitect EA wiki page]
(it's linked off the ToolSets page)
Whining should still be confined to his blog, so as to keep us reading it.
R
A very useful link from Robert on SCons, including a tutorial.
OK, back to the problem at hand. We are missing lsst.SConsUtils. I search the Wiki for SConsUtils and I find InstallingScons which shows how to get the Utils in the build system. This doesn't seem to have happened on darkstar; a locate SConsUtils only shows a directory in Russ's home directory, nothing in the build system. Its a bit unclear from InstallingScons where exactly I need to run the commands below (I think this is the anticipated difficulty with Scons' pseudo-integration with the build system) :
svn co svn+ssh://dev.lsstcorp.org/DC2/SConsUtils/tags/v1.5 SConsUtils
NOTE - The list of tags shows that v1.8 is the most recent; get this instead.
OK, to be frank, I don't totally understand the way Scons has been set up here (whining for RHL's sake). From reading InstallingScons I expect that locate sconsDistrib should show on darkstar.astro some installation either in the 'normal' place (/usr/local/) or in the build system ($LSST_HOME). However
becker15:locate sconsDistrib /home/rowen/build/SConsUtils/ups/.svn/props/sconsDistrib.table.svn-work /home/rowen/build/SConsUtils/ups/.svn/prop-base/sconsDistrib.table.svn-base /home/rowen/build/SConsUtils/ups/.svn/text-base/sconsDistrib.table.svn-base /home/rowen/build/SConsUtils/ups/sconsDistrib.table
So Russ has something in his own dir, but that is not so useful to me. And I have the scons executable at
becker152:which scons /lsst/lsst_root/Linux/external/scons/0.96.94/bin/scons
Some type of skullduggery has gone on here; I should talk to Russ about this. OK, from talking with Russ, it seems that he has not installed SConsUtils because he was waiting for it to be installable via Eups. Apparently this has not yet happened, or is not implemented, as the following checks indicate...
eups distrib -i -C LSSTPipe # update; this also installed 'consumer' eups list # only scons, no utils eups distrib -i -C scons # yep, its up to date eups distrib -i -C SConsUtils # nothing; tried all permutations of capital letters
Russ seemed to think that all I need to do is something like below (which means that the sconsDistrib 'bootstrapping' steps at InstallingScons are unncessary; sconsDistrib is now just scons)
cd /tmp/ svn export svn+ssh://dev.lsstcorp.org/DC2/SConsUtils/tags/v1.8 SConsUtils # don't 'co', since you won't be changing it. 'export' it instead! cd SConsUtils scons install current setup scons
Aaargh; the following happens
becker158:scons install current scons: Reading SConscript files ... scons: *** No tool named 'doxygen': not a Zip file File "python/lsst/SConsUtils.py", line 78, in MakeEnv
The tags for v1.8 indicate "Don't abort if doxygen is missing". It aborted. It also has a README file that I should pay attention to. It suggests the following course of action
$ XXX/bin/scons prefix=XXX version=YYY install declare
For me, XXX = /lsst/lsst_root/Linux/external/scons/0.96.94, and I think YYY = 1.8. So
becker162:/lsst/lsst_root/Linux/external/scons/0.96.94/bin/scons prefix=/lsst/lsst_root/Linux/external/scons/0.96.94 version=1.8 install declare scons: Reading SConscript files ... scons: *** No tool named 'doxygen': not a Zip file File "python/lsst/SConsUtils.py", line 78, in MakeEnv
So I think this is really a doxygen issue.
