Just to give an example what I mean, in Qt we the feature system something like this: ./configure -with-feature-nofoo ... code behind: #ifdef NOFOO ... #endif It would be nice to have that simplicity when it is not a direct mapping between PACKAGECONFIG and configure, etc. For instance, I would like to disable something in a python function inside busybox.inc depending on a PACKAGECONFIG variable. It is now quite a bit of work to do instead of a handy syntax as desribed above.
Busybox is a rather complicated beast. PACKAGECONFIG is unfortunately not sufficient to manage it's config system. It is very similar to the Linux kernel config and we recently added configuration fragment support to busybox from the kernel recipes: commit 56dc1720caa48344238d352c7b6e9b0f0d41aa54 Author: Chen Qi <Qi.Chen@windriver.com> Date: Tue Feb 5 14:36:40 2013 +0800 busybox: add config fragments This allows you to use the default config and include only the delta in your layer's bbappend in the form of a config fragment added to the SRC_URI.
.
This report has ** nothing ** to do with busybox. Please think, please-please, think, before acting. It was claimed explicitly and thoroughly discussed. You should not have the focus to close bugreports, but solve issues. If you do not understand the basics, like you seem to present in here, ask, and we will enlighten you if we can.
Just to make it clear, it is a generic extension. busybox was only an example of those.
This solution has also been recommended on the mailing list when my change was being rejected not to unbreak master with not the latest toolchain versions. I expect to have similar scenarios here and there. If you mean, it is not PKGCONFIG material, feel free to rename the title to a newly established variable if that is the concern. As for me, the feature matters. I would like to get a buildable master with my toolchain.
Laszlo, if you want our help, you'll have to keep it civil. Accusing project leads of not understanding the basics is not likely to achieve your desired result. Busybox was the only concrete example, which is why I responded to that. Please provide a specific example of where the system is failing you. Which recipe? Which configuration item? Specificity is required. There are a number of configuration mechanisms available to bitbake recipes and bbappends, it's possible one of those will already address your needs. If you want a general extension, use examples that fit in the context of the recipes. Are you looking for some way to modify the EXTRA_OECONF variable? def do_configure_append: if not pkgconfstr.find("libfoo"): EXTRA_OECONF += "--with-feature-nofoo" is this what you're looking for?
I am being civil. It does not matter who is the project lead or not. I call that civil when someone is coming up with the "title". Let us not do ping-pong emotional games. :-) After all, you did/no not understand the issue behind the bugreport, did/do you? Please see the mailing list for the discussion with the following title "[PATCH] busybox-1.21.1/defconfig: disable rfkill". There is a relevant discussion on IRC where we discussed this with Robert the outcome of which was this claim. If you do not find the IRC discussion, I can paste the link. Hope that helps.
"I call that not civil".
Sorry, I meant "Ross" (Burton).
To approach it from a different angle, will you fix the busybox issue with the old toolchain? If I do not get such support from the Yocto project, how will you simplify my work instead of this issue?
You did not answer the question. If someone doesn't understand your request it may be their lack of context/knowledge, it may also be that it was insufficiently described. Also, the NEEDINFO state should be cleared by the person setting it. Unless you want to own this bug? For your information, Ross and I discussed this earlier today already. If you feel there is something relevant in the IRC log, by all means, copy it here. A bugzilla entry must be fully self-describing. I provided a rewritten example to try and coax out of you what you are looking for. Was this closer to what you intended? If not, please provide your own.
You might leave it with NEEDINFO even if I provide the answer. I saw it happening already on this bugzilla ... which would mislead the bug triagers ... At any rate, you seem to think this is only a config issue, however it is not. If it was a configuration issue, I could have already solved the situation semi-nicely. Also, I provided in my very initial post, what the end result for my change should be once PACKAGECONFIG has a bit more thorough support. Why is that not clear? There is more to it than just changing the "defconfig" file. Perhaps, that is what you overlooked?
IRC log as requested: https://www.yoctoproject.org/irc/%23yocto.2013-07-31.log.html#t2013-07-31T10:05:04
(In reply to comment #13) > You might leave it with NEEDINFO even if I provide the answer. I saw it > happening already on this bugzilla ... which would mislead the bug triagers > ... Since that would be me, I think I can manage.
As I'm being referenced I'll put it on record that whilst I (along with others) said that PACKAGECONFIG is the preferred form of per-distro configuration in general and probably for busybox specifically, the extreme flexibility of busybox combined with the existing config fragment system (same as our kernel uses) means that PACKAGECONFIG isn't ideal after all.
Darren, it really is not just about triagers. It is also about any readers. I saw users stopping to push something forward because the "assignee" left the stuff at NEEDINFO. Anyway, you are not even the assignee, and it is also off-topic. Did you get your information now? Also, you pasted a commit. Note, you are writing to a user now using release tarball, etc. Please paste full documentation with snippets and examples how to approach this issue if possible. Cheers.
(In reply to comment #17) > Darren, it really is not just about triagers. It is also about any readers. > I saw users stopping to push something forward because the "assignee" left > the stuff at NEEDINFO. Anyway, you are not even the assignee, and it is also > off-topic. You said triagers, not me. > > Did you get your information now? Nope. > > Also, you pasted a commit. Note, you are writing to a user now using release > tarball, etc. Please paste full documentation with snippets and examples how > to approach this issue if possible. Cheers. Sure.
After reading through the oe-core thread on busybox and packageconfig referenced in Comment 8 and the IRC log provided in Comment 14, the nature of the requested feature is still unclear to me. The reporter states it is not just about configuration, but all the discussion is about configuration. The only thing clear to me so far is this: busybox CONFIG_RFKILL breaks the build for older toolchains and the reporter would like a way to use PACKAGECONFIG to easily turn that option on or off. Unfortunately, busybox already has a very complicated build environment (that frankly needs to be reworked to be completed based on config fragments). It is likely that even with this change, some user-layer change or bbappend will be required to make use of it, and that can already be accomplished via a config fragment in a user busybox bbappend for the one example given. I provided an example in Comment 6, which the reporter doesn't appear to think addresses the issue. The bug will remain open through Friday August 9th 2013 in the NEEDINFO state to give the reporter an opportunity to provide a more complete description of the feature requested, including an example usage, from which a solution can be drafted. Without that, the bug will be rejected.
def do_configure_append: if not pkgconfstr.find("libfoo"): EXTRA_OECONF += "--with-feature-nofoo" is this what you're looking for? ================================================= No, because that does not address the fact that certain part of the python function should not be executed. Just turning off the defconfig entry for busybox will make it buildable. If you do not believe me, try it yourself and see.
Without the requested information on what the reporter is looking for as a resolution, a solution cannot be crafted. Closing per Comment 19.
Actually, I already wrote, and you have not asked any question about that, so I consider careless to close this accordingly without any further clarification what the problem with that would be. Not sure why my opinion is asked if that is not read or/and considered then without any explanation.
Please read comment 19 again, particularly the part about example usage.
Please read comment 1 again, particularly the part about example usage.
I am honestly trying to help you here. Your explanation was not clear. I have discussed this with multiple people here, including those you had separate conversations with, trying to sort out what exactly you are getting it. We agreed more information was needed. I provided you with an example and asked you to provide a counter example. You have refused, continually referring back to the initial report which provides a C sourcecode example which doesn't apply to a recipe or an include file. We cannot be expected to translate your frame of reference to our own without any help from you. Since you refuse to present your idea in a way that can clarify it for the people responsible for providing a fix, we simply cannot help you.
That is actually untrue based on the fact the people also recommended the same as I just followed in comment 1. That has been publicly discussed and suggested on the mailing list by multiple people. Please discuss the details on the mailing list if you think I am unclear. Honestly, I cannot imagine what is unclear, and you have not provided any specific question which part is unclear. As for your claiming about example, I have not seen any. Where exactly did you provide a self-explanatory and well-understandable example?
Darren, can you provide, or repaste if you think it had been, the solution one should use to unblock the scenario with busybox with these circumstances? Until that is done, I think people are not unblocked.
As I suggested before already, it is not "INVALID" as the documentation is still missing. As another person confirmed me on the mailing list, documentation would be welcome. So, please do consider reopening this based on an earlier suggestion in this thread, and rename the title accordingly. It is fully unclear at this point if there is a feature supporting ifdef'ing of python entries in some way or another. This is obviously not so good for end users.
Ping? I tried to ask for clarification why documentation is not added, and the bugreport has stayed in "Resolved/Invalid" state without documenting this feature. See? That is why I do not like bugs closed because developers simply will not come back to it this way. One person was looking for this feature on IRC (#yocto) a few minutes ago, and I could not simply point him to a documentation, but bugreport and email chunks to get all the necessary information in a raw form he needs. Could we please improve this situation? In other words, can we turn this report into a documentation issue to document code fragments? Is it already done? Mind giving a link in that?
There seems to be some example added _after_ my request for documentation, so at least this is partially a good sign and outcome of my request: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ff10f72abda52315b892c64f711096772d9a4c1c However, this is still code-level detail, and not documentation. Either way, if this report is closed at all, it should be closed by "fixed" (Example is added). That would not solve the documentation request still, though. If you think it is better to mark this report as "fixed", please do so and I will open a new documentation report for improving the situation further on.