IMP-dev January 2013

imp-dev@salilab.org

2 participants
6 discussions

Requiring an extra step to do an in-source build of IMP
by Daniel Russel 31 Jan '13

31 Jan '13

Once you run scons in your IMP source directory, it is hard to get the source directory back into a state where you can do an out of source build, and, in general, the easiest is to simply check IMP out again. In addition, the failure modes when attempting an out of source build are rather odd. Since quite a number of people have run into this problem, and in-source builds of IMP are not something we want to encourage, I'd like to change the behavior a bit: - make the repository argument required. You can use "." if you want to do an in-source build - print an error message and terminate the build immediately with a message to the effect that "You should do an out of source build. If you, for some reason, really want to do an in-source build, add repository=. to your config." Seem reasonable?

1 0

Recently in IMP
by Daniel Russel 23 Jan '13

23 Jan '13

- Support for \imp-wide command line flags have been added to IMP::base in the base/flags.h file. They provide a simple command line parsing interface that can be used from C++ and python. In addition, various functionality in \imp is automatically exposed on the commend line when those functions are used. For example, one can control logging, checks or profiling. See IMP/base/flags.h for (some) more info. - OpenMP support in IMP is officially released. All tests pass. But there has been little specific testing so far. - Access to attributes using IMP::ParticleIndex and the IMP::Model now works from Python. See IMP::Model::add_attribute() and kin. - IMP::ParticleKey and IMP::ParticlesKey were renamed to IMP::ParticleIndexKey and IMP::ParticleIndexesKey respectively as that is what they store. Typedefs were provided to support old code. - Indexes have been added to the docs connecting classes with all the methods that return them, examples that use them and methods that take them. And all methods that are used in examples with the examples they are used in. Please check them out and report issues and ways to improve things. You can find links on the main page. - The docs for a modules/biological systems/applications should now be found in an `overview.dox` in the module `doc` folder. Modules in \imp svn have been updated. For external modules, you can just move a `overview.dox` from that was previously generated into your `doc` folder and (eventually) remove the lines from your `doc/SConscript`. This makes it easier to use the full range of doxygen markup, as well as removes the need to escape doxygen markup for python. - Examples have now been simplified into full blown doxygen examples. This involves merging the `.py` and `.readme` files (putting `\#\#` in front of each line of the `.readme`) and adding a `## \\example module/examplename.py` line at the begginning. You can use `./tools/updaters/update_examples.py modules/mymodule` to update a module that was not already updated. - IMP::base::FailureHandler has been removed as it wasn't used. - Handling of data and includes has been simplified. All appropriate files in the corresponding directories are linked into build/installed. This is only likely to be a problem if you had broken headers sitting around `include`. If so, just `\#if 0` them out, or move them some place nicer. - Modules now must be in a folder called `modules`, which must have an `SConscript` file. - The build system should now be a little better about cleaning up after itself. - How headers/doc files/data/examples - The IMP_PROTECTED macros didn't work out well, and are now deprecated. Sorry. If you had python implementations on top of IMP base classes that implement protected virtual methods, you may need to remove a leading "_" on the method name. - Nice version numbers will now be generated if you use git. You need to rerun tools/git/developer_tools/init_git if you have an existings clone.

1 0

And more simplifications
by Daniel Russel 15 Jan '13

15 Jan '13

To help reduce the amount of logic that is in your crazy mess of a build script and to take advantage of improvements in doxygen, I'd like make 2 changes: - instead of examples having a separate readme file, they will be more normal doxygen examples that start with a comment and an \example line with the files name (like headers do) - module overview information will be stored in a file called overview.dox that you can edit directly, rather than have it be generated from data passed to SConscript. The data has to be escaped properly and is kind of a pain to deal with. Both of these I will do for all the modules in the repository and I'll provide a script that can update the example files of a given model for modules that are elsewhere (since I have to interest in making such changes myself anyway :-). I don't expect this to cause problems since I don't think people other than us generate docs.

1 0

More proposed simplifications to IMP
by Daniel Russel 15 Jan '13

15 Jan '13

I'd like to remove support for explicitly listing headers/source files in SConscript files. The default behavior, and the one we recommend that people use is that the SConscript simply finds all the .cpp or .h files in the appropriate directories (like how it finds all tests in the test directory). Since broken .cpp or .h files mixed in with the real source make reading/greping the code more confusing and they can easily be moved elsewhere there isn't really much point in the excluding files by not listing them. And it creates the prospect for bugs when headers or source files are left out of the list. Let me know if there are any objections.

1 0

Proposed removals from IMP
by Daniel Russel 14 Jan '13

14 Jan '13

As part of a cleanup on various things IMP, I'd like to remove the following bits of functionality that I suspect are unused/ or are problematic - FailureHandler: I don't think anyone uses this functionality - the ability to define modules in arbitrary locations (outside a modules folder or as part of a biological system): this will require a small amount of work for people who build modules externally to IMP (since they will have to put their module into a folder called modules if it isn't there already). But doing so would allow us to move a bunch of logic out of scons (which is really slow) and would simplify builds. - application of IMP_PROTECTED to virtual methods: adding this wasn't a terribly good idea on my part. SWIG will wrap protected virtual methods and we don't have enough non-virtual protected methods to be too interesting. And the existing macros (and any way I can figure out how to implement them) messes with Doxygen.

1 0

FAQ for developers
by Javier Velazquez 09 Jan '13

09 Jan '13

Hi Daniel and I have started a FAQ section for developers in the github wiki for IMP. Here https://github.com/salilab/imp/wiki/FAQ-for-developers It is intended to include those somewhat detailed or tricky things that you were fighting with until you asked Daniel or just figure them out yourself. If you have some, put them there. It will help others. The FAQ section is not intended to contain any tutorial questions. Just code problems / bugs / why your are getting those beautiful segfaults, etc ...

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev January 2013