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 <ged...@rtems.org> wrote: > > Resending without the first patch since it may trigger size filters. > > ---------- Forwarded message --------- > From: Gedare Bloom <ged...@rtems.org> > Date: Mon, Oct 31, 2022 at 12:55 PM > Subject: Identify 3rd party source in spec? > To: devel@rtems.org <devel@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
