Generic inclusion files (*.all)

11 views
Skip to first unread message

Julien Yann Dutheil

unread,
Mar 30, 2015, 6:38:44 AM3/30/15
to biopp-de...@googlegroups.com
Dear all,

I would like to express some concerns regarding the *.all files in the include directories. Such files are provided for convenience in order to simplify the inclusion of multiples classes at once. Originally, this was a reviewer request from the very first paper, to be able to include all models at once like #include <models>. Later, we redesigned the code structure into subdirectories, such as Bpp/Phyl/Model/Proteins, with corresponding files Proteins.all, Model.all, Phyl.all, etc. which include the content of the content of the directory in one shot. The *.all files are generated by a script, launched after installation.
Some libs, however, share the same directory structure, such as Bpp/Seq/Io used both by bpp-seq and bpp-seq-omics. This means that the *.all files have to be regenerated after each install/uninstall for the full directory tree. While this script method is rather tricky and error prone, Debian and Rpm packages handle this pretty well thanks to the post-install target. Things get more complicated for package managers like Homebrew (Mac), where "packages" are installed from source in a separate directory and then linked to their final destination. This means that *.all files have to be disabled there, as they will not behave correctly.
I would suggest to remove such files on all platforms. I cannot see a real use for them, but I can see several potential issues (not even mentioning the fact that including a lot of stuff you do not need is not particularly a good idea).

Does anybody would have objections to this removal, or have alternative solutions to propose?

Cheers,

J.

Laurent Guéguen

unread,
Mar 30, 2015, 9:30:39 AM3/30/15
to biopp-de...@googlegroups.com
Dear Julien,

but if we remove these .all files, it means that we will have to list all the .h files independently?
With the same concern as the reviewer, it may be quite a long list, for example for models.

A+
L

Julien Yann Dutheil

unread,
Mar 30, 2015, 9:42:45 AM3/30/15
to biopp-de...@googlegroups.com
Yes, we would have to do that. The thing is, when do we have to list all
models? The only example I can think of is the ApplicationTools class and
co. We can also set up a manual Models.h file, which would be a copy of the
Model.all file, but that we should maintain manually.

J.

Laurent Guéguen

unread,
Mar 31, 2015, 9:26:11 AM3/31/15
to biopp-de...@googlegroups.com
Ok, we can do it that way then.

A+
L
Reply all
Reply to author
Forward
0 new messages