Re: [boost] [modular boost] non-linked headers

Subject: Re: [boost] [modular boost] non-linked headers
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2013-12-02 22:09:51

AMDG

On 12/02/2013 05:06 PM, Bjørn Roald wrote:
> On 12/03/2013 01:48 AM, Daniel James wrote:
>> On 3 December 2013 00:32, Bjørn Roald <bjorn_at_[hidden]> wrote:
>>> not sure I understood exactly what you refer to, but I did just test
>>> command
>>> line concatenation, emacs, gedit, vim.  All of them seem to change
>>> the file
>>> as I expected.  What programs do you have in mind?
>>
>> Git for a start. If you check out a different version of a header it
>> will break the link.
> 
> In that case we should use symlinks for sure.  The problem here is that
> the dependency in b2 for the link should catch this in the build, but
> not if the date stamp move in the wrong direction. IBM cleamake solves
> this in clearcase views, but we do not have that build tool.  Using
> filetime "greater than" to detect dependency changes is a fundamentally
> broken hack used by almost all build tools.
> 

I thought that I wrote this to try symlinks first.
Anyway, if everyone agrees that the correct behavior
is to create a symlink, then it's really easy to
change.  Go to link.jam, find the rule do-file-link,
and switch the order that it checks hard links
and symlinks.

> As far as I remember symlinks to files are not Supported on windows
> prior to Vista, how much of a concern should that be?  I guess copies
> are annoying for XP hosts, but not as devious as I see hardlinks could be.
> 

A copy has no advantages over a hard link.
- If the source is overwritten in-place, then the
  hard link is still correct, and there is no problem.
- If the source is replaced, then the hard link is
  left pointing to the original file, and the
  state is essentially the same as if we had made
  a copy.

In Christ,
Steven Watanabe