Fwd: Identify 3rd party source in spec?

[Kinsey Moore]

On Tue, Nov 1, 2022 at 11:25 AM <oss at c-mauderer.de> wrote:

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

I agree that an implicit "third-party: false" is preferable.

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


I don't think this should be required for the initial implementation with
existing 3rd party source, but it would be good to define how we do this
for any new 3rd party source that is brought in. Adding this for existing
3rd party inclusions could easily be a janitor task.

For rtems-lwip, I've been enforcing addition of an ORIGIN.* file for new
source imports with an upstream commit hash in the commit message, but that
was added basically from the beginning and almost all directories in the
root of that project are 3rd party source imports that have pretty clear
origin, upstream, and licensing.

>
>
> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221101/c64953f6/attachment.htm>