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

Subject: Re: [boost] [modular boost] non-linked headers
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-12-03 08:24:58

On Tue, Dec 3, 2013 at 3:52 AM, Daniel James <daniel_at_[hidden]> wrote:

> On 3 December 2013 02:02, Beman Dawes <bdawes_at_[hidden]> wrote:
> > On Mon, Dec 2, 2013 at 7:11 PM, Daniel James <daniel_at_[hidden]>
> wrote:
> >
> >> On 3 December 2013 00:08, Bjørn Roald <bjorn_at_[hidden]> wrote:
> >> >
> >> > yes, but b2 headers create hard links
> >>
> >> It really should use soft links. Most programs don't change files in
> >> place, so as soon as such a change is made the two entries will be
> >> pointing to different inodes. Which defeats the purpose, since they
> >> should always be the same.
> >>
> >
> > I'm missing something. Could you give an example of what you mean by
> "Most
> > programs don't change files in place"? Hard links ensure that a change is
> > always seen by both the entries because there is only one underlying
> file.
> > I ran into that with Visual Studio when I tried symlinks and found that
> as
> > a result Visual Studio failed to realize when a dependency had changed.
>
> I corrected myself a bit later, it isn't "most" programs, but is many,
> especially things that involve unix shell scripting or want to update
> file atomically. I was also talking about using linux and os x, I
> don't know anything about hard links on windows. The problem is that
> different programs do different things. There's no consensus on what
> the semantic of hard links are - sometimes they are used as a cheap
> copy, sometimes to link two directory entries. And most programmers
> don't even think about this when writing software, so they usually
> stumble into one unknowingly (or even both). If you have a system you
> completely control you can ensure one or the other, but once your
> software is exposed to the world the other behaviour easily sneaks in.
> And because it's subtle, people often don't realise what's happening.
>
> Git deliberately breaks hard links, so that you can create a fast
> local clone using hardlinks and then checkout another branch without
> disrupting the original. Someone proposed making that an option, and
> it was rejected:
>
> http://thread.gmane.org/gmane.comp.version-control.git/97974
>
> For a demonstration, take a clean checkout of master and do this:
>
> ./b2 headers
> cd libs/detail
> git checkout develop -- include/boost/detail/iterator.hpp
> cd ../..
> diff boost/detail/iterator.hpp
> libs/detail/include/boost/detail/iterator.hpp
>
> This can be fixed by running 'b2 headers' again, but this isn't
> something that should be relied on - people use other build tools. I
> also wonder if there's a possibility that 'b2 headers' will choose the
> wrong file.
>
> Soft links also have other advantages, they make it clear which module
> the header file came from, and it's more immediately obvious that file
> is linked - especially in graphical tools.
>

I have no objection to changing to symlinks as the default behavior.

Whichever approach is used, I'm concerned about those developers who use
IDE's or build systems that will fail to notice changes with that approach.
At the least, we need to provide some documentation, and mention by name
any widely used IDE's or build systems that will have trouble. It would
also be helpful to suggest workarounds.

--Beman