Sorry, another question: I am planning to use a call to regexec() near the beginning of builtin_normalize_path() to detect a UNC path and trigger different behavior in the rest of the function. Do you think this would significantly affect performance? I think this may be a good regex: "^[/\\]{2}[^/\\:]+[/\\]+[^/\\]"

Thanks,
Jim

On Thu, Aug 30, 2012 at 8:41 AM, Jim Gallagher <jim@thegallaghers.biz> wrote:
Jurko,

OK, thanks for the info. I will have to "roll my own" patch, as our build automation is changing and drive letters will not be an option for shares.

Do you have any thoughts as to areas that will require changes? Our specific use for UNC paths will be for third party libraries.

Thanks,
Jim Gallagher


Date: Thu, 30 Aug 2012 00:39:39 +0200
From: Jurko Gospodneti? <jurko.gospodnetic@pke.hr>
To: boost-build@lists.boost.org
Subject: Re: [Boost-build] UNC path for library search path
Message-ID: <k1m5nb$1ma$1@ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed

   Hi.

> It appears at first look that builtin_normalize_path() does not expect a
> UNC path (a windows path in the form \\server\share\path).
>
> Does anyone has any thoughts as to whether I'm on the right track?

   Yeah, I think Boost Jam generally does not know how to handle UNC
paths...

   I'm just now in the process of reviewing some of its path
manipulation code to remove some cases where different path strings
refering to the same file are not recognized as such and I've seen some
related code that can use cleaning up. UNC paths will definitely mess up
some of Boost Jam's 'is apsolute path' checks.

   However, I am not adding UNC path support at the moment and am first
concentrating on recognizing all Windows/NTFS relative & absolute path
variants correctly (to remove some recently added quick-fix Boost Build
code). UNC paths will require more thought as with them I really can see
no way to check whether two such paths actually refer to the same file.
This is needed, for example, when loading the same Jam module twice
using two different UNC paths... my guess is that in such cases we'll
simply load the module twice with two separate module names but I have
not gotten to that yet.

   Hope this helps.

   Best regards,
     Jurko Gospodneti?