Issues with rtems_waf on Windows 10 with gccdeps module

[Vijay Kumar Banerjee]

Hi Robin,

On Fri, Apr 30, 2021 at 2:36 AM Robin Müller <robin.mueller.m at gmail.com> wrote:
>
> Issue can be reproduced by doing the quickstart application build on Windows 10. The issue are backslashes in the absolute paths of the dependency paths
> which were not stripped from dependency paths on Windows,
> causing waf to not recognize them as valid absolute paths. More specifically, I printed the resulting dependency paths after stripping
>
> C\:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include/rtems/userenv.h
>
> The backslash at the start causes the issue.
> I was able to fix this with the following adaptations (gccdeps.py starting line 108)
>
As I mentioned earlier, this patch will probably not be accepted in
upstream waf and it might not be a great idea to change it in the
RTEMS version of waf, since it'll cause issues in the future when we
try to sync up with the waf updates from upstream.

Please try bld.find_or_declare from your wscript and see if that fixes
the header file not found issue. That is probably a cleaner solution
for now.

> # Now join all the lines together
> txt = txt.replace('\\\n', '')
>
> val = txt.strip()
> val = [x.replace('\\ ', ' ') for x in re_splitter.split(val) if x]
> # This was added to replace backslashes which can cause issues on Windows
> if os.name == 'nt':
>      val = [x.replace('C:\\', 'C:') for x in re_splitter.split(val) if x]
> print(val)
> nodes = []
> bld = self.generator.bld
>
> I don't know whether this can have other evil side effects, but the waf build works after that..
The possible evil side effects could be the issue with "\", as you
mentioned here. So better to avoid hacking it. :)


Best regards,
Vijay
>
> Kind Regards
> Robin
>
> On Fri, 30 Apr 2021 at 00:30, Vijay Kumar Banerjee <vijay at rtems.org> wrote:
>>
>> Hi all,
>>
>>
>> On Thu, Apr 29, 2021 at 3:01 PM Chris Johns <chrisj at rtems.org> wrote:
>> >
>> > On 30/4/21 5:01 am, Robin Müller wrote:
>> > > Yes that is the prefix. The rtems.h file is definitely located at the location
>> > > in the warning and it works on older commit of rtems_waf (where gccdeps.py is
>> > > not used).
>> > > I briefly looked through the gccdeps.py file and it is doing some string
>> > > stripping operations.
>> > > Maybe that is the issue but I am not sure.
>> >
>> > Thank you for debugging this and I agree it look like something is a little off
>> > in gccdeps.
>> >
>> Yes, I had a patch for that but I think there was a discussion
>> upstream between ita1024 and Chris and the conclusion was that the
>> patch won't be accepted. I can't find it right now but I could fix
>> this problem by using find_or_declare.
>>
>> @Robin: Please try to use the find function and see if it fixes.
>> Here's an example that worked quite nicely in rtems-examples:
>> https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34
>>
>>
>> Best regards,
>> Vijay
>>
>> > I will need to try and reproduce this to have a chance of finding it. What
>> > happens if you remove gccdeps.py? Will that you get past this point?
>> >
>> > Chris
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel