RTEMS examples build failed

[Vijay Kumar Banerjee]

On Wed, Apr 22, 2020 at 11:40 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 21/04/2020 19:18, Gedare Bloom wrote:
>
> > On Tue, Apr 21, 2020 at 8:42 AM Vijay Kumar Banerjee <vijay at rtems.org>
> wrote:
> >>
> >>
> >> On Tue, Apr 21, 2020 at 7:10 AM Chris Johns <chrisj at rtems.org> wrote:
> >>> On 21/4/20 7:03 am, Vijay Kumar Banerjee wrote:
> >>>> On Mon, Apr 20, 2020 at 11:33 PM Sebastian Huber
> >>>> <sebastian.huber at embedded-brains.de
> >>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >>>>      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?
> >> Hi,
> >>> Please do not do this. I am reluctant to again head down the path of
> >>> exposing the internals of the rtems.git build system to users via
> >>> examples. It says to our users they need to use this approach to
> >>> building RTEMS applications and that is not the case. It also removes
> >>> the need for us to make sure we correctly handle exporting the needed
> >>> build data for a BSP. I like the current separation.
> >>>
> >> Understood.
> >>> I prefer the examples are just that, an example of code to use and how
> >>> to build an application with different build systems. I welcome support
> >>> for other build systems being added to our examples. It just needs
> >>> someone to maintain whatever is added.
> >>>
> >>> The rtems_waf approach is based on the currently exported data and when
> >>> a new build system is agreed on and merged it will be updated.
> >>>
> >> I tried for some time to figure out some way to fix the dependency
> check errors
> >> but couldn't find any other solution. I also tried building the whole
> source from
> >> the build directory by adding this something like this:
> >> ```
> >>         rule = 'cp ${SRC} ${TGT}'
> >>         bld (rule = rule, source = 'init.c', target = 'fat-root-init.c')
> >> ```
> >> This again works nicely with the build but gets stuck in the post run
> checks by
> >> gccdeps that seems to search for the headers only in the source
> directory.
> >>
> >> Do you have some suggestions to try out? Patching the gccdeps works but
> >> it seems like we don't want to do that (?)
> >>
> > This was quite challenging for me to figure out how to make work the
> > first time. I had to wade through the waf book to figure out how to
> > make the generated header file visible. You might need to do some
> > digging as well to see how it might be possible.
> >
> > I think the next best solution is to have gccdeps search the build
> > tree for the generated header file.
> >
> > The worst solution is to touch an empty header file in the source tree.
>

Hi,

After reading through the Waf book and some different trials, I came up
with a
nice one-line solution that works like a charm:

https://lists.rtems.org/pipermail/devel/2020-April/059556.html

I used the find_or_declare function with it which returns a Node object
under the
source or build folders. If nothing is found, it creates the corresponding
node in
the build directory and the folder structure required for writing the file
during the
build phase. If the path is not under the build directory, then a fake
filesystem
structure is created for the output files. This makes the header
file searchable
after post_run, without the need to change the gccdeps.

I have tested it and it works great. Please review the patch and let me
know if
it's good to go.

Best regards,
Vijay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200426/5dfa13b6/attachment.html>