On Wed, Jan 31, 2018 at 6:57 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > > On 31/01/18 00:12, Chris Johns wrote: >> >> On 31/01/2018 01:16, Gedare Bloom wrote: >>> >>> On Tue, Jan 30, 2018 at 1:44 AM, Sebastian Huber >>> <sebastian.hu...@embedded-brains.de> wrote: >>>> >>>> On 29/01/18 21:45, Chris Johns wrote: >>>>> >>>>> On 29/1/18 6:32 pm, Sebastian Huber wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> now that all BSP header files are in >>>>>> >>>>>> * bsps/include >>>>>> >>>>>> * bsps/@RTEMS_CPU@/include >>>>>> >>>>>> * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/include >>>>>> >>>>>> we should also move the BSP sources to this new directory tree. How do >>>>>> we >>>>>> want >>>>>> to organize the BSP sources in bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@? >>>>>> >>>>> Yes this is a good thing to do. >>>> >>>> >>>> The question is this: should it go into the 5.1 release? I guess it >>>> needs >>>> three to six months to get this done. >>>> >>> I think our guiding philosophy moving forward is to cut a release with >>> any major change? We should not hold up a release for a second major >>> change like this, even if it is related. >>> >> Backporting fixes going to be OK? > > > I had a brief look into the build system stuff under c. It seems > c/src/configure is the main target code build driver. Looks like a > considerable amount (more that two person weeks) of work to move the stuff. > In terms of back-porting, it may be best to refactor the existing BSP structure into the common way described below for this release, at least for the "major" BSPs, but keeping them under c/src/libbsp. This way, back-port fixes should be a matter of mapping the relocated files, but the directory structures they were relocated to should not be too different.
-Gedare _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
