| Summary: | Improve the detection of misplaced parameters | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Igor Stoppa <igor.stoppa> |
| Component: | bitbake | Assignee: | Ross Burton <ross.burton> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | poky.bs.watcher, poky.watcher |
| Version: | unspecified | ||
| Target Milestone: | 2.3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
Igor Stoppa
2016-09-08 10:06:13 UTC
There's very few variables that *need* to be set in local.conf vs distro conf vs recipe (I can't think of anything apart from the obviously recipe-specific instances such as FILES), and in fact a large number of variables are explicitly available to be set in all three (user customisations, distro defaults, recipe overrides). Personally I feel that context is sufficient: don't set FILES in local.conf, don't set DISTRO_NAME in a recipe, etc; and where it isn't then the documentation should clarify. From an implementation point of view, there's no difference between distro/local/recipe beyond filename, whether a copy has been made, and parse order, so I think this would be distinctly non-trivial to implement. I obviously disagree with the statement that the context is sufficient, otherwise I would have not created the issue report :-) Improving the fine manual is ok, but it is not particularly developer friendly, after having done so, to just reply RTFM. I can understand if the answer is: "improving this has a low ROI" However I do not understand why this would be a non-trivial change. Wouldn't it be sufficient to search for the fingerprint part of he string ()in the example, CONF_ and compare it against the type of file where th CONF_xxx entry is used? (In reply to comment #2) > However I do not understand why this would be a non-trivial change. > Wouldn't it be sufficient to search for the fingerprint part of he string > ()in the example, CONF_ and compare it against the type of file where th > CONF_xxx entry is used? If we're happy to accept a complete API break as large numbers of variables change their name, sure. Not sure that's a good tradeoff though. It depends on how the change is introduced. What you describe is a hard change. If it was made available as opt-in feature, new/converted recipes could use it, while others wouldn't be affected. All I can say as a user, is that it feels unnatural to have 3 different types of file where to put basically the same type of assignment, without (afaik) a simple way to figure out what is set where. The example I gave in the issue report seems to agree with my feelings. I do not particularly care that it is done in the way I proposed, if the change I proposed is unfeasible/hard to implement and the same improvement can be achieved better/more easily through automated means. Adding more documentation will eventually turn the mega manual into a giga manual, but I doubt it's reasonable to expect the user to remember it all. Not if the goal is to provide a pleasant experience. If a variable can go in multiple places then there tends to be a good reason for that: is it distro policy, recipe configuration, or user overriding. Other variables have clear scope: RDEPENDS for example is recipe-specific. I don't see adding a naming convention or metadata being sufficiently useful to warrant the impact. (In reply to comment #5) > If a variable can go in multiple places I do not know how it has come to this, when the request was about the opposite: (In reply to comment #0) > Some parameters are meant to be used only when placed inside local.conf or > similar configuration file (ex: distro.conf) > > However there is no mechanism that can help the person trying to use a > recipe, to figure out that the parameter was misplaced (ex: inside a .bb > .bbclass or .bbappend file). |