until now, the strings intended to be hardcoded into the binary,
such as directory names and build id, were passed unquoted, which
means they're interpreted by the preprocessor as C tokens, rather
than strings, which can result in all sorts of "interesting"
behaviour such as interpreting paths starting with // as C++-style
comment.
this was then worked around using a stringize macro which turned
the tokens into a string (if they happened to be in a compatible
format).
adresses #1726
src/common/inttypes.h is a shim to fix building cc65 on
non-C99-compliant compilers missing inttypes.h (like VS2012 and
earlier). The shim is actually incomplete and does not define the PRI...
macros supplied by the actual compiler headers. Since we're planning to
use those macros, delete this header so cc65's source files instead use
host-supplied inttypes.h containing macro definitions.
New commands:
.PUSHCHARMAP: will push the current charmap state into an internal stack
.POPCHARMAP: will restore the current charmap to the last pushed charmap
Details:
The push and pop facilities are implemented directly inside the tgttrans.h,
to facilitate its reuse on the C compiler.
I placed the Git tag V2.19 in hindsight at 555282497c. But I certainly don't want to rewrite the Git history just for the reported version, so I simply set the reported version at today's HEAD to 2.19.
When compiling cc65, it will by default place the git hash (if available) of
the checked out commit in the version string. This isn't useful when building
a package for a Linux distribution, since there either won't be an upstream
git hash if there is one at all.
Thus we replace GIT_SHA with a more versatile BUILD_ID, which can be defined
to any arbitrary string. When building, its contents will be appended to the
version string instead of the git hash.
If BUILD_ID is not defined by the user the behaviour will be exactly the same
as before. That means BUILD_ID gets automatically defined to Git <GIT_SHA>,
if it can be determined from a checkout.
Although the primary target OS for the Apple II for sure isn't DOS 3.3 but ProDOS 8 the Apple II binary files contained a DOS 3.3 4-byte header. Recently I was made aware of the AppleSingle file format. That format is a much better way to transport Apple II meta data from the cc65 toolchain to the ProDOS 8 file system. Therefore I asked AppleCommander to support the AppleSingle file format. Now that there's an AppleCommander BETA with AppleSingle support it's the right time for this change.
I bumped version to 2.17 because of this from the perspective of Apple II users of course incompatible change.
The change allows cc65 to be compiled on 64-bit Windows, without getting warnings. That OS is actually 32 bits with 64-bit pointers. Its pointers are "long long" instead of "long". The change uses type-names that are configured for the actual pointer width.
If cc65 is installed and used as designed there's no need whatsoever for CC65_HOME (both on *IX and Windows) from the perspective of the cc65 binaries. If the user however has to access files from the 'target' directory thenhe ends up with some assumption on the cc65 installation path nevertheless :-(
In order to avoid this I added the --print-target-path option. It "exports" the logic used by the cc65 binaries to locate their files to the user thus allowing him to leverage the same logic to locate the target files in his build scripts / Makefiles.
