Identify 3rd party source in spec?

[Gedare Bloom]

The patches are available at
https://git.rtems.org/gedare/rtems.git/log/?h=test-split-3rd-party

On Mon, Oct 31, 2022 at 1:01 PM Gedare Bloom <gedare at rtems.org> wrote:
>
> 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