On Mon, Apr 20, 2020 at 12:20 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 20/04/2020 19:04, Vijay Kumar Banerjee wrote: > > > On Sun, Apr 19, 2020 at 8:16 PM Sebastian Huber > > <sebastian.hu...@embedded-brains.de > > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > > > On 19/04/2020 15:38, Gedare Bloom wrote: > > > >> On Sun, Apr 19, 2020 at 3:52 AM Vijay Kumar Banerjee< > vi...@rtems.org> <mailto:vi...@rtems.org> wrote: > >>> Hi, > >>> > >>> While trying to build the examples with a fresh pull from upstream, > >>> I got the following build error from gccdeps: > >>> > >>> ``` > >>> Build failed > >>> Traceback (most recent call last): > >>> File > "//home/lunatic/development/rtems-examples//.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Task.py", > line 190, in process > >>> self.post_run() > >>> File > "/home/lunatic/development/rtems-examples/rtems_waf/gccdeps.py", line 144, > in post_run > >>> raise ValueError('could not find %r for %r' % (x, self)) > >>> ValueError: could not find ['filesystem', 'fat_ramdisk', > 'fs-root-tar.h'] for > >> It's doing an error check to find the build dependency > fs-root-tar.h, > >> which gets generated in the build directory by bin2c. This has > always > >> been tricky to handle in waf. I don't grok the way Chris reworked > the > >> rootfs support in the example so I don't immediately see the root > >> (hah) problem or how to try to fix it. > > > > > > Hi, > > > > I figured out that the tar is generating properly but the error check > > is failing > > because it's looking for the fs-root-tar.h file in the source file > > directory but the > > header file is being generated in the build directory. > > > > Just manually copying the header file to the source directory makes it > > happy > > and the build works fine. Do we want to generate the header file in > > the source > > directory as well and maybe add it in gitignore? > > > > The other approach can be to tell gccdeps to check for the files in > > the build > > directory instead. I did it with a workaround like the following, and > > it works fine: > > ``` > > diff --git a/gccdeps.py b/gccdeps.py > > index bfabe72..61d9bfd 100644 > > --- a/gccdeps.py > > +++ b/gccdeps.py > > @@ -141,7 +141,10 @@ def post_run(self): > > node = path_to_node(path, x, cached_nodes) > > > > if not node: > > - raise ValueError('could not find %r for %r' % > > (x, self)) > > + x = > > os.path.relpath(str(bld.bldnode)).split('/') + x > > + node = path_to_node(path, x, cached_nodes) > > + if not node: > > + raise ValueError('could not find %r for > > %r' % (x, self)) > > if id(node) == id(self.inputs[0]): > > # ignore the source file, it is already in the > > dependencies > > # this way, successful config tests may be > > retrieved from the cache > > ``` > > > > If it doesn't look too hackish, then I'll post a patch. This shouldn't > > break anything else > > and I'll surely add comments there about the use case of taking this > > approach. > > > > Does it look right? > I encountered the same error while writing the new build system. I think > this issue can be fixed with a proper dependency chain in waf. Patching > the generic gccdeps.py is not the way to go if you ask me. > You could alternatively copy the rootfs base files to the build directory and do the tar from there. Source directory stays clean. --joel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
