The implication of that is that you want to use a header file from a host component of the SDK to be able to compile additional tools etc to run on the host after the SDK has been created? Normally th

OK, so all that's left to do is to move them into their own config fragment (since they have nothing to do with the existing getops config fragment).

What's the connection between enabling the getopt applet (a utility to help with parsing options in shell scripts etc) and enabling support for long options in a bunch of other unconnected apps? I thi

You can either use an intermediate variable in the recipe, e.g. PRUNESOURCE = "" PRUNESOURCE_libc-musl = "the-real-function" do_patch[postfuncs] += "${PRUNESOURCE}" Or you can call the script uncondit

Changes to source files, including removing them, should be done as part of the do_patch task. Since do_patch is implemented in python you can't simply _append shell script commands to it, but you can

Yes, sounds good to me.

It's very clearly a hack. Maybe it's the "official solution" for supporting https with busybox wget, but OE has a wider scope - we're not limited to busybox wget if a better overall solution is availa

<randy.macleod@...> wrote: This was discussed on the list last year. The conclusion was that FEATURE_WGET_HTTPS should be disabled by default (ie giving anyone who needs to fetch from https

<robert.joslyn@...> wrote: Adding —enable-largefile to EXTRA_OECONF would be fine. In general the goal of PACKAGECONFIG is not to expose every possible configure option, but only the ones

<robert.joslyn@...> wrote: The largefile distro feature is for historical reference only. Recipes should always enable largefile support regardless of the distro feature (which will event

It looks like you forgot to update BINV ?

The list of PACKAGECONFIG options is sorted, so the options for libgsasl should be added between the options for ldaps and libidn, not at the end after the options for zlib.

Seems questionable for backporting to a stable release. The bogus PROVIDES lines have been there for more than a decade without causing any issues (ie removing them isn't fixing a bug).

What's the specific concern? It won't work well for -native recipes (as discussed in another of these threads), but apart from that it should work OK. To be safe for use in a -native recipe you could

<devendra.tewari@...> wrote: If there are subtle issues which you don't yet understand then that's all the more reason for not hiding the new shutil.move code behind a test which will pass for 9

<devendra.tewari@...> wrote: It would be better to use shutil.move unconditionally in all cases, rather than have a separate shutil.move code path which only gets tested by people doing incremen

That line dates back to 2007, when packagegroup-base.bb was still called task-base.bb: https://git.openembedded.org/openembedded-core/commit/?id=ba9dd5228c290c96c622fb82964e49ce2511a1e9 Maybe it had s

PROVIDES sets up a name which can be used as DEPENDS (ie a build time dependency) in other recipes. If PROVIDES contains more than one name, they all just become aliases for each other. Since packageg

<richard.purdie@...> wrote: If there's code in the upstream tar file etc which is not involved at all in the build of the one particular sub component you're interested in then this ty

Do these new variables need to be exported? As far as I remember a few of the BUILD_xxx variables are "official" autotools variables which some autotools packages may expect to find in the environment