Re: [boost] date_time -> serialization (Was: spirtit -> serialization)

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-06-16 05:08:23

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