On 20/04/2020 19:58, Joel Sherrill wrote:
On Mon, Apr 20, 2020 at 12:20 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto: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>
> <mailto: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>>
<mailto: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.
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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
