Christopher Jefferson wrote:
File D.hpp is either standalone (if no directory D exists) or includes all files in subdirectory D. This way your abstraction gets you more than just information on how to negotiate the toplevel boost/ directories, and it matches current practice fairly well. Fusion has always struck me as quite clean:
% ls boost/fusion adapted/ container.hpp iterator.hpp support/ view.hpp adapted.hpp functional/ mpl/ support.hpp algorithm/ functional.hpp mpl.hpp tuple/ algorithm.hpp include/ sequence/ tuple.hpp container/ iterator/ sequence.hpp view/
I like your point about D.hpp being all there is for "D" or being a header that includes everything in the corresponding "D" subdirectory. However, look at the fallout illustrated by the directory listing you show: each "D" is duplicated. There's "adapted" and "adapted.hpp," "functional" and "functional.hpp," etc. The directory listing is complicated by this approach.
I find navigating such directory structures needlessly annoying: I can't use filename completion easily. With all.hpp, the directory name completes, with a trailing "/", and then I can type "all" and complete that. (Yes, I can get completion up to the "/" or "." and then type whichever I want to complete the header name or navigate into the subdirectory, but the partial completion can also mean that there are other files that begin with what I typed. I can't navigate as easily unless I already know the directory contents.)
I understand that switching to <libdir>/all.hpp is a breaking change for those libraries neatly arranged like Fusion, but I think the result will be cleaner. If the end result is thought sufficiently valuable, then the sooner the change is made, the fewer libraries will be broken. Delay just means more libraries may follow Fusion's lead and there will be more breakage. Thus, Boost needs to choose sooner than later.
I would like to strongly vote against all.hpp, in favour of fusion's approach :)
I very rarely tab-complete header file names, and I suspect most users don't either. Using 'all.hpp' means that when listing header files (for example because I want to know what file a particular function came from), you need more text to distinguish the file you are refering to. Having many identically named headers in different directories sounds to me like a recipe for confusion.
Further, I would STRONGLY disagree against needlessly breaking libraries. There is no reason that libraries can't, for a few versions, or even forever, support both versions (although this would break your tab-completing thing). There is nothing more annoying than boost libraries where it's almost impossible to write code that works over the set of versions users can reasonably be expected to have (which in our case is the latest versions in ubuntu, cygwin, and from the boost website). I'll put in a vote for the directory+.hpp style. Tab-completability does not bother me, especially when it will complete all the way to the extension and then it's a matter of picking '/' or '.' and doing another completion. That's much better than any change which would break existing code.
-Matt