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

Subject: Re: [boost] [modular boost] non-linked headers
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-03 22:32:14

On 12/3/2013 5:22 PM, Gavin Lambert wrote:
> On 4/12/2013 02:24, Quoth Beman Dawes:
>>> 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.
>
> Would symlinks even solve that issue?  I could be wrong, but I would
> think that a tool or editor that followed the delete-move pattern would
> break symlinks just as easily as hardlinks, unless they explicitly
> followed the symlink to the "real" file and used that path in the
> delete-move.  (And at least on Windows, most programs are not
> symlink-aware, partly because links are fairly rare.)

The delete-move pattern does not break symlinks. Since a symlink is only 
a pointer to another full file name, as long as the name remains the 
same after the delete-move the symlink still works correctly.

>
> Although it's true that symlinks are more obvious as such, so that might
> possibly encourage people to edit the "real" file instead of the linked
> version.

The grammar above is confusing. If you edit the file by specifying the 
symlink location you are editing the "real" file.

>
> Would it be possible to link only at the whole-directory level, rather
> than individual files?  I think behaviour is much more stable and
> desirable that way (and it should fix the make-timestamp issue too).  To
> support this, the top-level headers could be owned by the main
> repository, and (where not already) just be a thin redirect into the
> "real" headers in the library's linked subdir.
>
> It would mean a bit of restructuring for some of the older libraries,
> but that's probably a good thing overall for modularisation.

Certainly this could be done, but I see no necessity for it if symlinks 
are used, other than a possibly better design of some header file locations.

Let's get Modular Boost working correctly for programmers now by 
replacing the "b2 headers" command with one that uses symlinks rather 
than hardlinks. Then if we want to consider header file placement we can 
do that as a further chore in the future.