Re: [PATCH 02/15] scripts/sbom: integrate script in make process

[Nicolas Schier]

On Wed, Apr 01, 2026 at 01:09:55PM +0200, Luis Augenstein wrote:
> Hi everyone,
> 
> > If sbom.py is unable to parse the build commands, does it exit with a
> > non-zero exit code, correct?
> 
> yes correct. The current behavior is to always parse as much as
> possible, collect all problems, print an error summary in the end and
> exit with a non-zero exit code.
> 
> >> The cmd macro uses 'set -e', so consider moving this up and making it
> >>
> >>     trap  "rm -rf $$roots_file" EXIT; \
> >>
> >> like try-run in scripts/Makefile.compiler does to ensure it is always
> >> cleaned up.
> >
> > hm, well.  Yes, this should do as expected, but please be aware that
> > this also kills the $(delete-on-interrupt) which is part of $(cmd) and
> > removes $@ in case of error or interruption by installing a trap --
> > which will be overwritten.  See also below.
> 
> I think $(delete-on-interrupt) only operates on non-phony targets. Since
> our target is $@=sbom instead of the generated .spdx.json files
> $(delete-on-interrupt) currently has no effect and wouldn't really be
> "killed by intention" by introducing a trap within cmd_sbom.

ah yes, correct.


> > there should be _no_ output on error, regardless of
> --write-output-on-error.
> 
> If this is a general convention we should follow, then we maybe want to
> return a zero exit code in sbom.py in case of errors when
> --write-output-on-error is set, effectively treating errors as warnings?
> Alternatively, we could keep not using --write-output-on-error by
> default. Or we don't follow the convention and write the output
> *.spdx.json files in case of errors.

I don't have a strong opnion on that.  But I think it is important to
keep make exiting with a non-zero exit code if a target fails.  As you
described above, that is the way it is with your current patch set
version; thus I am happy with that behaviour.

> I am not sure what's the most appropriate behavior here. However, we
> know that people will very likely encounter cases with commands unknown
> to the parser. It's not very useful to simply deny generating the entire
> documents, because in many cases the sbom will still be quite usable
> although less complete. For example, if the parsing error occurs close
> to the leaf nodes it cuts off only a small part of the dependency graph
> which still retains most of the information.

Ack.


> Tim Bird apparently already encountered this problem which lead him to
> manually add the --write-output-on-error flag.
> https://birdcloud.org/bc/Linux_Kernel_Missing_SPDX_ID_lines_from_build_SBOMs
> 
> 
> > The cmd macro uses 'set -e', so consider moving this up and making it
> >
> >     trap  "rm -rf $$roots_file" EXIT; \
> >
> > like try-run in scripts/Makefile.compiler does to ensure it is always
> > cleaned up.
> and
> > The common way in kbuild is using '$(tmp-target)'.
> 
> This would be the new version then:
> 
> # Script to generate .spdx.json SBOM documents describing the build
> #
> ---------------------------------------------------------------------------
> 
> ifdef building_out_of_srctree
> sbom_targets := sbom-source.spdx.json
> endif
> sbom_targets += sbom-build.spdx.json sbom-output.spdx.json
> quiet_cmd_sbom = GEN     $(notdir $(sbom_targets))

If all filenames in $(sbom_targets) are w/o path components, the
$(notdir) is obsolete.

>       cmd_sbom = roots_file="$(tmp-target)"; \
> 	             trap "rm -rf $$roots_file" EXIT; \

I don't see a good reason in the trap here, now that the roots file is a
kernel build temp file (ignored by git, removed by make clean).  Thus
I'd rather recommend to remove the 'trap' line as well as the roots_file
variable but use $(tmp-target) instead in all three places.

Thanks!

Kind regards
Nicolas