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 …
[View More]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?
[View Less]
- 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 …
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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 ...