#4548 closed enhancement (fixed)
Add RTEMS version option to waf configure
Reported by: | Chris Johns | Owned by: | Sebastian Huber <sebastian.huber@…> |
---|---|---|---|
Priority: | normal | Milestone: | 6.1 |
Component: | build | Version: | 6 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description
We need a way to override the default release for testing. This is a developer option and is not for production. A waf
option is considered the best way to manage this.
Change History (9)
comment:1 Changed on 11/13/21 at 13:53:19 by Sebastian Huber
comment:2 Changed on 11/14/21 at 02:56:59 by Chris Johns
I think maintainer experiments should be done with spec
file changes on feature branches. My concern about a generic method from the command line, INI file or any other method is the testable dependencies it exposes. I feel what we have and where we are at is a good compromise between the web of options we had with autoconf's configure
and the ever present complexity of build and BSP options we have to have.
I agree the implementation of how to manage this should follow reasonable design paths but I think the type of action needed has to be explicit with wscript
or spec
file changes.
I have added a call named item_set_action_value()
that takes a path
and value
. The value
needs to be of a type and nature that matches the action
. The code to set the major version from the command line is:
if conf.options.rtems_version is not None: item_set_action_value(conf, '/cpukit/optvermaj/set-value', conf.options.rtems_version)
I think a path to address an item is a suitable abstraction. This version value update happens before the items are processed by configure
which is important.
comment:6 Changed on 12/17/21 at 17:22:19 by Joel Sherrill
Resolution: | → fixed |
---|---|
Status: | new → closed |
Closing. This is in the tree now.
comment:7 Changed on 01/11/22 at 15:47:42 by Sebastian Huber <sebastian.huber@…>
Owner: | set to Sebastian Huber <sebastian.huber@…> |
---|
This enhancement should be solved in a more general setting. What we need is the ability for maintainers to alter build system variables which a user should not be able to change.
What we could do is using an
_
prefix for internal build system variables which may be changed by theconfig.ini
file if an--rtems-maintainer-mode
option is given at the configure command line.An alternative would be a
get-option
option action (similar toget-value
) which uses a command line specified value if it is available. We could also add this feature toset-value
.