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