Boost logo

Boost :

Subject: Re: [boost] [Git] Moving beyond arm waving?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2011-02-08 16:07:41


On 02/08/2011 09:00 PM, Steven Watanabe wrote:
> AMDG
>
> On 2/8/2011 11:20 AM, Dave Abrahams wrote:
>> At Mon, 7 Feb 2011 22:27:20 -0800 (PST),
>> Vicente Botet wrote:
>>>
>>> * the user will need to jump to the real headers to look for details
>>
>> Jump there from where? Any error messages will point at the real
>> headers. What
>> else is there?
>>
>
> At least for me, using the VS IDE, I open files
> via the #include directives on a regular basis.
> Having to jump through a forwarding header every
> time will get annoying.

It is not clear to me why this can not be a hard or soft link to the
real header that is in SCM. I much prefer that to an annoying
forwarding header or a copy. No avoidable look-alike duplicates
causing confusion please. Even Emacs will take you to the wrong copy of
the header, or at least the one you do not want to edit. You do not
need Visual Studio to get annoyed or confused by this stuff. I assure
you that having the build system write over your recent changes get this
point burned in. After a few times of that, it is hopefully just an
annoyance to have to look up the right copy of the header before you
make the your changes.

Git support for managing symbolic links exist, so that is a
possibility. However platform portability of these features must
ensured. Also I generally think this is better handled by the build, not
the SCM, that seems more appropriate.

Note also that using symbolic links may break the build dependency, I
guess it need testing. In any case you need rules in the build system
touching the links each time the header is changed. There are also
issues with cleaning up when headers are no more in use. For platforms
not having links, a copy can do just fine if we accept the annoyance.
This should be miner though as I think all major operating systems have
file systems with proper links these days.

-- Bjørn


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk