Issues with rtems_waf on Windows 10 with gccdeps module
Robin Müller
robin.mueller.m at gmail.com
Mon May 3 12:31:55 UTC 2021
Hello Vijay,
I tried bld.find_or_declare('rtems.h') but that did not work for me.
Just out of curiosity, why was the patch not accepted? I did not find
anything in the waf gitlab.
Kind Regards
Robin
On Sat, 1 May 2021 at 20:29, Vijay Kumar Banerjee <vijay at rtems.org> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210503/c8626162/attachment.html>
More information about the devel
mailing list