Print

Print


Hello Bill,

Sorry Bill but I can't reproduce your problem with scons of my machine.
Nevertheless, I suspect a conflict in scons versions.

Furthermore, it seems you have qserv code here :

/u1/bchick/sandbox2/qserv-branchtest/

and install dir here :

/u1/bchick/sandbox2/


First, i strongly recommand you to extract qserv source code from qserv 
install dir,
for example move it in :

/u1/bchick/src/qserv-branchtest/

Then in /u1/bchick/src/qserv-branchtest/ run :
scons uninstall
and then :
scons


If your still meeting the scons issue you report, here's a few questions 
which should help you in diagnose it :

*1. *Do you have "scons" rpm provided by SL6 installed on your system ?
(do you have launched, under root account, the script 
%QSERV_SRC_DIR/admin/bootstrap/qserv-install-deps-sl6.sh which install it ?)

*2.* Do you use this rpm version :
Here's what i get after having installed qserv distribution dependencies 
with qserv-install-deps-sl6.sh :

[fjammes@clrlsst-dbmaster-vm qserv]$ which scons
*/usr/bin/scons*

If you don't get the same path, it is possible that you still run a 
compiled version of scons, which was installed by previous versions of 
Qserv.
In this case run
scons uninstall
and then check that
which scons
give the same output than me.
*
**3. *If the above is ok and the problem still persist, which version of 
scons do you have ?
Here's mine :
[fjammes@clrlsst-dbmaster-vm qserv]$ scons --version
SCons by Steven Knight et al.:
     script: v2.0.1.r5134, 2010/08/16 23:02:40, by bdeegan on cooldog
     engine: v2.0.1.r5134, 2010/08/16 23:02:40, by bdeegan on cooldog
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 
The SCons Foundation

*4. *If the problem still persist, please could you try launching the 
attached script ?
It will install qserv (same as qserv-install, but in shell and for 
qserv-master only)
and give me the failure message.

Thanks,

Fabrice


On 09/27/2013 11:21 PM, Kian-Tat Lim wrote:
> Serge,
>
>> I think scons might be ignoring the ambient environment (PATH,
>> LD_LIBRARY_PATH, etc...) when it is run, instead setting up its own
>> (presumably in the name of providing repeatable builds).
> 	scons does not by default pass variables from the environment in
> which it is invoked to the processes it invokes, precisely to provide
> repeatable builds.
>
> | scons does not automatically propagate the external environment used to
> | execute scons to the commands used to build target files. This is so
> | that builds will be guaranteed repeatable regardless of the environment
> | variables set at the time scons is invoked. This also means that if the
> | compiler or other commands that you want to use to build your target
> | files are not in standard system locations, scons will not find them
> | unless you explicitly set the PATH to include those locations. Whenever
> | you create an scons construction environment, you can propagate the
> | value of PATH from your external environment as follows:
> |
> |     import os
> |     env = Environment(ENV = {'PATH' : os.environ['PATH']})
>


########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1