SLOC Counter

[garethodickin]

Developer contact info:

gareth.dickin@boeing.com

Internal MR link

tbd

Licensing

OSS Approved for Upstream

Feature request summary

Add a source lines of code counting script that uses verbose make command/build log to count application, platform, Unikraft and musl source code based on Linux CLOC utility. 

Related architectures

Arm64 but could be expanded for x86 build products

Related platforms

Xen and QEMU

Additional context

The script is useful in developing a minimal config and baselining SLOC count and tracking expansion as functionality is added to a Unikraft unikernel. We have a protoype ready for review. Below is an example of the output summary for a small arm/xen appliation:

========================================================================
  SLOC Consistency Report — Running all 3 modes
  Mon Jun 15 12:49:15 PDT 2026
========================================================================

[1/3] Running buildlog mode...
  buildlog: 1364 files, 76788 code lines
[2/3] Running dryrun mode...
  dryrun:   1364 files, 76788 code lines
[3/3] Running preprocess mode...
  preprocess: 1364 files, 55569 code lines (after #ifdef)

========================================================================
  SLOC Consistency Report
  Generated: Mon Jun 15 12:49:56 PDT 2026
  .config:   ./catalog-core/c-hello/.config
========================================================================

  Method              Files     Code   App Code  xen Code  UK Code  Musl Code
  ------              -----     ----   --------  ---------  -------  ---------
  buildlog              1364    76788          6       3024    31012      42746
  dryrun (make -n)      1364    76788          6       3024    31012      42746
  preprocess (gcc -E)   1364    55569          -          -        -          -

  -------------------------------------------------------------------------

  File list comparison (buildlog vs dryrun):
    Common to both:     1364 files
    Only in buildlog:   0 files
    Only in dryrun:     0 files

  Code count comparison:
    buildlog vs dryrun: MATCH (76788 lines)
    #ifdef'd out code:  21219 lines (27% of raw code)
    Effective compiled: 55569 lines

[michpappas]

There is already make print-loc introduced in #1108. Better reporting would be nice to have, the tricky part is to correctly count the LoC compiled into the image. @andreittr that previously introduced this feature can provide more context.

[garethodickin]

It looks like print-loc uses wc -l to count the overall lines in each file in the file list. The proposed sloc-counter uses cloc utility and distinguishes between actual lines of code, spaces and comments. There is also an option using gcc -E to exclude any unused #ifdef'd lines of code. The compiled file list is extracted from the installing rules output in make V=1.
There could be some blind spots or possible overcounting in this method, but, if you think its worth it, I think it could achieve another level of accuracy compared to wc -l.

[michpappas]

It looks like print-loc uses wc -l to count the overall lines in each file in the file list.

So wc -l is not applied to entire files, but to the unique loc DWARF attributes to the emitted machine code on the final linked image:

$(shell $(OBJDUMP) -dl "$(1)" | grep '^/' | grep -v '^/[/*]' | $(SED) -e 's/ [(]discriminator .*[)]//g' | sort -u | wc -l)

The intention is to be as close as possible to what is actually compiled after conditionals, optimizations etc. I'll let @andreittr elaborate when he's back, but my understanding is that while at -O0 it's quite accurate, on higher optimization levels it becomes more of an approximation because of inlining, DCE, etc.

From my point of view the two methods measure slightly different things: The sloc-counter approach measures the lines of authored code, while print-loc focuses on the lines that become machine code in the image. Neither is strictly more accurate - if we want "real compiled footprint" the DWARF method is closer; if we want "how much code we maintain", cloc wins. If the latter is a requirement, adding a second make option - and cloc dependency - is still worth considering.

[garethodickin]

Oh ok, I see the distinction now. For us it was useful in breaking out sloc by config and source contribution. I think both add value, but will defer to you and your team. If we do upstream this, I'm happy to add documentation describing both print-loc and sloc-counter, as well as pull it in as a make rule to match the existing method.

[michpappas]

We had a discussion, and we're okay with that. Feel free to open a PR and we can discuss details there.

[andreittr]

Hi! I can confirm that the current implementation of print-loc and your proposal for using cloc would indeed target subtly different use-cases (lines present in the binary image after all optimizations vs. source lines being fed into the compiler). I agree that both are useful, and have no issues with adding a separate makefile target for it.

One minor nitpick on the issue of naming: sloc-counter is not very aligned with the rest of unikraft's misc/informative make targets, which all presently start with print-; perhaps a better name would be print-sloc-stats? Optionally, print-loc could also be renamed/aliased to a more descriptive print-used-sloc for consistency. (Names not final, up for discussion).

[garethodickin]

Hello! Ok great, I'll change the naming to align with unikraft convention, as well as rename the current print-loc for consistency.