When building libcar for Windows, the array size calculation would be of type
`unsigned long long` (aka `size_t`). However, `identifier` is of type
`enum car_attribute_identifier` (aka `int`). This results in a warning due to
the sign mismatch. Perform an explicit cast to the size type for the
comparision to silence the warning.
Take the opportunity to move the constant expression of the array length into a
variable for ease of readability.
- When new indices are added to a BOM, the extra spaces are now zero'd out instead of left as
junk memory. The space after the index table seems to be hidden metadata about a freelist, so
having this data randomized is not good.
- Add support for inserting freelist data at the end of the index table.
- Sorted entries added to a BOM tree, which appears expected by apps searching through BOM trees.
These functions are now deprecated, but using the new infrastructure
makes everything more consistent. This is also sufficient for path
support on Windows, even before adopting the strongly typed paths.
There are two types, one to represent any kind of path, and one
that always represents a full absolute path. Conversion between
them is checked to ensure consistency.
The path types are templated on traits, which implement platform-
specific path behavior. They default to the appropriate traits
for the current platform, but are customizable as required. The
path format consists of three parts: a root, of which there can
be one (Unix) or many (Windows), and a path, which is separated
by path separators.
Separate from the process as it is only vaguely related and adding
unused user information to in-memory process contexts was extra code.
Windows support uses the SID as the user ID, as it matches the idea
of an identifer uniquely identifying a user or a group.
Windows is simpler than Unix in that it doesn't require fork just
just to set a working directory; it's more complex in that arguments
must be manually quoted rather than passed as an array.
- Set to use static or dynamic libraries at top level.
- Compiler configuration for MSVC and MinGW.
- Copy rather than create symlink for aliases on Windows.
Current implementation encodes auxiliary files into base64 string,
and pass it through system's base64 decoding to recreate files on
ninja build process.
This has two main disadvantages,
1. When auxiliary files are large, invocation call will expand
very large and shell will reject executing them.
2. base64 may not be compatible. (e.g. xcbuild's base64 encoded
data is not properly decoded by linux's base64 utility)
Instead, after build.ninja file has been written, also write
auxiliary file chunks in temporary directory with its hash included
in its filename. Ninja caches hashes of its execution command to determine
changes to the rule, so the actual rebuild logic is unchanged.
Sometime, xcbuild will be symlinked to different location.
If the xcbuild is symlinked, try to resolve symlinks and
and find relevent builtin tools in symlink source directory.
