On 28/11/17 02:12, Chris Johns wrote:
On 27/11/2017 18:07, Sebastian Huber wrote:
On 25/11/17 23:02, Chris Johns wrote:
On 23/11/17 9:33 pm, Sebastian Huber wrote:
bsps/include
bsps/$arch/include
bsps/$arch/$bsp/include
cpukit/include
cpukit/libnetworking/include
cpukit/score/cpu/$arch/include
This generates a lot of header file moves that could be avoided with we use
We are moving a lot of files. This specific change is around 140 moves and so
not a big difference in the scale of things.
These header files contain the implementation details of the CPU ports.
I looked at the history of these files quite regularly.
cpukit/score/cpu/$arch
as an include directory.
We need to handle libdl's headers as well as these arch specific score headers.
I suggest:
cpukit/include
cpukit/@RTEMS_CPU@/include
cpukit/libnetworking/include
bsps/include
bsps/@RTEMS_CPU@/include
bsps/@RTEMS_CPU@/@RTEMS_BSP@/include
I have used the automake defines values in the build system rather than $arch
and $bsp. The `cpukit/@RTEMS_CPU@` may be misleading.
The other solution is to move the libdl headers into the score.
I would move the CPU-specific headers of libdl to cpukit/score/cpu.
Also we cannot use the actual BSP's name we have to use the base name and not an
alias. I am not sure if @RTEMS_BSP@ is the aliased name or not.
With $bsp I mean the @RTEMS_BSP@, the BSP base directory, not the actual
BSP name.
This is looking sensible but I am not sure how to handle the install phase.
Do we have per ARCH and/or BSP makefile .in files that list the headers for that
ARCH or BSP in that part of the tree and we have the Makefile.am subst to
include the specific file, for example `include @RTEMS_CPU@/@RTEMS_BSP@.am? We
cannot use .am files because the subst is during configure and not during
bootstrap. If we did this would we have these file generated by the contents of
the directory, that is all headers are installed?
I just hope we do not fall into an Automake hole here.
I would one bsps/Makefile.am which includes
bsps/$arch/$arch.am
I am not sure what you mean here with `$arch`. Do you mean we have a number of
explicitly named files or some form of macro replacement?
arch is one of { arm, bfin, epiphany, i386, lm32, m32c, m68k, mips,
moxie, nios2, no_cpu, or1k, powerpc, riscv, sh, sparc, sparc64, v850 }.
For example:
bsps/lm32/lm32.am
to keep the file reasonably small. Then I would introduce
AM_CONDITIONAL(BSPS_$arch, ...)
AM_CONDITIONAL(BSPS_$arch_$bspdir)
Where are the BSP headers listed?
In bsps/lm32/lm32.am:
if BSPS_LM32_MILKYMIST
include_HEADERS += bsps/lm32/milkymist/include/bsp.h
include_HEADERS += bsps/lm32/milkymist/include/tm27.h
...
endif
In Makefile.am or bsps/Makefile.am:
include $(srcdir)/lm32/lm32.am
I don't know if this AM_CONDITIONAL() stuff works well, but can we make
it worse than it is?
A general question, why do we need more than one configure.ac to build
RTEMS, the BSPs and the testsuites?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
