Hello Daniel,
Thanks for this answer, i understand very well your arguments and
i agree with them.
Nevertheless, here's some more details which i ommitted in my
first email and which may help in defining a good solution :
Here's the
only file which is needed to implement the
custom.py solution in eupspkg (with TaP feature), neither
additional code is required :
eups@clrlsst-dbmaster-vm:~/eupspkg/contrib $ cat
qserv/patches/ldependencies_paths.patch
diff -rupN qserv.orig/core/custom.py qserv/core/custom.py
--- qserv.orig/core/custom.py 1970-01-01
01:00:00.000000000 +0100
+++ qserv/core/custom.py 2014-02-20 09:35:43.514467583
+0100
@@ -0,0 +1,17 @@
+import os
+import distutils.sysconfig as ds
+
+XROOTD_DIR=os.getenv("XROOTD_DIR")
+MYSQL_DIR=os.getenv("MYSQL_DIR")
+PROTOBUF_DIR=os.getenv("PROTOBUF_DIR")
+PYTHONPATH=os.getenv("PYTHONPATH")
+
+
+XROOTD_INC = os.path.join(XROOTD_DIR, "include","xrootd")
+MYSQL_INC = os.path.join(MYSQL_DIR,"include")
+
+MYSQL_LIB = os.path.join(MYSQL_DIR,"lib","mysql")
+XROOTD_LIB = os.path.join(XROOTD_DIR,"lib64")
+PROTOBUF_LIB = os.path.join(PROTOBUF_DIR,"lib")
+
+PROTOC=os.path.join(PROTOBUF_DIR,"bin","protoc")
(please note that qserv/ doesn't have to be the qserv source
directory, but only the directory containing qserv packaging for
eups, and qserv tarball)
Furthermore, with this solution, it would be possible to use the
default eupspkg procedure (which launch "scons" by default) and so
to remove the qserv/ups/eupspkh.sh configuration file from the
packaging.
Whereas, if we needed to launch "scons --eups", we would have to
overload build() and install() functions in "qserv/ups/eupspkh.sh"
So the custom.py solution would lead to less code in qserv build
system, and wouldn't add complexity in eupspkg packaging, except a
small and understable patch file. This could satisfying in the
short-term, don't you think so ?
Furthermore, eupspkg packages for Qserv have currently been
reviewed here :
https://dev.lsstcorp.org/trac/ticket/3149
and please note that K.T. made several times this remark about Mario and I eupspkg packaging :
Is it safe to depend on eups
using {PKGNAME}_DIR
environment variables?
Nevertheless, in my understanding, both the "custom.py" and the
"scons --eups" (cf. l. 65-66 in core/site_scons/eupsLib.py )
relies on
{PKGNAME}_DIR env variables.
I think that only sconsUtils may use an other technique to
retrieve dependencies path. So if we want not to rely on
{PKGNAME}_DIR path in the future, we may have to switch to
sconsUtils.
This could require complex updates of Qserv SConstruct file.
That's why i would propose next solution :
- in the short-term rely on "custom.py" technique, which is simple
and straightforward,
- in the mid-term, if we're sure we mustn't use {PKGNAME}_DIR,
develop a solution relying on sconsUtils. On the other hand, if we
know we can rely on {PKGNAME}_DIR, we could improve the first
technique, by using "scons --eups" for example.
I hope these proposals are worth being studied.
Have a nice day,
Fabrice
On 02/19/2014 08:43 PM, Daniel L. Wang wrote: