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

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

On January 10, 2015 11:04:29 AM EST, alex <alexhighviz_at_[hidden]> wrote:
> >
> > 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. 

There must be information on each file, at least if the library isn't marked header only. Both pieces of information can become stale after just one maintenance change, so it is brittle. There's also the question of where to store that information. Is it per host? per user?

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

I was trying to imply that, indirectly, but the tool will need to be smart enough to know when the user expressly wanted Y versus needing Y because of X.

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

That would still be an issue.

___
Rob

(Sent from my portable computation engine)