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

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-16 00:40:22

Le 16/06/14 01:51, Julian Gonggrijp a écrit :
> Andrey Semashev wrote:
>
>> On Sunday 15 June 2014 23:45:37 Julian Gonggrijp wrote:
>>> I just caught up with this discussion, and based on what I read I
>>> think the future automated dependency handler should indeed operate on
>>> a per-header basis. This would mean that the configuration file of a
>>> module would list all headers in the module, and for each header in
>>> the module list all headers that it directly depends on. Of course
>>> still with support for conditional (e.g. tool-dependent) dependency
>>> annotations. *Optional* dependencies however could then be detected
>>> automatically, as I'll explain in my inline reply below.
>> Umm, I don't think that manually listing all headers and their dependencies in
>> a config file is a viable idea.
> That is not the intention. The tool generates the file for you (when
> you ask for it). The file is still there so you can annotate it with
> tool conditions. Having a single file that lists all header
> dependencies also speeds up automated downloading, because the tool
> doesn't have to traverse your 235 headers but can find all
> information in one place.
>
> The tool will also be able to update the file while respecting your
> annotations. It will also be invoked as a part of the regression
> tests to check that the file is complete.
>
> See also http://lists.boost.org/Archives/boost/2014/06/214429.php .
Hi Julian,

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.
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.
What is needed is the association of a file and a sub-module 
(sub-sub-module). Currently this is defined by the directory structure.

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?
Could you show an example of the file you pretend the authors of a 
library need to maintain?

Best,
Vicente
>> I have 235 headers in Log and who knows how
>> many dependent headers. Even if that information is filled once, I can't
>> realistically guarantee that the config file stays actual as I work on the
>> library.
>>
>> The list of headers and their dependencies should be inferred by the tool from
>> the headers themselves.
> Yes.
>
>> Maintainers should be able to provide only the missing
>> information - in particular, which headers are considered optional. Although,
>> if the tool works on the header basis, the whole idea of optional headers
>> becomes irrelevant - you don't include a header => you don't need its
>> dependencies.
> Exactly. /Conditional/ dependencies are still relevant, however.
>
> -Julian
>