Had a real yak shave this morning with disabling assertions in release
builds in our C/C++ code. It turns out that our unit tests use
`assert()` which we intended to use from `test_assert.h`, but in some
cases `cassert` or `assert.h` had been #included after `test_assert.h`,
overriding our special `assert()` macro. The chain of includes is
somewhat hard to puzzle out -- it's often buried several levels deep.
This meant that a release build would drop all test assertions, meaning
most tests passed, unsurprisingly, as there were no assertions left to
fail ... but some tests failed with crashes because we optimized out
important lines such as `assert(some_important_function())`.
I was quite unhappy with this fragility, so I have opted to rename
`assert()` to `test_assert()` in all of our home-grown C/C++ unit tests,
which further highlighted unit tests which were only using the C/C++
`assert()` and not ours, so then had to figure out which unit test
executables needed to have `test_assert` added, and then ... then ...
discovered a bug in `test_color.h`, where we were #including
`io.h`/`unistd.h` inside a `namespace console_color {}` block, which
just happened to be the first ref to those beautiful headers, and thus
(because `#pragma once`) meant that useful little functions like
`access()` were no longer accessible to us in the global namespace.
I have also audited Every Single Call to `assert()` to verify that we do
not do Important Work inside the parentheses, and, apart from those
offending unit tests, now resolved with `test_assert()`, it looks like
all is good.
I would like to present one very well-shaved yak in this commit.
Fixes: #12619
Moves variable declaration for `bool enabled` from .h to .cpp and fixes
up builds. Fixes `#include` in ldml_test_source.cpp which was inside a
namespace.
Fixes: #10426
feat(mac): include km_types and u16
feat(mac): include filesystem and some kmx
feat(mac): include old functions in keymap
feat(mac): include kmx_file, mc_kmxfile
feat(mac): include deadkey, filesystem, km_types, import_rules,mc_kmxfile
feat(mac): include functions in mcompile.cpp/h
feat(mac): #includes out to be used
Note: there is a bit of potential confusion about the difference between
/resources/builder.inc.sh (the full implementation for builder scripts),
and /resources/build/builder.inc.sh (the source script that builder
scripts should always use).
This allows us to make assumptions that will always be true for builder
scripts that may not be true for other scripts, such as setting base
folder.
Fixes#11324.
* Always `cd "$THIS_SCRIPT_PATH"`
* Remove unnecessary `cd` from all build.sh
* Remove unnecessary `set -eu` from all build.sh (and `# set -x`)
* Replace old build-utils.sh incantation in a few build.sh scripts
Fixes#9541.
Also adds version 16.0 support to the kmcmplib compiler constants, and
unit tests for both versions. Does not add any support for automatic
version feature detection, because that forces an inverted dependency on
the touch layout compilation phase (done in kmc-kmw), which would be a
significant refactor. This may be something we need to support in the
future.
When we read .kmx files, they have no alignment guarantees, so we need
to tell the compiler to generate unaligned-safe code for accesses to
`COMP_` structure members, because typically we point into the buffer
and read at any offset.
A .kmx file will generally be 2-byte aligned, as there are no structures
or data types with smaller than 2 byte widths. There is no requirement
that this be the case per the .kmx spec, though. So we use a 1 byte
alignment attribute for the compiler, so it will generate safe code when
reading these structs.
Note that we are assuming that `COMP_KEYBOARD` is aligned because it is
always the start of the file, so will be at the start of any buffer
which will automatically be aligned correctly.
We should probably review some of our design decisions and structs for
KMXPlus given this.
The &displayMap system store adds support for a mapping file that remaps
the On Screen Keyboard files -- .kvks and .keyman-touch-layout, at
compile time, to new ranges. This is specifically intended to resolve a
limitation of unattached marks and diacritics which display
inconsistently across platforms; this is described in more detail in
issue #9031.
In order to allow us to reference the padding in the FILE_KEY structure,
for reproducible and cross-platform consistent builds, turn the padding
into an `_reserved` (must always be zero) field.
Changes to compiler to utilise this will be in a follow-up commit.
