https://dev.lsstcorp.org/trac/ticket/3149
and please note that K.T. made several times this remark about Mario and I eupspkg packaging :Is it safe to depend on eups using {PKGNAME}_DIR environment variables?
[log in to unmask]" type="cite">Hi Fabrice,
Qserv build ran successfully with eupspkg installed dependencies usingIt shouldn't, because I don't know enough of what I can derive from eups and how. The code is not implemented. If you show me the code you wrote to generate your custom.py, maybe I can finish it?
the "custom.py" configuration file.
But it doesn't seem to work while running command "scons --eups", or
"scons eups=1".
That's why, i propose you to use the "custom.py" configuration in theThis is not what the custom.py was intended to address...
eupspkg packaging.
Here's why i propose this :I agree. I'm sure that feature could do much more...
- the new TaP (Tarball and patch) eupspkg feature allow to VERY easily
patch custom.py file. I can create this packaging in a few minutes,
- having only one build process interface would be easier to maintainOk.
and document,
- we won't have to modify the qserv build code if we stop using eupspkg,But we'll have to modify and write new code somewhere. Wherever it is, it will need to be tracked and kept up to date.
- we won't have to modify the qserv build code if eups interface changeBut we'll have to modify the code that writes the custom.py file. I would rather cut out that step. Why not be more direct?
(for exemple the name of the env variables),
- the build process interface would be the same for a stand-alone buildThis is somewhat true. I wanted more integration for eups building, and I don't want to use files as a way of transmitting information from one part of qserv to another.
or a eups build, which would allow better debugging and understanding
for sysadmins,
- the "custom.py" technique could be also used in rpm and deb packaging,One interface, but it's more generality than is needed. 'custom.py' really is a way to insert arbitrary python code into the build system. Each of the other packaging systems requires some integration logic, and usually it is fragile because the people performing the packaging are usually not part of the development team of the software that is being packaged. In our case, we are one team writing the software and doing the packaging. I think there is less code to manage overall if it is more integrated.
and so their would be only one interface to maintain for all packaging
system,
- none of all the qserv dependencies, or stack dependencies, containNo, but there are eups-specific files there. The eups-specific plugin I propose is isolated.
eups specific code in their build scripts,
- it is less job for us, and leads to a simpler solution,I don't think so. You'll need to write the integration logic somewhere--whether it's bash/perl/python code to generate the right command line to a './configure' script or a build-configuration file or a plugin into the build system. It's just a matter of where it goes.
Would you agree with it ?I still need some convincing. One of the things I hate about qserv is that there are so many files that are created for passing information between its pieces. We have separate config files for the master/czar, proxy(sort of), my.cnf(worker AND master), and xrootd/cmsd. And in some way, we are asking the user to keep them consistent. Why? We control the code that generates every single one of them. Since we are writing the code that generates them, why do the generation only once during installation? If we can do the generation just-in-time, or not at all (maybe we can communicate the information directly!), we don't have to worry about those files being out of sync.
Do you think i miss some important point ?
If you insist, you might be able to convince me of a "pkgconfig.py" file that mostly works like custom.py, but I'd really rather not.
What do you think? I may have missed something as well.
-Daniel
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