[Boost-build] Builtin GLOB is broken in Boost Engine (BJAM)

Subject: [Boost-build] Builtin GLOB is broken in Boost Engine (BJAM)
From: Jose . (kasty.jose_at_[hidden])
Date: 2014-03-23 21:02:44

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>