On Wed, 2025-08-20 at 15:07 +0200, Baurzhan Ismagulov wrote:
> CAUTION: This email originated from outside of the Elektrobit
> organization. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 
> On 2025-08-20 05:40, 'Schmidt, Adriaan' via isar-users wrote:
> > > > I am wondering if a specific styleguide exists for isar?
> > > > Normally for
> > > > bitbake based projects I am using oelint-adv.
> > > > 
> > > > When I played around with dpkg-raw and wanted to install some
> > > > file
> > > > under /etc, this caused the linker to complain about not using
> > > > sysconfdir for etc.
> > 
> > Well, yes and no...
> > Years ago I very briefly looked into technical solutions for
> > bitbake linting (maybe it was oelint-adv, but I don't exactly
> > remember), and how flexible/extensible those might be.
> > Even with that in place, it would be up to the Isar Community to
> > actually define a style and rules, but as far as I'm aware nothing
> > like this exists yet.
> > 
> > > > Is there a specific reason why isars bitbake.conf would omit to
> > > > also
> > > > define variables got etc, bin and friends?
> 
> We've looked at pylint but not at oelint-adv.
> 
> Ideally, we imagined our recipes as three-liners (inherit dpkg,
> SRC_URI, SRCREV
> or similar) which wouldn't require much of style. In the (very
> distant) future,
> we'd need automatically created recipes or even not need recipes at
> all (all
> necessary metadata is already inside the Debian-style source
> packages).
I was thinking about recipes that inherit dpkg-raw e.g. sdk-files.bb
>  This
> not being the case today :) , I think oelint-adv could be evaluated
> whether
> it's useful and configurable enough for Isar. Experiences welcome.
> 
we have ok experiences with the following config:


FILES="$(find . -name "*.conf" -o -name "*.bb*" -o -name "*.inc")"
oelint-adv \
    --suppress oelint.var.mandatoryvar.HOMEPAGE \
    --suppress oelint.var.mandatoryvar.DESCRIPTION \
    --suppress oelint.task.docstrings \
    --suppress oelint.task.heredocs \
    --suppress oelint.vars.homepageping \
    --suppress oelint.vars.mispell \
    --suppress oelint.vars.pathhardcode \
    --exit-zero --quiet --hide info --output result \
    --messageformat "::error file={path},line={line}::{id}::{msg}" \
    $FILES
> Regarding your specific questions -- sysconfdir, etc, bin and friends
> -- those
> vars are very OE-specific and in are in case of Isar all managed by
> the Debian
> package building infrastructure. So my wish would be exactly about it
> -- if the
> tool turns to be useful for Isar, we shouldn't force people to deal
> with many
> false positives.
> 
> Other than that, seems that the tool is not intended to provide pure
> formatting
> guidance, but also real style guidance -- in that case, I think major
> effort
> would be needed to make it useful to check for Isar development
> patterns
> .
> 
> With kind regards,
> Baurzhan
> 
> 
Kind Regards,
Simone Weiß

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/461d97ae67082dcea8ff99b83451c8c436cd9024.camel%40elektrobit.com.