Hello Gedare,
Am 31.10.22 um 20:01 schrieb Gedare Bloom:
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.
Sounds like a good idea to have it in the build specification items.
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.
Is it a good idea to make it a mandatory attribute? It makes the yaml
files bigger. It will only mean that we have to look for copy and paste
bugs instead of missing attributes if someone adds a new third party
library.
Do we need some additional information / scripts / stuff for third party
code? Like an upstream source or upstream version? For example the JFFS2
code has a VERSION file with lots of information:
https://git.rtems.org/rtems/tree/cpukit/libfs/src/jffs2/VERSION
For the imxrt I added something similar in the commit description:
https://git.rtems.org/rtems/commit/bsps/arm/imxrt/nxp?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285
Full text is a bit big for an attribute but maybe the location of a
VERSION file in the source tree? Or a minimal link to an upstream code
and a version info?
Best regards
Christian
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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
