Jacek, Okay, thanks for pointing this out. For db and ?logging?, let's make sure they include only assumptions that make sense for all LSST code (including Qserv and it's potentially non-LSST, non-science users). Of course, those specific assumptions need to get in somehow, so maybe cat has it's own wrapper/plugin for db, and qserv has its own wrapper/plugin for ?logging?. What do you think? -Daniel On 01/10/2014 11:19 AM, Becla, Jacek wrote: > Daniel > > Qserv also has (or will have) dependencies on three other, relatively > simple packages from lsst: geom, db and whatever package logging ends up in. > > Jacek > > > On 01/10/2014 10:05 AM, Daniel L. Wang wrote: >> Hi Fabrice, >> >> My vision of qserv is that some time part-way through construction, a >> sysadmin will be able to install qserv via yum (RHEL/Fedora) or apt >> (Debian/Ubuntu). By then, I hope that all dependencies will be included >> in both RHEL and Ubuntu. The only dependencies not included yet are: >> * xrootd (qserv-specific changes should be on mainline in ~2 years) >> * scisql (probably easy to package) >> * nearly-forgotten lua-related libs >> Eliminating the problem lua packages is on the roadmap for qserv. Xrootd >> is already there, and the right version should land soon. I am willing >> to maintain RPMs for scisql. >> >> So the vision is not too far. If we add sconsutils, we would need to see >> that packaged in .deb or .rpm. The LSST stack has complex versioning and >> sandboxing requirements that I think are less appropriate for qserv. >> >> Indeed, during the hack week, we decided on a directory layout that is >> somewhat more complex than the LSST layout, so we wouldn't be able to >> reuse that part of sconsutils. Don't worry about the scons >> complexity--it is already much simpler than before (though I have not >> yet cleaned the obsolete parts out). I am also not ruling out Cmake. >> >> Can you clarify what functionality you are hoping to get? My instinct is >> that our needs are so much simpler that whatever redundancy is smaller >> and simpler than the adaptation needed to use sconsutils. I'd rather not >> tie any part of the build process to eups, any more than building SWIG, >> Python, or boost is dependent on eups. >> >> Hope this helps, >> -Daniel >> >> >> On 01/10/2014 12:43 AM, Fabrice Jammes wrote: >>> Hello Daniel, >>> >>> Thanks a lot for your answer on my previous email (cf. [QSERV-L] Some >>> questions about building Qserv in branch u/danielw/modules1) >>> >>> Here's below an usefull answer from Jim Bosch about sconsUtils. >>> It seems it may be suitable to detect and link Qserv dependencies. >>> We may use this in order to remove this code from Qserv scons scripts >>> and lighten them ? >>> >>> K.T., could you please give your opinion about sconsUtils use, it >>> would be very usefull ? >>> Indeed, it would allow that Daniel and I to fit to LSST architectural >>> requirements ;-), and work in the right direction. >>> >>> Have a nice day, >>> >>> Fabrice >>> >>> >>> -------- Original Message -------- >>> Subject: Re: [QSERV-L] [LSST-data] Some more question about Qserv >>> packaging with eups. >>> Date: Thu, 2 Jan 2014 11:14:03 -0500 >>> From: Jim Bosch <[log in to unmask]> >>> To: Fabrice Jammes <[log in to unmask]> >>> CC: Kian-Tat Lim <[log in to unmask]>, qserv-l >>> <[log in to unmask]>, LSST Data <[log in to unmask]> >>> >>> >>> >>> I'll limit my responses to questions about sconsUtils, as that's the >>> only area where I'm really an expert here. >>> >>> On Thu, Dec 26, 2013 at 5:02 AM, Fabrice Jammes<[log in to unmask]> wrote: >>> >>>> - Do you think Qserv build should relies on sconsutils ? >>> I don't think this is as important as relying on EUPS; I personally >>> think Qserv should use sconsUtils only if it is convenient to do so. >>> It basically provides a configuration system and convenience functions >>> that allow SCons scripts to be much more concise if the package is >>> laid out in a certain way and you're willing to commit to creating >>> .cfg files that describe all of your dependencies. In particular, it >>> will be most helpful if: >>> - You have a lot of compiled code; a lot of what sconsUtils provides >>> is configuration of various compiler build variables (include >>> directories, library directories, etc). >>> - You organize the package in the same way as most DM packages, with >>> doc, include, lib, python, src, and ups directories. >>> - You use Swig to build Python wrappers for C++ code and need to >>> build against Swig modules created by dependencies. >>> >>>> - Do you thinks sconsutils may be compatible with rpm format ? >>> Most of it is, and possibly all of it. The part I'd be concerned with >>> is the need for .cfg files not just for your own package but for all >>> your dependencies as well. So if your dependencies come from other >>> rpms, you'd need .cfg files for those too. But they wouldn't need to >>> be installed with those dependencies; you could package them directly >>> with Qserv too. Other than that, using sconsUtils with rpm shouldn't >>> be any different from any other SCons-based build system. >>> >>> Jim >>> >>> ######################################################################## >>> 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 >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> 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 >>> >> ######################################################################## >> 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 >> ######################################################################## 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