Waf's dependency on Python3

[Christian Mauderer]

Am 26.02.19 um 16:57 schrieb Jonathan Brandmeyer:
> https://devel.rtems.org/ticket/3709
> 
> On Mon, Feb 25, 2019 at 5:32 PM Chris Johns <chrisj at rtems.org> wrote:
>>
>> On 26/2/19 10:18 am, Jonathan Brandmeyer wrote:
>>> I attempted to follow the directions in rtems-libbsd's README.md and
>>> run into the following error: "Could not create the directory ///h",
>>> right after configuring the build.  On a wild guess I tried again
>>> using python3 as the interpreter explicitly and that succeeded.
>>>
>>> My host is Debian Stretch, AMD64.
>>> /usr/bin/python is 2.7.13
>>> /usr/bin/python3 is 3.5.3
>>> Tested on rtems-libbsd current master
>>> (5432c6bed37fa26a27c2730e34343d4c507902a9 as of this writing).
>>>
>>> Its not entirely clear to me if waf is supposed to be dual-mode
>>> compatible right now or not.  Maybe the waf shebang line should be
>>> updated?
>>
>> Waf _should_ be fine, well that is the latest releases should be.
>>
>> We have our own support in the rtems_waf directory and that could be a source of
>> what you are seeing so we cannot just assume waf.
>>
>> The weird thing is the path you posted '///h' looks like a Windows path but I
>> cannot be sure.
>>
>> I suggest you raise a bug with as much detail as you think we need, eg commands
>> lines and outputs.
>>
>> Thanks
>> Chris
> 
> 
> 

Hello,

also I don't know a solution, the problem sounds quite similar to the
(unsolved) one here:

https://lists.rtems.org/pipermail/users/2019-January/032920.html

Differences: In your case it has been an "h" instead of a "o" and you
use Debian instead of Mac.

Again it sounds like some path hasn't been generated correctly. Most
likely some header should be generated but the path and name is missing.

Kind regards

Christian