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

Subject: Re: [boost] [modular boost] non-linked headers
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-12-03 17:22:10

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

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.

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.