sierrafoxtrot / srecord

SRecord github Mirror

SRecord

The SRecord package is a collection of powerful tools for manipulating EPROM load files.

I wrote SRecord because when I was looking for programs to manipulate EPROM load files, I could not find very many. The ones that I could find only did a few of the things I needed. SRecord is written in C++ and polymorphism is used to provide the file format flexibility and arbitrary filter chaining. Adding more file formats and filters is relatively simple, see the Reference Manual. -- Peter Miller (original author of SRecord)

The SRecord package understands a number of file formats:

• Ascii-Hex: input/output; also known as ascii-space-hex
• ASM: output only; for embedding data into Assembler code
• Atmel Generic: input/output; used by Atmel AVR assembler
• BASIC: output only; for embedding data into BASIC code
• BinaryBinary: input/output
• B-Record: input/output; also known as Freescale Dragonball bootstrap b-record
• C: output only; for embedding data into C code
• COE: output only; Extension .coe; also known as Xilinx Coefficient File format
• Cosmac: input/output; also known as RCA Cosmac Elf format
• DEC Binary (XXDP): input/output
• Efinix hex/bit: input;
• Elektor Monitor (EMON52): input/output
• Fairchild Fairbug: input/output
• Formatted Binary: input/output
• Four Packed Code (FPC): input/output
• Gowin fs: input;
• Hexdump: output only; a simple hexdump
• HP64000 Absolute: input only
• IDT/sim: input/output
• Intel: input/output; also known as Intel MCS-86 Object format
• Intel Absolute Object Module Format (AOMF): input/output
• Intel 16 (INHX16): input/output; also known as Intel hexadecimal 16
• LSI Logic Fast Load: input/output
• Logisim: input/output
• Memory Initialization Format: output only; Extension .mem; used by Lattice Semiconductor
• MIF: input/output; used by Altera Memory Initialization File format
• MOS Technology: input/output
• MIPS-Flash: input/output
• Motorola S-Record: input/output; also known as the Exorciser, Exormacs or Exormax
• MsBin: input/output; also known as Windows CE Binary Image Data format
• Needham: input/output; also known as Needham Electronics ASCII file format
• OS65V: input/output; also known as Ohio Scientific hexadecimal format
• PPB: input/output, also known as Stag Prom Programmer binary
• PPX: input/output, also known as Stag Prom Programmer hexadecimal
• Signetics: input/output
• SPASM: input/output; used by a variety of PIC programmers
• Spectrum: input/output
• Tektronix: input/output
• Tektronix Extended: input/output
• Texas Instruments Tagged: input/output (both 8 and 16 bit); also known as TI-tagged or TI-SDSMAC
• Texas Instruments ti-txt: input/output; used by bootstrap loader of TI MSP430
• TRS-80: input/output; used by The Radio Shack
• VHDL: output only
• VHDL textio: output only; suitable for loading with textio.read() into a bit_vector
• Verilog VMEM: input/output; suitable for loading with $readmemh()
• Wilson: input/output; mysterious type of EPROM writer

Full documentation and binary packages can be found at the SRecord website

srecord's Issues

srecord-1.65.0 forces install into /usr even if CMAKE_INSTALL_PREFIX is defined

The install is being forced into /usr, which is often write-restricted. CMakeLists should honor $CMAKE_INSTALL_PREFIX.

cmake -DCMAKE_INSTALL_NAME_DIR=/opt/sw/lib -DCMAKE_INSTALL_PREFIX=/opt/sw .
...
-- Packaging for Macintosh
-- gcrypt location 
-- CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION lib
-- CMAKE_INSTALL_PREFIX /usr
-- CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION lib
-- CMAKE_INSTALL_PREFIX /usr
-- CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION lib
-- CMAKE_INSTALL_PREFIX /usr
...
lots of building...
...
make install DESTDIR=/tmp/srecord
Install the project...
/sw/bin/cmake -P cmake_install.cmake
-- Install configuration: "Release"
-- Installing: /tmp/srecord/usr/lib/liblib_srecord.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /tmp/srecord/usr/lib/liblib_srecord.a(vsnprintf.cc.o) has no symbols
-- Installing: /tmp/srecord/usr/include/srecord
-- Installing: /tmp/srecord/usr/include/srecord/format_printf.h
-- Installing: /tmp/srecord/usr/include/srecord/quit.h
-- Installing: /tmp/srecord/usr/include/srecord/endian
...

fixes from @marcows repo

I was happy to learn that you are back and active maintaining srecord - great news.

Are you keeping track of the changes Markus has in his repo, to eventually merge them back into upstream ?

For example,

• fix-end-of-address-space branch - 4 commits, could probably be rebased + merged ?
• reference-manual-pdf-features branch - probably difficult to port now due to different doc generation ?
• new OS65A format by @glitchwrks ? https://github.com/glitchwrks/SRecord/tree/os65a_work

Fix warnings from MegaLinter

Following @jtxa's wonderful additions of MegaLinter and other workflows, there are a bunch of warnings including on coding style as SRecord style doesn't fit in with the default which appears to be the Google C++ style guide. I'm starting to take a look at fixing some of these. I suspect others will also start chipping away at the list.

I figured listing work in progress here might save doubling up and treading on each other's toes. I'm also using it as a nice easy introduction to GitHub workflows for my own education.

If anyone wants to grab one of these sub-tasks, please note it

cpplint

• [whitespace/braces]. Likely going to suppress these or perhaps a subset of these. SRecord doesn't do hugging braces for example
• [build/include_order]. I like the reasoning behind this and might explore fixing these.
• [readability/casting]. Includes things like replacing c-style cast which would be a nice modernisation step.
• [runtime/int]. Not going to push back on platform independent fixed size types. We are literally manipulating bytes here!
• [runtime/*]: Most likely underlying issues that should be fixed.
• [build/header_guard]: Looks to be a style issue only. Likely to suppress the warning unless there is a concrete benefit
• [readability/namespace]: Might be a nice improvement. Considering to fix or supress
• [whitespace/newline, comma, parens, indent, etc]:To be fixed if it matches existing style
• [build/include_what_you_use] Definitely fix

build package for system

how to merge hex appoint address

i have 2 hex file，1.hex,2.hex(start address 0x8000)
now i want merge 2.hex to 1.hex to appoint address ,i use the command below

srec_cat 1.hex -Intel 2.hex -Intel -offset 0x7C0000 -o app.hex -Intel
it works ok，but the content of 2.hex start at 0x7C8000,i just want it start from 0x7C0000.
can you please tell me how to resove this?

All Git tags missing

Neither the repo on SF nor GitHub has any tags for releases.

Was this on purpose or did you simply forgot to push them?

Add Issue and PR templates

To create an easier workflow, it may be useful to use PR and issue templates.

Some examples:

• Feature
• Issue
• Question
• Pull Request

There are many more examples available on GH and elsewhere, linked are ones I've used in the past.

Fail in test t0260a.sh on msys2

The following test contributed by @marcows in PR from #6 runs perfectly on linux including github CI. Appears to fail under windows/msys2. No analysis yet.

$ ctest --rerun-failed --output-on-failure
Test project C:/msys64/home/scott/work/srecord-cmake/build
    Start 210: t0260a.sh: "random fill near end of address space"
1/1 Test #210: t0260a.sh: "random fill near end of address space" ...***Failed    0.69 sec
5c5
<         FFFFFFFF - FFFFFFFFFFFFFFFF
---
>         FFFFFFFF - FFFFFFFF
FAILED test of random fill near end of address space


0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.73 sec

The following tests FAILED:
        210 - t0260a.sh: "random fill near end of address space" (Failed)
Errors while running CTest

Floating point exception

System

Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy

Error

A divide by zero error can occur when providing rounding:

case token_round_down:
        token_next();
        multiple = get_number("-round-down");
        if(multiple == 0)
        {
            multiple = 1;
        }
        value /= multiple;
        value *= multiple;
        cout<<"HERE"<<endl;
        break;

    case token_round_up:
        token_next();
        multiple = get_number("-round-up");
        value = (value + multiple - 1) / multiple;
        value *= multiple;
        break;

    case token_round_nearest:
        token_next();
        multiple = get_number("-round-nearest");
        value = (value + multiple / 2) / multiple;
        value *= multiple;
        break;

When providing the following as input:

$ srec_cat test.in  -offset  - 1 -Round_Up 0

$ srec_cat test.in  -offset  - 1 -Round_Down 0

$ srec_cat test.in  -offset  - 1 -Round_Nearest 0

In each of the above cases, output will be

Floating point exception (core dumped)

Issue is due to line

multiple = get_number("-round-up");

which is not verified to be non zero. In each of the above cases, immediately following parsing 0, 0 will be used and cause an exception.

on linux , 'make install' also adds system libraries

vaguely related to #29 (cmake improvements).

Trying to package this for Archlinux, with default options cmake is bundling some systemwide libraries (libstdc, libgcrypt, libc, etc...) at the cmake --install step.

Does this have to do with the RUNTIME_DEPENDENCY_SET stuff in /etc/packaging.cmake ?

install_manifest.txt:

...
/usr/bin/srec_cat
/usr/bin/srec_cat
/usr/lib/ld-linux-x86-64.so.2
/usr/lib/libc.so.6
/usr/lib/libgcc_s.so.1
/usr/lib/libgcrypt.so.20
/usr/lib/libgcrypt.so.20.4.1
/usr/lib/libgpg-error.so.0
/usr/lib/libgpg-error.so.0.33.1
/usr/lib/libm.so.6
/usr/lib/libstdc++.so.6
/usr/lib/libstdc++.so.6.0.30
/usr/bin/srec_cmp
/usr/bin/srec_cmp
/usr/lib/ld-linux-x86-64.so.2
/usr/lib/libc.so.6
/usr/lib/libgcc_s.so.1
/usr/lib/libgcrypt.so.20
/usr/lib/libgcrypt.so.20.4.1
/usr/lib/libgpg-error.so.0
...

(interesting to note : lots of duplicates...)

Wrong srec_info output when using the last 32-bit address

srec_info prints the last 32-bit address wrongly in address range end.
This is a regression introduced between version 1.64 and 1.65.0.
Note: srec_info can generate data itself, but that would only work for this first case, it wouldn't show the misbehavior of the second case below.

srec_cat -generate 0xFFFFFFFF 0x100000000 -constant 0 -header "" -start-addr 0 | srec_info

Output is:

Format: Motorola S-Record
Execution Start Address: 00000000
Data:   FFFFFFFF - FFFFFFFFFFFFFFFF

Output should be:

Format: Motorola S-Record
Execution Start Address: 00000000
Data:   FFFFFFFF - FFFFFFFF

Additionally srec_info doesn't fill other data ranges up to 8 nibbles if the last 32-bit address is used.
This is not a regression, it was already the case with version 1.64.

srec_cat -generate 0x0 0x1 -constant 0 -generate 0xFFFFFFFF 0x100000000 -constant 0 -header "" -start-addr 0 | srec_info

Output is:

Format: Motorola S-Record
Execution Start Address: 00000000
Data:   0000 - 0000
        FFFFFFFF - FFFFFFFFFFFFFFFF

Output should be:

Format: Motorola S-Record
Execution Start Address: 00000000
Data:   00000000 - 00000000
        FFFFFFFF - FFFFFFFF

In the newly introduced verbose mode, the additional fields also can't cope with the last address.

srec_cat -generate 0x0 0x1 -constant 0 -generate 0xFFFFFFFF 0x100000000 -constant 0 -header "" -start-addr 0 | srec_info -verbose

Output is:

Format: Motorola S-Record
Execution Start Address: 00000000
Data:   0000 - 0000 (0001)
        FFFFFFFF - FFFFFFFFFFFFFFFF (FFFFFFFF00000001)
Filled: FFFFFFFF00000002
Allocated:   inf%   Holes:  -inf%

Output should be:

Format: Motorola S-Record
Execution Start Address: 00000000
Data:   00000000 - 00000000 (00000001)
        FFFFFFFF - FFFFFFFF (00000001)
Filled: 00000002
Allocated:  0.00%   Holes: 100.00%

Compare with the following command using the second to last address with the correct output already.

srec_cat -generate 0x0 0x1 -constant 0 -generate 0xFFFFFFFE 0xFFFFFFFF -constant 0 -header "" -start-addr 0 | srec_info -verbose

Format: Motorola S-Record
Execution Start Address: 00000000
Data:   00000000 - 00000000 (00000001)
        FFFFFFFE - FFFFFFFE (00000001)
Filled: 00000002
Allocated:  0.00%   Holes: 100.00%

add support for file format ELF (Executable and Linkable Format)

Hello,
I'm using this tool for years now, especially to add CRCs to hex files.

I work in embedded and arm-none-eabi-gcc which is one of the main compilers generated .elf files (also named .axf or .out depending on the MCU manufacturer). I think the format is this one : https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

It's more or less industry standard. Could you please add support to this format in srecord ? As of today, I'm using objcopy to work only on Intel Hex files but it's not ideal.
Maybe it's beyond the scope of srec_cat.

CI: Test report fails due to protections

After the workflow was accepted from PR #7 it only works fully for @sierrafoxtrot
The follow-up PRs from other people fail due to some protection problems:

Error: HttpError: Resource not accessible by integration

As @marcows pointed out here, this seems to be a common problem.

If I understand that correctly, it does only work for people having write access, which makes it more or less useless in this form.

Fletcher bug report

Bug report from Colen Garoutte-Carson back in December 31st, 2014 via email.

Hi. I was combing through the internet looking for some fletcher32 algorithms to compare my own against, for correctness. Surprisingly, this particular algorithm has a lot of bad versions out there.

Your fletcher32.cc in SRecord 1.64 appears to be close to correct, but a slight change has been made that breaks it, making it no longer the fletcher32 algoritm.

From your response to someone opening a bug on it(?) :

So the important thing to note is that data is read 8 bits at a time and then assembled into 16bit values before loading into the accumulators. The algorithm is otherwise uncanged.
<<<

Note that your implementation does not actually assemble 8-bit bytes into a 16-bit accumulator. It sums one 8-bit byte at a time, into the simple sum1 register. Because you adding only 8-bits at a time between rounds of sum2, you are getting a completely different value than someone who properly advanced 16-bits per round of sum2 (half as frequently).

Note the following line from the Wikipedia page:

sum2 += sum1 += *data++;

In their case, data is a uint16_t, so this reads 16-bits, and the increment advances 16-bits. To correctly handle 8-bit bytes, you would need to accumulate 2 at a time into a 16-bit integer (to be endian-safe) and pass that accumulator in place of "data++" to the above line. Instead, your equivalent code is:

    sum1 += *data++;
    sum2 += sum1;

In your case, data is a "const unsigned char*". Yet, the rest of the function is unchanged?(!?). So, functionally, your implementation is generating something very different from a fletcher32 result.

Note the smoking gun: You preserved the 360 constant. (If you initialize to 0xFFFF, you need 359 instead, Wikipedia has since been corrected. 360 assumes the sums are init'ed to zero). Since you are only adding an 8-bit value at a time, 360 is a completely irrelevant number. The number of rounds you would need to make before you could overflow a 32-bit (16x2) sum2, would be closer to 5802. Take a look at Adler32, which functions in a similar way to what you have created. Adler32 processes 8-bit bytes into a 32-bit result directly, mods by 65521, and overflows after 5552.

Fix groff/troff warnings during build

A number of groff/troff warnings/errors are thrown during the build. These need to be addressed.

Example(s):
[258/311] Building /home/sfinneran/wor.../srecord-cmake/build/doc/html/man/man1
troff: /home/sfinneran/work/srecord-cmake/doc/man1/srec_input.1:604: warning [p
1, 89.0i]: cannot adjust line
troff: /home/sfinneran/work/srecord-cmake/doc/man1/srec_input.1:604: warning [p
1, 89.2i]: cannot adjust line

[New format request] ASCII-art font rendering

The Hoard-of-fonts Project on Github is preserving fonts for classic computers. Their fonts are stored in an ASCII format which they call YAFF (yet another font format?) that is human- and machine-readable. Since srecord is the tool of choice for preserving and converting ROM images, supporting this format would be a great step for preserving and editing character generator files. It would be reasonable to assume that the rows are stored in consecutive addresses. A parameter could be provided that would indicate the number of columns and rows for writing, and these values could be inferred from the format on reading (and consistency check required for conversion). I am not aware of any character generator ROMs using more than 8 columns. But some of the fonts are for banners and use more than 8 columns. For these, there could be a switch to use consecutive bytes for more than 8 columns, or to split between multiple ROM images. Here is an abbreviated example of the format (DEC VT100 "A"):

# Comments are ignored on read, could be added on write 
# to include information about size, organization, etc.
# LATIN CAPITAL LETTER A

0x41:
    ........
    ...@....
    ..@.@...
    .@...@..
    @.....@.
    @@@@@@@.
    @.....@.
    @.....@.
    ........
    ........

Add git hash to documentation

Might be nice to have the git hash in the documentation.

v1.65.0:

$ cat LastTest.log 
Start testing: Dec 02 05:54 CST
----------------------------------------------------------
1/208 Testing: t0001a.sh: "basic srecord functionality"
1/208 Test: t0001a.sh: "basic srecord functionality"
Command: "/usr/bin/false" "/sw/build.build/srecord-1.65.0-1/srecord-1.65.0-Source/test/00/t0001a.sh"
Directory: /sw/build.build/srecord-1.65.0-1/srecord-1.65.0-Source/finkbuild/test
"t0001a.sh: "basic srecord functionality"" start time: Dec 02 05:54 CST
Output:
----------------------------------------------------------
<end of output>
Test time =   0.00 sec
----------------------------------------------------------
Test Failed.
"t0001a.sh: "basic srecord functionality"" end time: Dec 02 05:54 CST
"t0001a.sh: "basic srecord functionality"" time elapsed: 00:00:00
----------------------------------------------------------

Similar output for all other tests

[BUG] Broken links in documentation

Following man pages have a link to external resource which no longer works:

1. srec_aomf(5)
2. srec_binary(5)
3. srec_brecord(5)
4. srec_emon52(5)
5. srec_fpc(5)
6. srec_mos_tech(5)
7. srec_mif(5)
8. srec_signetics(5)
9. srec_ti_tagged(5)
10. srec_ti_tagged_16(5)
11. srec_wilson(5)

doc: Useless ref-index.so

The content of the generated ref-index.so is not used.
Even if it's empty, the PDF is identical: same size, same text content, just some bytes are different at the end, some of them being a unique identifier
This is a regression of version 1.65.

Found a small extra problem: the last content page in the PDF has number 1000. But this was introduced a long time age (I checked 1.50 and it was already there)

[BUG] Default constructor provided but header states should be deleted

Description

In file.h constructor for input_file() has the comment

  /**
    * The default constructor.  Do not use.
    */
  input_file();

In file.cc, an implementation is provided:

srecord::input_file::input_file() :
    file_name("standard input"),
    line_number(1),
    prev_was_newline(false),
    vfp(stdin),
    checksum(0),
    ignore_checksums(ignore_checksums_default)
{
}

Resolution

Two options to resolve issue:

Pre C++11

Remove the default constructor from file.cc

Post C++11

Remove the default constructor from file.cc

and change default constructor in file.h to:

  /**
    * The default constructor.  Do not use.
    */
  input_file() = delete;

If a default constructor is provided now, a compile error will occur.

[Format request]: C++ array

Call me crazy, but I program microcontrollers in C++.

To that end, while the C array is perfectly adequate, over the years the languages are diverging more and more. I propose adding a new output format, the C++ array.

The question is of specific output format, how it should be done.

My idea is to:

• support C++11 and newer - C++03 can just use the C array
• make a single output which is compatible with C++11, but utilizes newer features as appropriate

To that end, I believe the outline below to be appropriate. Although I would love for someone with a better grasp of the C++ standard to check if what I'm doing here with inline vs static is the right way.

#ifndef FOO_H
#define FOO_H

#ifndef SREC_CAT_QUALIFIER
    #ifdef __cpp_inline_variables
        #define SREC_CAT_QUALIFIER inline
    #else
        #define SREC_CAT_QUALIFIER static
    #endif
#endif

SREC_CAT_QUALIFIER constexpr std::array<uint8_t, LENGTH_HERE> foo = {
    // data goes here, the same as in the C array
};

SREC_CAT_QUALIFIER constexpr size_t foo_termination = 0x00;
SREC_CAT_QUALIFIER constexpr size_t foo_start       = 0x00;
SREC_CAT_QUALIFIER constexpr size_t foo_finish      = 0x00;

#endif // FOO_H

More on the inline keyword: cppreference.com notes:

Because the meaning of the keyword inline for functions came to mean "multiple definitions are permitted" rather than "inlining is preferred", that meaning was extended to variables.

If my understanding is correct, inline will result in more of a guarantee that the array will not be duplicated in the resulting program/library.

CMake: improvements and formatting

Discussion about possible improvements

• local configurations: move all doxygen things into 1 file, move config headers to library
• Make doyxgen optional (and depending if tools found)
• Make website optional (and depending if tools found)
• Make PDF optional (and depending if tools found)
• Make documentation optional (and depending on tools found)
• Make LIB_GCRYPT fully optional (library linkage, test selection)
• With optional documentation it should be possible to build srecord on any C++11 aware system (even native Visual Studio)
• With optional documentation less tools needs to be loaded in some Workflows
• project name: SRecord, use SRecord as prefix for global things (either SRecord_ or SRecord::)
• Naming of lib target: srecord (lib prefix is added by CMake)
• Introduce Aliases: SRecord::srecord, SRecord::srec_cat, SRecord::srec_cmp, SRecord::srec_info
• Build srecord library STATIC or DYNAMIC (introduce cache var SRecord_BUILD_SHARED_LIBS, default defined by BUILD_SHARED_LIBS)
• choose the right package format (DEP/RPM) by default
• generate official binaries to bin/ in build dir (there's a variable to control that)
• avoid include_directories, use target_include_directories
• explicit filelists
• Introduce toolchains used in Workflows and for developers
• Introduce profiles used in Workflows and usable for developers

Tooling

There is some tooling: cmake language tools
interesting tools contained: lint, format

Haven't used it myself yet, don't know how widely used and mature it is.
Don't know what the formatter can do.

Discussion about format

Indentation

# now (sometimes):
add_doc(abc
        def)
# suggested:
add_doc(abc
    def)

rationale: No manual extra formatting of single spaces. Less effort to write.

closing parentheses

# now (sometimes):
add_doc(abc
    def)
# suggested:
add_doc(abc
    def
)
# alternative:
add_doc(abc
    def
    )

rationale: Better visibility where it ends. Easily insert something at the end, without extra care for parentheses.

multi-line function calls

# now (breaking at max width):
add_library(tgt KEY1 KEY2 value KEY3 value
    KEY4 KEY5 value KEY6 value)
# suggested (new line for every argument):
add_library(tgt # just the positionals, or most important on first line
    KEY1
    KEY2 value
    KEY3 value
    KEY4
    KEY5 value
    KEY6 value
)

rationale: readability, avoids merge conflicts

file lists (for multi-line function calls)

# now
add_custom_target(tgt
    DEPENDS file1 file2 file3)
# suggested:
add_custom_target(tgt
    DEPENDS
        file1
        file2
        file3
)
# alternative:
add_custom_target(tgt
    DEPENDS
    file1
    file2
    file3
)

rationale: readability, avoids merge conflicts

This could also be applied to COMMAND and others.
For file lists with more than 1 file I would always do this, for other things I can't say this in general.
I do an extra indent for values, don't know if the formatter can do such things.

Ideas to consider when writing CMake files

Just apply if really help in readability, not in general.

strings quotation marks

# example:
set(var ${a} ${b}_${a} ${b}${a} ${b}.${a})
# may be more readable
set(var "${a}" "${b}_${a}" "${b}${a}" "${b}.${a}")

rationale: readability (only with syntax coloring), easier to identify a single value

strings bracket argument

# example:
set(CPACK_SOURCE_IGNORE_FILES
  /\\.git/
  \\.gitignore
  \\.swp ...
# no extra quoting needed:
set(CPACK_SOURCE_IGNORE_FILES
  [[/\.git/]]
  [[\.gitignore]]
  [[\.swp]] ...

rationale: avoid extra backslashes, e.g. in RegEx
drawback: inside bracket argument variables are not expanded (not relevant here)

General discussion about GitHub Workflows

This is a list of potential things to do in the workflow.
Attention: this message may be updated based on discussions and implemented PRs.

CI (Continuous Integration)

systems

• new linux (see #7)
• old linux (maybe via docker, e.g. centos)
• windows: msbuild with VC++
• windows: ninja with VC++
• windows: ninja with MinGW
• windows: msys2 (see #24)
• windows: cygwin
• macos (see #24)
• select which compiler shall be used on which machine/os

jobs/steps

• simple build one linux with gcc & clang, run tests (see #7)
• build docs (see #7)
• #9
• install package
• test installed executables
• docs (see #7)

CD (Continuous Delivery)

• build all release packages
• build PDF
• build doxygen
• build web-site
• publish web-site
• publish release packages
• publish to Ubuntu ppa and alike

QA (Quality assurance)

Different build with special settings

• with fixed language version (see #24)
• with coverage

Possible checks with MegaLinter

• *.sh: shellcheck, shfmt (see #19)
• *.css: stylelint (only generated css exist)
• *.html: djlint and/or htmllint
• *.md: markdownlint, markdown-link-check and/or markdown-table-formatter (see #19)
• *.yml: yamllint and/or v8r (see #19)
• prettier (formatting of yml, md) (see #19)
• editorconfig-checker (see #19)
• cspell (see #19)

Static code analyzers

• clang-tidy (see #24)
• clang-format
• IWYU
• LWYU
• cpplint (see #19)
• Cppcheck
• CodeQL
• scan-build

maybe done with the help of CodeChecker

more may be found here or here

Statistics

• scc
• Code Coverage, e.g. with gcovr

Dependabot

• Dependabot
  may be useful for being up-to-date on the github actions used in workflows.