Fwd: Identify 3rd party source in spec?

Gedare Bloom gedare at rtems.org
Mon Oct 31 19:01:33 UTC 2022


Resending without the first patch since it may trigger size filters.

---------- Forwarded message ---------
From: Gedare Bloom <gedare at rtems.org>
Date: Mon, Oct 31, 2022 at 12:55 PM
Subject: Identify 3rd party source in spec?
To: devel at rtems.org <devel at rtems.org>


Hello all,

I would like to float the idea of managing 3rd party source tracking
through the build system spec files. I believe this would be the most
efficient way to maintain this information, and we can leverage the
existing build system code for tasks such as automatic format checks,
generating lists of third-party code, etc.

This will require refactoring some spec files to pull 3rd party code
out to a separate .yml file that gets linked. Once that is done, then
we could add another attribute for this tracking purpose. I would like
to keep it simple as a boolean, maybe just "third-party: true/false"
Attached is an example patch showing how this might work for the
dtc/libfdt code as a build objects item type 'obj', and for zlib
library as a build library item type 'lib' with some proof-of-concept
code for generating a listing of third party source files.

As an initial step before making this refactoring, I have added an
explicit default "third-party: false" attribute to every yml file
preceding the enabled-by: attribute, using the following bit of shell:
rtems.git/spec/build$ find . -name "*.yml" | xargs sed -i -e
's/\(enabled-by.*\)/third-party: false\n\1/'

This touches 2333 files adding that one line, which is the contents of
the first 1 MiB patch attached in the series. The remaining patches
then layer on the top and are functional, outputting:

rtems.git$ ./waf third_party_list
cpukit/dtc/libfdt/fdt.c
cpukit/dtc/libfdt/fdt_addresses.c
cpukit/dtc/libfdt/fdt_empty_tree.c
cpukit/dtc/libfdt/fdt_ro.c
cpukit/dtc/libfdt/fdt_rw.c
cpukit/dtc/libfdt/fdt_strerror.c
cpukit/dtc/libfdt/fdt_sw.c
cpukit/dtc/libfdt/fdt_wip.c
cpukit/zlib/adler32.c
cpukit/zlib/compress.c
cpukit/zlib/crc32.c
cpukit/zlib/deflate.c
cpukit/zlib/gzclose.c
cpukit/zlib/gzlib.c
cpukit/zlib/gzread.c
cpukit/zlib/gzwrite.c
cpukit/zlib/infback.c
cpukit/zlib/inffast.c
cpukit/zlib/inflate.c
cpukit/zlib/inftrees.c
cpukit/zlib/trees.c
cpukit/zlib/uncompr.c
cpukit/zlib/zutil.c

I'll continue to work on this, feedback is requested though if this is
a good direction or how to improve.

Gedare
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-wscript-add-command-to-print-third-party-sources.patch
Type: application/x-patch
Size: 1719 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221031/f17c0eef/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-spec-build-mark-objdtc-and-libz-as-third-party.patch
Type: application/x-patch
Size: 1092 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221031/f17c0eef/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-spec-build-split-dtc-sources-from-librtemscpu.patch
Type: application/x-patch
Size: 2465 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221031/f17c0eef/attachment-0002.bin>


More information about the devel mailing list