waf: allow any custom build option to be specified in waf configure #28039
Conversation
tridge
force-pushed
the
pr-build-options-configure
branch
4 times, most recently
from
3c35af1 to
e86d205
Compare
Tools/scripts/build_options.py
Outdated
| @@ -413,7 +421,7 @@ def __init__(self, | |||
| Feature('Filesystem', 'FILESYSTEM_SYS', 'AP_FILESYSTEM_SYS_ENABLED', 'Enable @SYS/ filesystem', 0, None), | |||
| Feature('Filesystem', 'APJ_TOOL_PARAMETERS', 'FORCE_APJ_DEFAULT_PARAMETERS', 'Enable apj_tool parameter area', 0, None), | |||
|
|
|||
| Feature('Networking', 'PPP Support', 'AP_NETWORKING_BACKEND_PPP', 'Enable PPP networking', 0, None), | |||
| Feature('Networking', 'PPP Support', 'AP_NETWORKING_BACKEND_PPP', 'Enable PPP networking', 0, None, "enable-ppp"), | |||
There was a problem hiding this comment.
Could we put these hacks back in waf, please?
Should just be a dictionary mapping from A to B?
There was a problem hiding this comment.
it needs to be here to keep backward compatibility with existing documented options like --enable-ppp. We won't need it for new options. It would be an awful lot uglier to have this in wscript
There was a problem hiding this comment.
if we're willing to break existing documented configure options we could remove these
There was a problem hiding this comment.
Or throw a warning in 4.6 that the option is deprecated and remove in 4.7?
There was a problem hiding this comment.
if we're willing to break existing documented configure options we could remove these
I'm thinking that breaking them would be ok, although it will be a small inconvenience initially for a very small minority who can probably deal with it, because in the long term, part of the power of this feature comes from it's consistency - everything will work the same way.
There was a problem hiding this comment.
Surely
Feature('Networking', 'PPP Support', 'AP_NETWORKING_BACKEND_PPP', 'Enable PPP networking', 0, None, "enable-ppp"),
should be "PPP" not "PPP Support" - it seems to be the only one with a space in the label field.
There was a problem hiding this comment.
If we want to support --enable-ppp, could you not also support --enable-PPP, ditto for ekf2/EKF2, ekf3/EKF3.
I'm thinking that someone might want to build a script that would generate a ./waf configure command line. These special cases would make that difficult, but supporting both (deprecating the lowercase option) might be a good interim solution.
|
Just a thought about how the options work, could it be
rather than
Doesn't that make more sense? |
we won't be able to tab complete that, or at least not without a lot of work in the completions logic for each shell. Being able to tab complete options is very nice |
this makes it easy to configure with any option from build_options.py
tridge
force-pushed
the
pr-build-options-configure
branch
from
e86d205 to
2511395
Compare
|
after discussion on the dev call I've removed the backwards compatibility logic |
We had the forethought to create autotests for the options you've removed :-) Still, fixing those means we can't easily break this new functionality |
tridge
dismissed
peterbarker’s stale review
removed backwards compatibility
|
@Hwurzburg for the WikiNeeded, we need to remove reference to the removed options --enable-ekf3 and friends (or make it clear they're pre-4.6), and perhaps add a pointer to using the new capabilities for listing configuration options with |
this makes it easy to configure with any option from build_options.py, with tab completion
Note that the build_options.py table takes an optional enable-XXX label to allow us to replace some of the existing options (eg. --enable-ppp and --disable-ekf3)
we end up with options like this: