 |
 |
Fabrice et al., > *1. Cleaning previous install :* > Please also note that you may have to remove the ~/.eups directory > before installing a new stack. People may have customizations in their ~/.eups directory; telling them to remove it (or, worse, doing it for them) is inadvisable. I think the only issue should be that packages in other stacks may be marked current, but this is not a problem if we use "eups distrib install -C". > *3. Rebuilding the code of an updated git repos :* > Once you've updated the code in your git repos, and want to run it, > you can use this workaround to rebuild/reinstall it in the same > stack directory : > *scons install prefix=$QSERV_DIR* > (Then, $VERSION may have became incorrect, but this is non-blocking.) This is pretty ugly. Switching out the code from under eups is not nice and will lead to problems when trying to do provenance or produce configurations for bug reports. Most LSST Stack packages work this way: 1) You can run from the directory where you built. This means that "setup -r ." and then building gives you a completely usable package. That allows rapid iteration of building and testing, without installing. We could change the Qserv build process to fulfill this constraint. 2) You can install the package in a stack. That installation shouldn't be touched thereafter. For Qserv, this means that the instance configuration needs to live somewhere *outside* the stack. This will also solve Jacek's problem of needing to switch between instances. Installed packages can be shared with others and have clean provenance. -- Kian-Tat Lim, LSST Data Management, [log in to unmask] ######################################################################## 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