On 22/10/21 1:21 am, Sebastian Huber wrote: > On 21/10/2021 10:36, Chris Johns wrote: >> Could you please answer the other parts of the email you cut because it would >> help understand this stuff? >> >> Specifically the opt* and user options. When is an option optional and when >> is >> an option an option but not optional? > > The option item files are used for both user options and internal options. >
OK I think this now makes sense. An option can be a user controlled with a default or a variant dependent on the build characteristics, for example architecture? >> On 21/10/21 7:09 pm, Sebastian Huber wrote: >>> On 21/10/2021 10:06, Chris Johns wrote: >>>> KeyError: '/cpukit/optlibddebugger' >>>> >>>> You have to admit this is a horrible error message. It provides no insight >>>> into >>>> problem or the solution. >>> >>> Looks like a typo. Maybe use optlibdebugger? >> >> Yes it was. Thanks. However I am still confused. >> >> If I add optlibdebugger to cpuopts.yml which is: >> >> build-type: config-header >> >> I would expect libdl and libdebugger to appear in cpuopts.h as enable >> variables >> but they do not? > > What the option items to is defined by the actions attribute, for example > (spec/build/cpukit/optlibdl.yml): > > actions: > - set-value: true > - env-enable: null > > This adds the option name to the enabled set. Thanks. And `name` is the name field? >> Why are they in this YAML file? > > This is to order the build properly. OK. Is it fair to say cpuopts is a convenient way to centralise this? >> >> The the libdebugger YAML file I need: >> >> enabled-by: BUILD_LIBDEBUGGER >> >> or: >> >> enabled-by: >> - arm >> - i386 > > If the option file adding BUILD_LIBDEBUGGER to the enabled set is processed > before the libdebugger.yml and it uses the same enabled-by expression, then > you > can use both. Both of what? How would I add a define to the actual cpuopts.h file? I wonder if adding libdl and libdebugger would be useful given they are not universally supported? >> however `enabled-by` is not in: >> >> https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuildlibraryitemtype >> >> >> Is it OK to do this? > > Yes, just follow the "refines" link to the root type. > >> >> It is great this is working but it is confusing understanding why and that >> means >> it is hard to know what you can do and not do? > > The items have a fixed set of top-level attributes which are all documented. > What you should definitely not do is adding new attributes to existing files. > This is an absolute no go. Would it make sense to capture the constraints of each `build-type`? It would have helped me here if an error was generated when I added `name` to the `build-type` library. I can see `constraints.yml` as a top level file that is read in and to used to monitor what is present in each built-type. > We should gradually improve the documentation. Maybe the enabled-by attribute > needs more explanations. Agreed. And the options and what they are used for? I considered their use was literal and user facing. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
