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
|