Re: [boost] [chrono] Dependency on math?

Subject: Re: [boost] [chrono] Dependency on math?
From: alex (alexhighviz_at_[hidden])
Date: 2015-01-10 11:04:29

>
> > 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.
> 

Is it really that much more information that needs to be given? If you would
just tell the package manager which header files require building and which
not, would that not enable it to remove many dependencies based on the
assumption that all headers require building. If such information were
absent you could always revert to the original assumption that everything
needs to be build. 
 
> If the tool knows that a library is header only, 

Well, large parts of BOOST are header-only and libraries that are not
header-only often only rely on being built for some specific functionality.

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 

It would be very complicated if you wanted to optimize and really copy only
the files that are essential. However I suggest to only get complete
libraries, but  also only get libraries that are actually depended (based on
recursive file dependencies) on and not all libraries that are depended on
based on recursive library dependencies. 

> 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.

That is why I thought it would be good to always get all files of a library,
even if not all files are needed. 

> 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.
> 
> Rob
>