On Thu, 28 Feb 2019 at 03:37, Chris Johns <chr...@rtems.org> wrote:
> On 25/2/19 6:57 am, Vijay Kumar Banerjee wrote:
> > In an attempt to read all the files, I wrote a parser to try to put them
> > all in one place.
>
> Great.
>
> > I'm attaching the parser, the generated data and the list of files that
> > could not be parsed because they use `defines`.
>
> Yes this is where things get difficult.
>
> > Is this data any helpful?
>
> It is interesting. If a complete set can be captured we can move all the
> common
> options into a single place.
>
> > Is this the right way forward?
>
> I suspect it is or we run the risk of not seeing something if this is done
> by
> manually.
>
> On the issue of the defines:
>
> 1. Are the defines needed or could be these changed into something else and
> removed? I think this requires inspecting each one and deciding.
>
> it's defining bsp-post-link something like this ...
define bsp-post-link
$(default-bsp-post-link)
$(OBJCOPY) -O binary $@ $(basename $@)$(DOWNEXT)
endef
can this be moved to some common cfg file somehow?
I have observed that the arm bsps are using .inc files and importing them
from the .cfg files. Is there any reason that they're organized like that,
instead
of directly writing it in the .cfg files ?
2 Does running `gmake -p` after a successful build of the BSP provide you
> with
> the missing details?
>
> Chris
>
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
