On Nov 23, 2010, at 11:10 AM, Dina Schneidman wrote:
> I think that it is simple enough today to have two separate builds.
> The major obstacle is that those builds take forever to build, and you
> really don't want to wait for them, when you want to commit 3 lines of
> code.
Yeah, but that is a bit harder to solve (at least part is due to deep flaws in scons which I haven't yet managed to work around). On that note, once ccache 3 makes it to our linux distribution, it could be really nice to have a lab ccache repository as we are basically all doing the same compinaltions and ccache would simply fetch the results someone else built earlier ones rather than rebuild them.
>
> On Tue, Nov 23, 2010 at 9:19 AM, Daniel Russel <> wrote:
>> I think it very important that people run their code with checks turned on at least once to make sure there aren't obvious usage errors and most people seem to want speed and hence also want to run production code against a fast IMP build. Has this been has the current setup discouraged anyone from doing multiple builds?
>>
>> Currently, having two separate builds requires doing something like:
>> - svn co https://svn.salilab.org/imp/trunk imp
>> - mkdir release
>> - ./imp/tools/setup-out-of-source release
>> - cd release
>> - scons -j 4 config.py build=release path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include
>> - scons -j 4
>> - ./tools/imppy.sh python myscript.py
>> - mkdir fast
>> - ./imp/tools/setup-out-of-source fast
>> - cd fast
>> - scons -j 4 config.py build=fast path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include
>> - scons -j 4
>> - ./tools/imppy.sh python myscript.py
>>
>> It could be made easier eg:
>>
>> Options:
>> 1) provide release and fast subdirectories in the svn checkout. This would be very easy to implement. Usage would then be something like,
>> - svn co https://svn.salilab.org/imp/trunk imp
>> - cd imp
>> - ./configure path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include
>> - cd release
>> - scons -j 4
>> - ./imppy.sh python myscript.py
>> - cd ../fast
>> - scons -j 4
>> - ./imppy.sh python myscript.py
>>
>> Unfortunately with both this and the current setup, installing release and fast versions of IMP requires installing them in separate locations and then switching around your LD_LIBRARY_PATH and PYTHON_PATH to switch between them. But a model where by you run with release on your machine and fast on the cluster would work fine. We could provide imppy.sh equivalents for once IMP is installed.
>>
>> 2) use an environment or python variable to switch on load time (warning, I don't actually know how to implement this, but suspect it can be done).
>> - svn co https://svn.salilab.org/imp/trunk imp
>> - cd imp
>> - scons config.py path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include or ./configure path=/opt/local/bin libpath=/opt/local/lib includepath=/opt/local/include
>> - scons -j 4 #build both fast and release
>> - ./tools/imppy.release.sh python myscript.sh
>> - ./tools/imppy.fast.sh python myscript.sh
>> One could then install IMP normally (there would be libs like lib_imp_fast and lib_imp_release) and the right one could be chosen at runtime with an environment variable (or perhaps something more clever entirely within python)
>>
>>
>> _______________________________________________
>> IMP-dev mailing list
>>
>> https://salilab.org/mailman/listinfo/imp-dev
>>
>
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev