Closed tarik02 closed 5 years ago
From https://docs.bazel.build/versions/master/skylark/language.html:
The following basic types are supported: None, bool, dict, function, int, list, string. On top of that, two new types are specific to Bazel: depset and struct.
So the types of features must be limited to these. For example, no floats.
There is a problem with the way how to collect features from packages, e.g. if there is two packages containing the same dependency with different features. Also, there should be some way to collect features from all manifests.
There is a problem with the way how to collect features from packages, e.g. if there is two packages containing the same dependency with different features
This is the nature of the beast. It is similar to conflicting version constraints.
Things to consider:
In the C/C++ world there are two kind of features: additive and exclusive features.
An example for additive features is -DWITH_GTK
in OpenCV.
Other flags may be exclusive eg. -DWITH_RTTI
may be exclusive as they may change the ABI.
If we encounter different feature requirements that are additive then we can merge the features.
If we encounter a different exclusive features we have a conflict. In this case the user needs to intervene as there is no obvious way how to resolve this situation. Ways the user can resolve this are:
The later one is not implemented in Buckaroo yet.
However we can override configurations in Buck quite easily using the buck build -c <cell>//feature=value
syntax.
If we provide an option to ignore feature conflicts this conflict could be manually resolved by the user at build-time.
Whether we should allow this kind of practice is probably an important discussion to have...
Is this something that should be handled in package management, or should it be done in build management?
Have no idea how to continue this PR. Sorry.
An ability to pass parameters (features) to dependencies and to use them in
BUCK
configs. Features comes with condition system allowing to disable dependencies based on dependencies.Description
Features can be set for each dependency. Here is an example:
GLAD library itself has a generator script which can be called using
gen_rule
fromBUCK
. So, features will allow to configure the script.Feature types
Current implementation will have these types:
boolean
integer
string
dict
- associative container with string key and any value of plain typeslist
- list of any plain valuesConditions
Conditions are the way to disable some of dependencies based on passed features. Example:
condition
field can be array, then the dependency will be enabled when at least one of conditions are true.Condition text is python-like expression, but with very limited syntax.
Condition evaluation
If a feature used in condition is not specified, the condition will be false. List of operators:
Also, there can be single
not
prefix which inverts the result of condition evaluation. Example:Related Issue
Closes #344
Motivation and Context
It is very useful feature to pass some parameters to universal dependencies. This is very common in C++ code, especially in cross-platform libraries.
Useful links:
How Has This Been Tested?
Still WIP
Types of changes
Checklist:
Progress: