parallel make failure?

[Sebastian Huber]

On 20/11/17 02:18, Chris Johns wrote:
> 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.

At least for the cpukit header files I think it will be rewarding if we 
do the header file move before the release.

>
> 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.

Yes, I guess the BSP area will be a nightmare to clean up.

>
>> 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

You need a separate area for the cpukit/score/cpu/$arch/include headers. 
I am not sure if this should be

$arch/include

I would keep the existing location.

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

You need a place for the BSP and arch dependent header files, e.g. with 
your bsps directory

bsps/$arch/include

>
> Should cpukit/libnetworking become network/legacy ?

I would keep the sources where they are unless there are huge benefits 
to move them.

>
> 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.

More visibility of header files should be all right.

>
> 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.

We probably need one -Bbsps/$arch/$bsp switch and move the linkcmds to 
bsps/$arch/$bsp/lib. There is an issue with the generated linkcmds that 
reside in the build tree.

>
>> 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.

Hm, looks like a major amount of work.

>
> 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?

I am not sure, with a common install to $prefix you save some disk 
space, but a new BSP installation may break another already installed BSP.

-- 
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.