I'll rewrite in this thread my findings about the builtin GLOB in bjam. Everything started in the thread titled "<install-source-root> in Windows doesn't work with case-insensitive matching". All tests are made in Windows, with the Boost Build package bundled with the final release of Boost 1.55.

Please consider the following code example:

# Jamroot file at C:\Jam.
# A dummy text file at C:\AaA\BbB\File.txt

using msvc ;
import path ;

path-constant TOP : . ;
ECHO [ GLOB $(TOP)/../AaA/BbB : * ] ;

actions pause
{
pause
}
make pause : : @pause ;
always pause ;

In a perfect world the output would be:

C:\Jam\..\AaA\BbB\File.txt

[ Now make sure BOOST_BUILD_PATH is properly set in Control Panel->System->Advanced Settings->Environment Variables and it points to Boost Build 1.55 ]

We create a shortcut for bjam.exe and place it in the Desktop (right click bjam.exe -> Send To -> Desktop), setting the working directory to C:\Jam (right click the shortcut->Properties->Working Directory). Double click the shortcut and the output is OK:

C:\Jam\..\AaA\BbB\File.txt

Now we open a CMD terminal, CD c:\Jam, and execute BJAM:

C:\Jam> bjam

The output is:

C:\Jam\..\aaa\bbb\File.txt

The problems resides somewhere in the canonicWindowsPath() function (pathnt.c), and is related to the way the cache is implemented. Question for the developers: why does it use sometimes the original path for the hash key, other times the normalized path, and others an ugly mix of them?

A quick and dirty fix, that works for me, is this:

static int canonicWindowsPath( char const * const path, int const path_length,
    string * const out )
{
....

    saved_size = out->size;
    string_append_range( out, last_element, path + path_length );

//    if ( !missing_parent )    // COMMENT THIS LINE
    {
        char const * const n = last_element;
....
}

Regards.

<ranting>

Honestly, I am very grateful to all Boost volunteers, but this boost engine (bjam) release should have never made it into boost 1.55. Because it breaks working projects. The optimizations related to file path caching are bogus, at least on Windows, which means nobody really tried them in big projects (appart from compiling Boost libraries, which obviously is not enough).

I tried to fix it and provide a patch to the community, but I was not able because I never really understood the code (not many comments around, hard to devise developer's intentions regarding bogus logic), and it takes too long because it's not debugger-friendly (i.e. data types cannot be easily inspected, I really miss C++ and STL).
</ranting>