Vicente J. Botet Escriba wrote:
I don't think that the configuration file should contain the file dependencies, only the module dependencies are really needed and are easy to maintain.
Consider this problem pointed out by Peter: module X X.hpp module Y Y1.hpp Y2.hpp (optional) includes X.hpp module Z Z.hpp includes Y2.hpp If the configuration file contains only module-level dependency information, the handler will not be able to decide whether Z depends on X based on the file alone. The question is how to solve that. I can think of a few options: (1) Also annotate reverse dependencies in the configuration file, i.e. "this dependency is optional unless you want to install some_other_module". This leads to duplicate information, so it doesn't seem like a good idea to me. It would also require the handler to have access to all of Boost in order to detect such reverse dependencies. (2) Have the tool process all *pp files in a module live, every time it handles the module. This would slow down matters dramatically, apart from being an ugly solution in itself. (3) Isolate all optional dependencies into separate modules. I am convinced that this would severely complicate the directory layout, and take apart headers that semantically belong together. In fact I'm not 100% convinced that it will solve the optional dependency problem, unless each individual header becomes a module of its own. (4) Include header-level dependency information at full detail in the configuration file. It does not *need* to be maintained, because the tool can create, update and verify the file automatically. It also doesn't rule out the possibility to keep a module-level summary at the top of the file for casual readers.
The boostdep tool give us the reasons why we depend on a module so if we want to refine our module dependency files we have the needed information.
I can think of several possible interpretations for this sentence. Could you please restate in other words what you intended to say?
What is needed is the association of a file and a sub-module (sub-sub-module). Currently this is defined by the directory structure.
This is option (3) from above. Like Andrey, I believe that basing decisions on header-level information is the better way to go.
Could you tell us more about how do you plan to manage the conditional dependencies? Which kind of conditions could be stated? platform, compiler, user defined?
All conditions that Boost.Build knows about. If I'm right that includes platform and compiler (toolset) but not anything user-defined.
Could you show an example
Sure. Suppose that the tool generates the following file for mymodule: # module-level information may appear at the top, not shown here mymodule.hpp mymodule/core.hpp mymodule/utility.hpp mymodule/core.hpp config.hpp mymodule/detail/god_object.hpp mymodule/utility.hpp config.hpp mymodule/core.hpp mymodule/detail/hacks.hpp compressed_pair.hpp mymodule/filesystem.hpp mymodule/core.hpp filesystem.hpp mymodule/haiku.hpp mymodule/core.hpp mymodule/detail/hacks.hpp container/vector.hpp # mymodule/detail/ headers are standalone Based on just this information, the handler can tell that config and compressed_pair are fixed dependencies while filesystem and container are optional. Now we can annotate that mymodule/utility.hpp and container/vector.hpp are conditional on the compiler: mymodule.hpp mymodule/core.hpp <toolset>msvc-7,<toolset>msvc-8:mymodule/utility.hpp mymodule/core.hpp config.hpp mymodule/detail/god_object.hpp mymodule/utility.hpp config.hpp mymodule/core.hpp mymodule/detail/hacks.hpp compressed_pair.hpp mymodule/filesystem.hpp mymodule/core.hpp filesystem.hpp mymodule/haiku.hpp mymodule/core.hpp mymodule/detail/hacks.hpp <toolset>gcc-2:container/vector.hpp Now we're at it, we can make life easier for Haiku users and conditionally include mymodule/haiku.hpp into the catch-all header: mymodule.hpp mymodule/core.hpp <toolset>msvc-7,<toolset>msvc-8:mymodule/utility.hpp <os>Haiku:mymodule/haiku.hpp mymodule/core.hpp config.hpp mymodule/detail/god_object.hpp mymodule/utility.hpp config.hpp mymodule/core.hpp mymodule/detail/hacks.hpp compressed_pair.hpp mymodule/filesystem.hpp mymodule/core.hpp filesystem.hpp mymodule/haiku.hpp mymodule/core.hpp mymodule/detail/hacks.hpp <toolset>gcc-2:container/vector.hpp This is the module-level information that the handler may extract from the last version: fixed: config <toolset>msvc-7,<toolset>msvc-8:compressed_pair <os>Haiku,<toolset>gcc-2:container optional: filesystem
of the file you pretend the authors of a library need to maintain?
I want to emphasize that library authors would not *need* to maintain the file. Making annotations is beneficial (because it slims down dependencies under certain conditions) but not necessary. The file will be complete and valid without human intervention. -Julian