 |
 |
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