Fwd: Identify 3rd party source in spec?

[oss at c-mauderer.de]

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 <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.

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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel