parallel make failure?

[Sebastian Huber]

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 at .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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.