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