On Fri, Apr 16, 2021 at 7:28 AM Robert Joslyn
Adding —enable-largefile to EXTRA_OECONF would be fine.On Apr 16, 2021, at 12:17 AM, Andre McCurdy <armccurdy@...> wrote:Is it worth making it a PACKAGECONFIG at all, or is it preferred to just set —enable-largefile in EXTRA_OECONF? The upstream configure script does enable this by default so it’s not strictly needed at all either, but I usually prefer to be more explicit with configure options (as you can probably tell with this patch!).
In general the goal of PACKAGECONFIG is not to expose every possible
configure option, but only the ones which we want to encourage people
to experiment with or use to control high level functionality. An
option to break support for large files doesn't fit into that
My preference doesn't matter much :-) I was suggesting that you lookI’m not sure what you mean. Would you prefer them on one line rather than split? In a specific order? There seems to be a lot of different styles in use, so I tried to follow the OE style guide, which suggests splitting lists like this, but maybe I’m misunderstanding.+ backtrace \This is not conventional formatting for a list of PACKAGECONFIG
in oe-core to get a feel for the typical style. Note that the OE style
guide mostly predates PACKAGECONFIG and hasn't been updated to cover
it in any detail.
See the comment above about the goal of PACKAGECONFIG not being toSome recipes do use PACKAGECONFIG, such as ffmpeg, but in grepping the repo it seems more common to use EXTRA_OECONF. Is there a reason not to use PACKAGECONFIG here? Just that building the static libraries is uncommon? I don’t mind changing it, just curious.+"The choice to build shared and/or static libs is not something which
expose every possible option. However, there are no well defined rules
about it (and in general in OE, what rules there are are not
consistently enforced) so patches like the one to ffmpeg which
converted a lot of inappropriate configure options to PACKAGECONFIG
options do sometimes get merged.
Specifically for shared and static libs, shared libs are generally
enabled by default but if a particular component didn't do that then
the normal approach would be to add a configure option to enable them
to EXTRA_OECONF. Static libs are generally unused but harmless, so
don't justify a PACKAGECONFIG option to control them. The only real
downside of enabling static libs is the wasted build time. If that
concerns you then you can try including
conf/distro/include/no-static-libs.inc in your distro config file.
I don't think backtrace justifies a PACKAGECONFIG option, especiallyI wasn’t sure the best way to handle this. I can put it back the way it was, where the configure script enables the feature by default and it’s disabled only for musl. I could keep the packagconfig and append only for glibc:+PACKAGECONFIG[convert] = "--enable-convert --with-convert=ext2,--disable-convert --without-convert,e2fsprogs"Use of _remove in core recipes is discouraged.
if the default value for the option is problematic (as it seems to
be). The original approach of appending --disable-backtrace to
EXTRA_OECONF for musl builds looks fine.