Hi Robin,
On Mon, May 3, 2021 at 6:37 AM Robin Müller
wrote:
>
> I also tried bld.path.find_or_declare('rtems.h') like in the supplied
example, but that did not work for me either.
>
That worked for me in multiple places before. not sure what's happening
there.
> Kind Regards
> Robin
>
> On Mo
I also tried bld.path.find_or_declare('rtems.h') like in the supplied
example, but that did not work for me either.
Kind Regards
Robin
On Mon, 3 May 2021 at 14:31, Robin Müller wrote:
> Hello Vijay,
>
> I tried bld.find_or_declare('rtems.h') but that did not work for me.
>
> Just out of curiosi
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 wrote:
> Hi Robin,
>
> On Fri, Apr 30, 2021
Hi Robin,
On Fri, Apr 30, 2021 at 2:36 AM Robin Müller 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 t
The "dirty solution" actually only works if the drive is named C, and maybe
the backslashes should not be there in the first place.
Maybe you already have dealt with this issue?
Kind Regards
Robin
On Fri, 30 Apr 2021 at 10:36, Robin Müller
wrote:
> Issue can be reproduced by doing the quickstar
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
Hi all,
On Thu, Apr 29, 2021 at 3:01 PM Chris Johns 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).
> >
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
> strippin
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
On Thu, Apr 29, 2021 at 9:59 AM Gedare Bloom wrote:
>
> On Thu, Apr 29, 2021 at 3:14 AM Robin Müller
> wrote:
> >
> > I replaced the file in rtems_waf manually but it still throws the same
> > error:
> >
> > [1/2] Compiling build/conf_check_995d7bdd1834199278843e9a51c37759/test.c
> >
> > ['C:/U
On Thu, Apr 29, 2021 at 3:14 AM Robin Müller wrote:
>
> I replaced the file in rtems_waf manually but it still throws the same error:
>
> [1/2] Compiling build/conf_check_995d7bdd1834199278843e9a51c37759/test.c
>
> ['C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe',
>
I replaced the file in rtems_waf manually but it still throws the same
error:
[1/2] Compiling build/conf_check_995d7bdd1834199278843e9a51c37759/test.c
['C:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/bin/sparc-rtems6-gcc.exe',
'-mcpu=cypress',
'-IC:/Users/Robin/Documents/RTEMS/rtems-tools/rte
On 28/4/21 7:59 pm, Robin Müller wrote:
> I think the following commit in rtems_waf breaks the waf build on Windows 10:
>
> commit 096372fc4504730e50b51b952ce47ca603b35f01
> Author: Chris Johns mailto:chr...@rtems.org>>
> Date: Thu Oct 10 17:43:11 2019 +1100
>
> Use gccdeps for dependency s
13 matches
Mail list logo
