RTEMS examples build failed

[Vijay Kumar Banerjee]

On Mon, Apr 20, 2020 at 11:33 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 20/04/2020 19:58, Joel Sherrill wrote:
>
> >
> >
> > On Mon, Apr 20, 2020 at 12:20 PM Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at 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.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>
> >     > <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at 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<vijay at rtems.org <mailto:vijay at rtems.org>>
> >     <mailto:vijay at rtems.org <mailto:vijay at 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.
> We don't have to reinvent the wheel. We could copy the wscript of the
> new build system to the examples and add a couple of specification
> items. Building test programs is really not that much different to
> building applications.
>
Just to make sure I understood correctly: Do you suggest that we replace
the rtems_waf in examples with the wscript similar to the new build system?
The tar and the *-tar.c file is generating properly using the
rtems_waf.rootfs
the issue here is that the gccdeps isn't searching for the *-tar.h file in
the build
build directory where it's being created, instead it's looking for it in
the source
directory. Since the *-tar.c file is also being built from the build/
directory, will
it not be possible to build the init.c from the build directory as well?
This won't
require any modification to the gccdeps and probably just some tweaking in
the
wsript of the filesystems examples.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200421/6fda58fd/attachment.html>