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