Compressed patch to move make/custom/* to make/*
Chris Johns
chrisj at rtems.org
Thu Feb 8 23:47:57 UTC 2018
On 09/02/2018 02:22, Joel Sherrill wrote:
> On Thu, Feb 8, 2018 at 9:10 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> wrote:
> On 08/02/18 16:08, Joel Sherrill wrote:
> On Thu, Feb 8, 2018 at 3:05 AM, 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 08/02/18 09:11, Sebastian Huber wrote:
>
> On 08/02/18 01:00, Joel Sherrill wrote:
>
> Hi
>
> The patch was quite large and rightly blocked from being
> sent to
> everyone (~900k). Compressed, it is only 63K
>
> This eliminates the custom directory and moves everything up
> one level. No failures in the build as shown here.
>
>
> https://lists.rtems.org/pipermail/build/2018-February/000398.html
> <https://lists.rtems.org/pipermail/build/2018-February/000398.html>
>
> <https://lists.rtems.org/pipermail/build/2018-February/000398.html
> <https://lists.rtems.org/pipermail/build/2018-February/000398.html>>
>
>
> If we move this stuff, then why not to
>
> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
>
>
> OK. I can pick at that but what does from testsuites this change to?
>
> include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP at .cfg
>
> Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?
>
> Is there a Makefile.am variable that really points to the top of the
> source tree?
>
> The other common pattern is
>
> include $(RTEMS_ROOT)/make/custom/default.cfg
>
> in all the BSP .cfg files? What will that need to be to work before and
> after install?
>
> RTEMS_ROOT is the build tree and later the install point. I don't
> know how to make that one work.
>
> Any thoughts?
>
>
> No user should be forced to touch its Makefiles only because we move some
> files in the RTEMS source tree from A to B. So, I think the install location
> should remain as is.
>
>
> I agree but I think you missed my point. The use in testsuites can be fixed to point
> to the source tree. But if I change the includes in the "custom" files, I have
> concerns
> that it may not be possible to make it work in both when building and installed.
>
Exporting anything internal to users is always going to present a risk, we have
known and acknowledged this for years. It has been part of the reason we have
avoided making changes in the build system however my attitude is changing or
has changed, ie removing preinstall.
Long term I cannot see how we can sustain this interface and that means we need
to determine when it goes? I am more than happy to be proved wrong. It is only
fair to those who use these installed files they get suitable warning and we
need to figure out what we provide to replace it.
Building new applications and products based on this type of application build
framework with RTEMS 5 should be discouraged. We are looking to increase the
release frequency and this will only shorten the life span for these files.
> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit.cfg:include
> $(RTEMS_ROOT)/make/custom/altcycv.inc
> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit_smp.cfg:include
> $(RTEMS_ROOT)/make/custom/altcycv.inc
> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv.inc:include
> $(RTEMS_ROOT)/make/custom/default.cfg
>
> I just grep'ed for RTEMS_ROOT and it appears that I need to change the definition
> of where it points. It is mostly used to point to the custom files but this looks
> problematic:
>
> /c/src/Makefile.am: 'RTEMS_BSP=@RTEMS_BSP@' 'RTEMS_ROOT=.' \
> ./c/src/configure.ac:RTEMS_ROOT=. make/${RTEMS_BSP}.cache
>
> All the references in testsuites can be to top_srcdir. Easy to eliminate RTEMS_ROOT
> completely I think in there. But what should RTEMS_ROOT be set to in
> c/src/configure.ac <http://configure.ac> to make it work? What variable has the
> top of the source tree?
>
> I guess $(top_srcdir)/../..?
> > Thoughts?
>
You are entering a swamp made of "top.*" labelled quick sand as I found out in
the preinstall removal. Top is relative and is implemented as a hack I refrain
from fully explaining so I do not offend. There are a number of "tops" in the
tree and then there are lists of ".."s to go up and down and that number depends
on the relative point to the "top" you are under. There are no consistent rules
across the source and it depends on a mix of different .m4 pieces with the same
macro and files names in different aclocal directories that are effected by the
command line options to the nested configure calls that is controlled in a
completely unrelated place in the tree. It is close to impossible to get a clear
metal image of what actually happens. Once you get close to understanding this
the build tree is a completely unrelated tree that has to support building more
than one BSP in a single make run and that has a different set of rules. I
suggest you keep away from top_* etc if you want to remain sane.
In no-preinstall I gave up attempting to sort this swamp out and implemented a
parallel and simpler system. In aclocals I added rtems-source-top.m4 and
RTEMS_SOURCE_ROOT that is the top of the source tree and rtems-build-top.m4 and
RTEMS_BUILD_ROOT that is the top of the BSP's build tree (I think). I needed
this to know where the header files are as they are not copied into the build
tree. As a result the RTEMS_BSP_INCLUDES macro contains this fragment:
RTEMS_BSP_CPPFLAGS="-I${RTEMS_BUILD_ROOT}/lib/libbsp/\$(RTEMS_CPU)/\$(RTEMS_BSP_FAMILY)/include
\
-I${RTEMS_SOURCE_ROOT}/bsps/include \
-I${RTEMS_SOURCE_ROOT}/bsps/\$(RTEMS_CPU)/include \
-I${RTEMS_SOURCE_ROOT}/bsps/\$(RTEMS_CPU)/\$(RTEMS_BSP_FAMILY)/include"
Have a look at these to see if they help.
Chris
More information about the devel
mailing list