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.
Kym Greenshields <kym.greenshields@gmail.com> has expressed interest
in contributing and maintaining support for the VTech CreatiVision system.
this resembles commit 8e6b8dd0af from oliver
Most POSIX function libraries hid that long-time bug by putting zeroes in their dynamic RAM; but, MinGW's library doesn't do it. Therefore, a command like
cl65 foo.c -l
would crash with a "Segmentation fault" -- it should give a nice error message about "-l"; and, quit neatly.
