Re: [Boost-build] Windows Develop Tests Failing

Subject: Re: [Boost-build] Windows Develop Tests Failing
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2015-03-21 12:08:33

AMDG

Resending.

On 03/20/2015 09:49 AM, Raffi Enficiaud wrote:
> Le 19/03/15 19:24, Steven Watanabe a ecrit :
>> On 03/19/2015 11:03 AM, Raffi Enficiaud wrote:
>>> Le 19/03/15 16:22, Steven Watanabe a ecrit :
>
> Thread from boost.devel list, sorry for cross posting.
>

No problem.  You're correct that this
discussion belongs here.

>>>>
>>>> It's a bit more complicated then that, since
>>>> \\?\ requires an absolute path.  Also, I
>>>> thought that you need to use wchar_t as well.
>>>
>>> Right, I made an attempt and most of the files are in
>>> relative path. Is
>>> there any function in C retrieving  the full path?
>>
>> No there isn't.  You can get the cwd and
>> you can join and normalize paths, though,
>> so it wouldn't be very hard to add.
>
> Right. Do you think it is better to put that in the
> .jam files instead?

We have two options for fixing this:
a) We can just change b2 so that it translates paths
   to UNC whenever it needs to interact with the filesystem.
   This is the least intrusive method, as the only
   user visible effect will be to make some things
   work that would have failed before.  However, this
   won't help external programs that don't do such
   translation.  The basic way to handle this would
   be to write a function like:
   wchar_t * make_system_path( const char * );
b) We can instead change the Jam code to use UNC paths.
   This is likely to be considerably more work as we
   would need to work out which paths need to be relative
   and which ones should be absolute.  However, it has
   a better chance of allowing the updating actions
   to function correctly.

Actually, we have a third option:
c) instead of a hard error when failing to write the
   .rsp file, just fail the target that needs it.
   This would at least allow some tests to pass if
   only a few overflow MAX_PATH.

> I do not know exactly what is computed when we arrive at
> this point: are
> those expanded commands from the rules?

I'm not sure exactly what you're asking, but
I'll give it my best shot.

The action block for msvc.compile-c-c++ contains
an expression of the form: @(file.rsp:file contents)

This expands to "file.rsp" and writes "file contents"
to file.rsp.  The file name and contents are completely
determined by msvc.jam.  The file name, I believe, is
formed by replacing the extension of the .obj file
with .rsp.

> BTW, is it possible in the .c code to call commands
> from the .jam files?
>

It is possible, but anything that's needed by the
core Jam interpreter should not be implemented in Jam.

in compile.h:
LIST * evaluate_rule( RULE * rule, OBJECT * rulename, FRAME * );
LIST * call_rule( OBJECT * rulename, FRAME * caller_frame, ... );

>>
>>> Also, I think that
>>> the full chain should be in full path as well (eg
>>> mkdir in common.jam
>>> should prefix the absolute path with \\?\ to work).
>>>
>>
>>    I think the first step to handling this would
>> be to make sure that Boost.Build handles UNC
>> paths correctly.  Once we can pass these paths
>> through correctly, we can worry about converting
>> paths to UNC.
>>
>> Right now, I would be somewhat surprised if
>> this worked:
>>
>> exe test : "\\\\?\\C:\\boost\\source.cpp" ;
>>
>
> This is not clear to me what happens between this declaration and the
> failing "fopen" we are referring to. If at some point relative
> paths are
> used, the test you are proposing would not tell us anything.
>

If we're going to be changing the Jam code to
use UNC paths automatically, then we need to
make sure that path.jam doesn't mangle UNC paths.
If we're just going to fix the "fopen" in isolation,
this test isn't relevant.

In Christ,
Steven Watanabe