Opened 8 years ago
Last modified 18 months ago
#53089 new enhancement
option-contains
Reported by: | RJVB (René Bertin) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | |
Keywords: | haspatch | Cc: | |
Port: |
Description
This is a little prototype patch that adds a "contains" function to the options mechanism, something I've often missed when trying to do things like adding depspecs cleanly.
Example:
if {![depends_build-contains port:pkgconfig]} { # pkgconfig already added by one of the included PortGroups depends_build-append port:pkgconfig }
or
variant qtA description {support Qt component "A"} { # someday: qt5.depends_component qt-a depends_lib-append port:qt5-qt-a } variant qtB description {support Qt component "B"} { # someday: qt5.depends_component qt-b depends_lib-append port:qt5-qt-b } ... # pull in some runtime dependency made necessary by either of the qt variants, # checking for the dependency pattern rather than using multiple variant_isset calls if {[depends_lib-contains -regexp port:qt5-qt-*]} { depends_run-append port:shared_runtime_dependency }
Ideally the handle_option-contains procedure would scan over $args and catch all lsearch arguments, but that may be overkill.
Attachments (1)
Change History (3)
Changed 8 years ago by RJVB (René Bertin)
Attachment: | patch-options-contains.diff added |
---|
comment:1 follow-up: 2 Changed 18 months ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 18 months ago by RJVB (René Bertin)
Replying to ryandesign:
Does the in operator satisfy this need?
...
The usual way we handle this however is just to delete before appending.
I guess it does because I had completely forgotten about this ticket (I'd noticed the use of a "prophylactic" -delete
several times in recent months and that also didn't refresh my memory). Note however that the -delete
trick isn't relevant for the example use case in my OP.
Still, looking at this with fresh eyes it strikes me that the addition could be useful of other option-vars too and is a bit more readable (OOP fashion) than the pure Tcl construct.
It remains just a suggestion of course.
Does the in operator satisfy this need?
The usual way we handle this however is just to delete before appending.
It's not an error to delete something that is not in the list; in that case, nothing happens.