[RTEMS Project] #3351: libbsd: Add support for conditional compilation of modules and compiler flags

[RTEMS trac]

#3351: libbsd: Add support for conditional compilation of modules and compiler
flags
--------------------------------+---------------------------------
 Reporter:  Christian Mauderer  |       Owner:  Christian Mauderer
     Type:  enhancement         |      Status:  assigned
 Priority:  normal              |   Milestone:  Indefinite
Component:  network/libbsd      |     Version:  5
 Severity:  normal              |  Resolution:
 Keywords:  libbsd waf IPSec    |  Blocked By:
 Blocking:                      |
--------------------------------+---------------------------------

Comment (by Chris Johns):

 Replying to [comment:2 Christian Mauderer]:
 > If we build multiple variants in one go we might have a lot of different
 variants soon because every option would double the variants.

 Yes. A way to configure and build does not diminish the obligation on all
 developers making changes to build all possible variants or at least an
 agreed number. Over the years we have added options to RTEMS's `configure`
 and has become a problem. If you add on to the possible configure options
 the possible `BSP_OPTS` we have something we can never ever test build not
 even once. I am attempting to control the issue with the `rtems-bsp-
 builder` and it's 1600+ lines of Python. If you review a recent build from
 Joel (1) you will see the minimal set of 13 build variants I could come up
 with generates over 1500 build jobs or separate builds of RTEMS. I would
 like to avoid this as much as possible but recognize it is difficult or
 impossible to do without limiting the features we want.

 (1) https://lists.rtems.org/pipermail/build/2018-March/000553.html

 > The IPSec is one option but we already had an application where we
 disabled IPv6 for one specific use case due to size reasons. Another
 option could be WiFi or no WiFi (which adds quite some code which isn't
 used by many applications). So it would be already eight different
 versions.

 Yes, and while we have used options for this I feel that method may not
 scale. It has been useful up to now but I think we need to consider
 something else.

 > My long-time direction would be to provide options via a configuration
 file (for example some ini). With that it would be possible to use
 different default configuration for some BSPs (for example the ones with /
 without WiFi). A user could provide his own config that matches his
 application. I still have to have a more detailed look over the option
 parser used in waf but I would expect that it can be somehow convinced to
 read options via a file too.

 I would prefer this be a near-term direction and we develop Python code
 and support so we can define a set of agreed "variant builds" . I see a
 "variant" consisting of compile options, ie `-Os` etc, specific defines
 and specific sets of files. The base build would be a bare stack, for
 example no IPv6, SSL, etc, and an IPV6 with SSL would be `IPV6-SSL = base
 + IPV6 + SSL`.

 I am OK with INI files because it is built into Python. YAML would be nice
 but it requires extra host packages and that creates user support issues.
 Please take a look at `tester/rt/check.py` and
 `rtemstoolkit/configuration.py` in the `rtems-tools` repo. It is fine to
 copy down to this project the configuration file support from the
 rtemstoolkit.

 I think it would be best to leave `libbsd.py` as it is for now. I would
 like to move that configuration to an INI format and remove the
 intermediate step of generating `libbsd_waf.py`. There is no real need to
 generate the file other than the former support of `Makefile` builds. This
 means we work on a top level INI design and we can flesh out the migration
 from `libbsd.py` later. The `rtemstoolkit/configuration.py` supports
 includes which allows a tree structure to be formed letting us clip below
 the needed file sets when that change happens.

 The key requirement I would like to have is being able to configuring a
 build for libbsd that builds all variants we agree are important before
 submitting a patch. I do not want to have to write another `rtems-bsp-
 builder`, I would like that functionality built in.

--
Ticket URL: <http://devel.rtems.org/ticket/3351#comment:4>
RTEMS Project <http://www.rtems.org/>
RTEMS Project