Subject: Re: [boost] [chrono] Dependency on math?
From: alex (alexhighviz_at_[hidden])
Date: 2015-01-10 16:43:20
> > If you would just tell the package manager which header files require
> > building and which not....
> There must be information on each file, at least if the library isn't
> header only. Both pieces of information can become stale after just one
> maintenance change, so it is brittle.
Yes you would need information for each file, but you could have defaults
for the library or directories.
Would you call a code change that introduces a requirement to build
'maintenance' ? It would be a breaking change for users that did not build
A code change that removes a requirement to build but not marked as such
would not cause a problem; it just means that sometimes the library would be
> There's also the question of where to
> store that information. Is it per host? per user?
Isn't it obvious that it should be per host? The user shouldn't be expected
> > 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.
Isn't the whole idea that the users express what they want and then get the
package containing what they need?
> > > Since users can alter the contents of the installation directories,
> > > the tool must actually track all files it installs in order to be able
> > > reinstall missing files to correct user mistakes, too.
> That would still be an issue.
Yes, but very solvable and I would think it already needs to do this anyway.
>From you responses I gather that resolving dependencies at file level would
cause too many complications for built libraries but not so for header-only
libraries. Why not at least take advantage of the header-only status of a
large number of libraries? I suppose this would create an incentive to split
existing libraries into a built and header-only library, but that is not so
bad is it?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk