Re: [Buildroot] [PATCH 00/29 v2] package: improve for better pulseview integration (branch yem/sdcc-fx2lafw)

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Thomas, All,

On 2025-04-19 17:17 +0200, Thomas Petazzoni spake thusly:
> On Wed,  9 Apr 2025 22:03:42 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > This series aims at making the pulseview and other sigrok-related
> > packages more integrated. The series is articulated around three main
> > goals, the details of which are expanded later:
> >  1. cleanup and extend pulseview dependencies, notably the need for
> >     fonts;
> >  2. extend the boost package, for a better host variant, and better
> >     maintainability;
> >  3. introduce sdcc and fx2lafw, to allow use of Cypress FX2-based logic
> >     analyzers.
> 
> Wow, this is a large series doing a lot of stuff.

Yes, but it is all related and triggered by the f2xlafw package coming
last in the series... So, a lot of different things, but to an ultimate
common goal.

> I already applied a
> few of the preparation patches in order to reduce a bit the size of
> your series.

\o/ :-)

> Now, I have several concerns about different aspects of the series.
> Nothing I am entirely against, just topics on which I am not 100% sure
> on how we want to deal with them.
> 
> First topic is the some-font package and this whole idea that all font
> packages should at least install some font. One thing that bothers me
> is that fonts can be provided in different formats, and "some-font"
> doesn't say which font format will be used/available. Should we make
> this "some-ttf-font", or something like that? Is that even a mechanism
> we want in Buildroot at all? Arnout, Peter, Julien, Romain, any opinion?

Yes, the some-font stuff is not what I am most proud of. If you have a
better idea on how to allow applications to request that some font be
available, or some refinements on my solutions, I'm all ears and eyes.

As for TTF vs fixed-width, I don't think that makes a difference.
Applicaitons usually use a font rendering library, like fontconfig and
harfbuzz et al. which would load and render text from whatever font they
are told to load, or that is available... In the very limited use-case I
had, running pulseview full-screen on framebuffer on rpi2, it was
working very well whatever the fonts that were installed (the text would
look slightly ugly/weird at times, but was rendered OK).

But I'm by far not an expert in fonts, so I may very well be talking
bullshit.

> Second topic of concern is how you handle the host-boost dependency.
> You add a "select BR2_PACKAGE_HOST_BOOST" to all packages that need
> host-boost, adding hidden Config.in.host options for all of them. Is
> this really what we want? So far, we have never required
> BR2_PACKAGE_HOST_* options to be selected (think
> BR2_PACKAGE_HOST_PKGCONF for example). So to stay consistent, I would
> rather suggest that the BR2_PACKAGE_HOST_BOOST_<something> hidden
> options that are needed get added and selected by whoever need them,
> but BR2_PACKAGE_HOST_BOOST isn't needed, nor it is necessary for
> packages to select it.

The thing is, if you look for example to the package host-odb, it does
not itself need host-boost, but it depends on libodb-boost, which does.
Today, libodb-boost does not need any of the boost extra libraries, but
if tomorrow it does, then without a host-libodb-boost Kconfig symbol, it
would be host-odb that would have to carry the selection of that extra
boost library; that does not sound too nice to me...

Second, if a package selects HOST_BOOST_BLAH, it is not too much of a
burden to also select _HOST_BOOST, I believe. I modeled that from the
host-python3 package: there is a main symbol that has to be selected
before sub-options can also be selected. Granted, host-python also has a
prompt and can be enabled on its own, which is not the case for
host-boost. However, I think it would be a little bit awkward to have
symbols for sub-options of a package that has no main symbol for
itself... (but if the consensus is to just drop the main symbol, and
just keep the rest of the symbols as-is for a configurable host variant,
I will not argue further, that would be fine for me as well).

> Of course, unless we decide to bite the bullet
> and have Config.in.host options for all host packages, always selected,
> but that's a huge effort and complicated one (think host-cmake, which
> may or may not be built depending on whether there is a suitable CMake
> version on the host machine).

We already talked about this and we already tried, but it really is way
too much to do; let's concentrate on those packages where that is
actually needed and/or makes sense and/or is not too much trouble...

However, to be honest, that is not the part of the boost changes I was
expecting the most comments about; I had rather expected some (very
needed!) questioning on that subset:

    utils/check-symbols: allow ignoring some defined-but-unused symbols
    package/boost: commonalise list of libs
    package/boost: check that known libs match Boost's list

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot