I'm not asking for MicroPython to "support more build systems"--at all. That would actually defeat the purpose that I'm trying to attain here ;-).

Sorry I phrased that poorly. What I meant was that having people add support for additional build systems (in your case, SCons) is likely a difficult task, and it would be better if we made it easier to use the "official" (make-based) mechanism used in the MicroPython build from third-party systems.

How the QSTR Python scripts are actually utilized...not "oh, the output of this Python script goes into that Python script, which does this, and then goes into that Python script (like the qstr.htm doc).

One thing that might help you is to run make V=1 on one of the existing ports, which will print out the command line for each command.

e.g.

cd ports/stm32
make BOARD=PYBV11 V=1 build-PYBV11/genhdr/qstrdefs.generated.h

which will show the steps up to the completion of the QSTR generation.

Have you seen https://docs.micropython.org/en/latest/develop/qstr.html which at least provides a high-level overview of the steps involved in QSTR generation (might help you understand the makefiles).

Realistically though, supporting this process across more build systems (we also do cmake, which is also a hassle) isn't really scalable. The same is true for IDE build systems (e.g. STM32 Cube IDE) and lots of others.

Instead I think the better approach is to build MicroPython using the existing make system, and then integrate the output of that into your build system.

See #9529 for the first step towards this -- the idea eventually is that you run the MicroPython build on micropython itself as well as your bindings, and the the output of this can just be included as .c (and .h) files into your SCons or whatever.

#9529 is not based around generating QSTRdefs, but appears to be more of a means to compile and embed Python scripts into the actual MicroPython build.

I've tried getting the QSTRdefs generated in the MicroPython UNIX build and then copying the generated files over--but of course this is an exercise in exasperation due to the (necessary) MicroPython library differences in MPY UNIX port vs the RT-Thread port. For the most part it works--but then starts failing on every single difference where MPY UNIX doesn't have a particular library that RT-Thread does.
at the moment, that's:

• "mpirq.c"...took several hours to finally get that one in MPY UNIX. Turns out the QSTRdefs generators are terrible at identifying project changes. As a last resort, I deleted the entire "build-standard" folder, and poof MPY UNIX mysteriously compiled without errors (it would fail due to missing QSTRdefs in "mpirq.c" which I'd added to the build list, because the QSTRdefs generators were failing to recognize the changes). Oh, and the resulting "qstrdefs.generated.h" file was all of 520 bytes bigger...neatly adding on the 3-4 QSTRs for "mpirq.c". Copied "qstrdefs.generated.h" over to RT-Thread, and it was compiling well until it hit...
• "machine_pin.c". This one's a real doozy of a problem, because it's highly dependent on the platform MPY is being built on. Looking through the MPY ports, this file ranges from 12kb to 25kb depending on the port. And I can pretty well guarantee that that's going to result in different QSTRdef requirements. Oh, and did I mention that of the MPY ports utilizing "machine_pin.c"...NONE of them utilize "mpirq.c"? That's just 2 files...there's almost unquestionably more.

#5964 is not much help either, as it has to do with "adding an external library" to MicroPython, "adding in" a minimal QSTRdef file for the external library alone. Like #9259, it also does not generate project-level QSTRdefs.

NONE of them utilize "mpirq.c"?

That's not true. Quite a few ports use mpirq.c, like stm32, renesas-ra, mimxrt, rp2, c3200, samd, and zephyr.

That's not what I wrote: of the ports utilizing "machine_pin.c" NONE of those also utilize "mpirq.c". From what I could find anyway.

At least in the MicroPython ("lv_micropython") I'm trying to work with, the ONLY port that has "mpirq.c" in the port folder, is c3200. (It's possible that others might pull it from the "shared/runtime" folder.) Eight ports have "machine_pin.c", but c3200 is not one of them.

It's possible that others might pull it from the "shared/runtime" folder.

That's where it is. Instead of having copies of the same file in every port folder, the aim is to have the same file for the same task and keep it at a single place.

Think I answered my own questions...and yes, there's no reason why this hugely overcomplicated routine can't be broken down into a VERY simple process.......

"QDEF0" is simply built-in QSTRs that are autogenerated regardless of the source (at least for MicroPython 1.19; in 1.13, there are only ever "QDEF" entries, no number.)
"QDEF1" is everything else found in the source files.

Here's the routine in "makeqstrdata.py" that does the final outputting:

def print_qstr_data(qstrs):
    # print out the starter of the generated C header file
    print("// This file was automatically generated by makeqstrdata.py")
    print("")

    # add NULL qstr with no hash or data
    print('QDEF0(MP_QSTRnull, 0, 0, "")')

    # split qstr values into two pools. static consts first.
    q0_values = [q for q in qstrs.values() if q.order < 0]
    q1_values = [q for q in qstrs.values() if q.order >= 0]

    # go through each qstr in pool 0 and print it out. pool0 has special sort.
    for q in sorted(q0_values, key=lambda x: x.order):
        print('QDEF0(MP_QSTR_%s, %d, %d, "%s")' % (q.ident, q.qhash, q.qlen, q.qdata))

    # go through each qstr in pool 1 and print it out. pool1 is regularly sorted.
    for q in sorted(q1_values, key=lambda x: (x.qhash, x.qlen)):
        print('QDEF1(MP_QSTR_%s, %d, %d, "%s")' % (q.ident, q.qhash, q.qlen, q.qdata))

Second argument? "q.qhash"

That's a class function of the qstr class, which is defined as follows:

@property
    def qhash(self):
        return compute_hash(self.qbytes, Qstr.cfg_bytes_hash)

And "compute_hash" is this little routine:

def compute_hash(qstr, bytes_hash):
    hash = 5381
    for b in qstr:
        hash = (hash * 33) ^ b
    # Make sure that valid hash is never zero, zero means "hash not computed"
    return (hash & ((1 << (8 * bytes_hash)) - 1)) or 1

So there is absolutely zero use for the 135MB "qstr.i.last" file...that is, if we don't care about compile-time configuration to include/remove various MicroPython libraries.

"Q.ident" is simply an escaping method to make valid C code out of symbols...that's easy. ("ident = qstr_escape(qstr)")

def qstr_escape(qst):
    def esc_char(m):
        c = ord(m.group(0))
        try:
            name = codepoint2name[c]
        except KeyError:
            name = "0x%02x" % c
        return "_" + name + "_"

    return re.sub(r"[^A-Za-z0-9_]", esc_char, qst)

.............I'm eating this snake one byte at a time. And maybe making the MPY world a bit better for other hapless humans like myself who almost got eaten alive and gave up ;-)

OK so I realized something , I work in a baremetal environment so a lot of POSIX commands , commands that triggers linux functions will act erroneously.. So the assert function tried calling a higher mode . It resulted in a ECALL from Mmode in my chip (It makes no sense as its already in the highest priority.) Had to change the assert statements in qstr.c ,now it works ..