This macro hid away the arguments to the underlying call, and served
no purpose beyond saving the programmer some typing. This is 2019,
people have IDEs (even Vim!) with autocompletion.
That folder contains external code, and modifying it to conform to our
code style would make applying upstream patches, amongst others,
problematic. Therefore, skip checking it.
Ideally, the folder should also be excluded from `make checkpatch`,
but I haven't figured out a way to do that yet.
Since the RGBLINK rewrite, there have been no .l files in the whole codebase
(RGBASM has the C file directly, for better and for worse)
Since flex isn't used anymore, it's a good idea to remove it from the Makefile
so people don't think it's a dependency.
Those are only useful for locking file IO across threads, but RGBLINK is
single-threaded anyways, so they don't matter. Plus, they aren't provided by
mingw, so that'll remove part of the problem
The error was due to casting `const` away for permuting argv
elements, which is necessary for a libc for compatibility with older
systems, but not for us.
Checkpatch will complain about the style not being followed, but this is not
our code, so it can be ignored.
Both `getopt_long` and `getopt_long_only` are GNU-specific, so we'll be
copying musl's implementation for portability.
This was retrieved as of commit 90251cf73dfdd44e7a3f085d236e89a7dff1b00b.
musl is licensed as MIT, which is compatible (being identical...) to RGBDS'.
The file is being copied as-is, without a copyright notice or attribution,
but this is only to have a verbatim copy in the history. Those will be added
in the next commit.
The goal was to improve readability, but along the way a few things were
gained.
- Sorted sym and map files
- Infrastructure for supporting multiple .o versions
- Valgrind-proof, as far as my testing goes anyways
- Improved verbosity messages
- Added error checking
- Performance improvements, see end of commit message
The readability improvement was spurred while trying to make sense of the
old code while trying to implement features such as sorted sym and map
files.
I also did my best to remove hardcoded logic, such that modifications
should be doable; for example, "RAM loading" sections, which are linked
against a different location than the one they're stored at.
Some work remains to be done, see the "TODO:" and "FIXME:" comments.
Further, while regression tests pass, this new linker should be tested on
different codebases (ideally while instrumented with `make develop` and
under valgrind).
The few errors spotted in the man pages (alignment) need to be corrected.
Finally, documentation comments need to be written, I have written a lot of
them but not all.
This also provides a significant performance boost (benchmarked with a
51994-symbol project):
Current master RGBLINK:
2.02user 0.03system 0:02.06elapsed 99%CPU (0avgtext+0avgdata 84336maxresident)k
0inputs+11584outputs (0major+20729minor)pagefaults 0swaps
Rewritten RGBLINK:
0.19user 0.06system 0:00.63elapsed 40%CPU (0avgtext+0avgdata 32460maxresident)k
23784inputs+11576outputs (0major+7672minor)pagefaults 0swaps
The stdlib functions specify the difference between `err` and `errx`
is that the former prints a message obtained with `strerror`.
However, RGBDS' implementation breaks that contract, and `warn`'s puts the
added semicolon in the wrong place.
This is especially useful when an EQUS expands to another one, to help
track them.
This is done separately from the file stack as the EQUS stack is separate
(which is itself because EQUS are managed *way* differently).
They do not take any room, so they can only be used to define symbols at
a given location. I ran into trouble with such a SECTION failing to be
placed where specified, which doesn't make sense.
This way, it also makes sense to have such a SECTION in the middle of
another one, but that should be fine, since there's no actual overlap.
f29d768 forgot to switch these two `expr->nVal` to `src1->nVal`
This won't break anything, since this wasn't published yet.
I checked, and didn't see any other missed changes.
Reported by pret, I confirmed that `1 && 1` evaluated to 0.
Eldred Habert