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

Subject: Re: [boost] [modular boost] non-linked headers
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-02 22:26:53

On 12/03/2013 04:09 AM, Steven Watanabe wrote:
> 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.

You did, I think I deliberately changed the preference to hardlinks in 
my patch, probably a bad move.  I don't remember but I think I only got 
copies before the patch though, thats why I made changes to the rule in 
the first place, should have left the preference for symlinks the way it 
was.

> Go to link.jam, find the rule do-file-link,
> and switch the order that it checks hard links
> and symlinks.

Sure, but not today on my part, need to get some sleep.

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

+1

--
Bjørn