parallel make failure?

[Chris Johns]

On 18/11/2017 19:15, Sebastian Huber wrote:
> It would be nice if we are able to back port fixes from the next master (6.0.0) to RTEMS 5.1 easily. I guess RTEMS 5.1 could be a long term release since all the work for SMP which resulted in a massive re-write of the operating system internals stabilizes now.

This is a good idea but is it possible at this point in time? It will happen at
some point and it will be a change that will have this issue.

My current guess doing this change would require a sequence of patches to fix
headers that cause problems in some BSPs (see VME.h below as an example) and
then generation of a script to do a `git mv`. We can chat off-list about the
headers that have an issue.

> For the new build system we have to get rid of the preinstall anyway, so we maybe we should move the header files now and already remove the preinstall step in the current build system. File moves make back ports difficult. I think we only need six header include directories:
> 
> cpukit/include
> cpukit/libnetworking/include
> cpukit/score/cpu/$arch/include
> c/src/include
> c/src/lib/libbsp/$arch/include
> c/src/lib/libbsp/$arch/$bsp/include

I thought the approach was a single top level include tree. I think it would be
better to move the headers only once. What about:

include
cpukit/libnetworking/include
bsps/$arch/$bsp/include

Should cpukit/libnetworking become network/legacy ?

The only downside for this layout is a BSP would get a copy of arch, libcpu etc
header files they are not using. I do not mind this because the code should not
be using -I compiler tricks, we should have the source and header paths cleanly
mapped.

We would also need to consider the various $(PROJECT_LIB) files that are
installed. These are things like bsp_specs and linker command files. Do these
move? I think they should.

> The header file move in the BSP area is a bit of work.

There are 3 basic types of files being managed via the preinstall.am files. They
are directories, pre-install files and temporary install files (internal
libraries). All these would need to be resolved to fix this bug.

The generated preinstalls has 90 instances of the `$(PROJECT_INCLUDE)/bsp`
directory create, 83 instances of installing `$(PROJECT_INCLUDE)/bsp.h` and 174
instances of the word `linkcmds` in an installed file name. There are 2650
preinstall instances in the preinstall.am files and then you have the complexity
of 3 separate VME.h files in BSPs, 2 each of vmeTsi148.h and vmeTsi148DMA.h. I
have no idea if these files are the same or different. These would need to be
audited and changed with the corresponding changes to the source.

I suspect the current install model, ie make install, for the final resting
place for headers would need to be reviewed and considered. Would these be a
single tree for common headers per $PREFIX or per BSP copy?

Chris