On 09/04/2018 15:29, Sebastian Huber wrote: > On 09/04/18 07:20, Chris Johns wrote: >> On 09/04/2018 15:05, Sebastian Huber wrote: >>> On 09/04/18 01:06, Chris Johns wrote: >>>> I am testing testsuite Makefile.am changes and the following configure: >>>> >>>> /opt/work/chris/rtems/kernel/rtems.git/configure >>>> --prefix=/opt/work/rtems/bsps/5 >>>> --target=arm-rtems5 --enable-posix --enable-networking --enable-smp >>>> --enable-tests --enable-maintainer-mode >>>> >>>> fails with: >>>> >>>> gmake[5]: Entering directory >>>> '/opt/work/chris/rtems/kernel/bsps/arm/arm-rtems5/c/atsamv/cpukit/score' >>> The --enable-smp doesn't work with this BSP. >>> >> Seems a brutal way to let a user know? >> >> Considering this is a little it means --enable-smp and >> --enable-multiprocessing >> is broken when the BSP wildcard is used. Should we require a BSP or list of >> BSPs >> be provided to configure? It would avoid this issue? > > I think for the --enable-multiprocessing we already have something like this: > > c/src/aclocal/check-multiprocessing.m4 >
Yes. > I am not sure if we should omit BSPs which cannot cope with a --enable-* > option. > If you want to build all BSPs you want to build all BSPs? > I think it would too hard at this point in time to probe and create a list of those BSPs that support the options. I am thinking if you use --enable-smp or --enable-multiprocessing you must provide a list of BSPs so the wildcard or all default cannot be used. If a user supplies a BSP that is not support that is a different issue and the need to handle that better for SMP would be nice. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel