On 28/11/2017 17:27, Sebastian Huber wrote:
> 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.
This is something that effects all the files we move so I am not sure this is a
good reason to leave some files in place. Git log has --follow option so you can
walk the files history backwards.
We should be looking to get the files into places we want and I like the
'include' being last on all paths.
>
>>
>>> 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.
>
I am ok with this happening, they can be placed where ever the other CPU headers
end up.
>>
>> 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.
>
Great. This makes sense.
>>
>>>> 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
>
OK.
>>
>>> 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
>
OK.
> I don't know if this AM_CONDITIONAL() stuff works well, but can we make it
> worse
> than it is?
This will work.
>
> A general question, why do we need more than one configure.ac to build RTEMS,
> the BSPs and the testsuites?
>
It was split to support a separate CpuKit and multilibs. A change would be hard
given it is far to fragile to change.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
