Boost logo

Boost :

Subject: Re: [boost] [chrono] Dependency on math?
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-01-10 08:22:44

On January 9, 2015 5:43:07 PM EST, alex <alexhighviz_at_[hidden]> wrote:
> Peter Dimov wrote
> > Sent: 09 January 2015 16:42
> > To: boost_at_[hidden]
> > Subject: Re: [boost] [chrono] Dependency on math?
> >
> > alex wrote:
> > > As I understand it, if library X depends on library Y and Y
> depends on
> > > Z, then X is said to depend on Z. I can understand as packages are
> > > created based on the library dependency graph:
> > >
> > > [ To package X we must package all libraries on which X depends.]
> > >
> > > However, the reality is that the file-dependencies of X do not
> > > necessarily include Z. Why would you not package only the files
> upon
> > > which the desired library depends?
> >
> > Because the package for X only contains X's files, not its
> dependencies.
> If X
> > depends on a file from Y, then Y's package must be installed to get
> Y's
> file.
> > And since Y is now installed, if it requires building, Z needs to be
> installed as
> > well; but even if it doesn't require building, having Y installed
> but
> unusable
> > is not good from usability point of view.
> Thanks for clarifying. I must say I am not convinced by the usability
> argument. Having just the files of Y and not the build makes library X
> usable. And X is what the user asked for. So, from a usability point
> of view it is perfect.

How do you know Y is usable at that point? To get what you want, a packaging tool has to be given much more information. If Y depends upon a header from Z, how does the tool know whether that Z header implies the need to build Z? Without that, the tool must assume that Z will need to be built. The same applies to the Y headers upon which X depends so Y must be installed ready to build.

If the tool knows that a library is header only, then it could be more selective about which files it installs. However, that leads to complicated dependency tracking of the installed files. If the user gets only a partial Y and a partial Z to satisfy X, and the user asks to install Y, the tool must install the rest of Y. But if the user then uninstalls Y, the tool must leave the parts of Y that were needed originally for X whilst removing the rest of Y. Since users can alter the contents of the installation directories, the tool must actually track all files it installs in order to be able to reinstall missing files to correct user mistakes, too.


(Sent from my portable computation engine)

Boost list run by bdawes at, gregod at, cpdaniel at, john at