Use `ifeq` to provide two rules for the `avail` target: one that reports
an error if any of the symlink targets are missing and one that installs
the symlinks for the targets if they're all present.
there was some concern that this will break windows' way of doing
file lookups relatively from the binary, rather than via hardcoded
locations, but so far each occurence adding e.g. "CA65_INC" to
the pathsearch is already shielded with an #ifndef _WIN32.
addressing #1726
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
it's often required to see the full commandline when things go wrong.
the standard way for Makefile-only based buildsystems and autoconf
is to pass V=1 to make.
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.
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.
- Force usage of shell wrapper in order to allow to suppress potential message about git not found (thanks to Greg King).
- Do $(info GIT_SHA ...) only if there's something special - as done with the other $(info ...).
After all it seems much cleaner to explicitly control the behaviour from the .travis.yml file than to behave differently "under the hood" when detecting a Travis CI build.
I must admit that I don't understand why but obviously it is necessary to place .PHONY below the definition of variables it refers to - although those variables are recursively expanded ones! Not doing so made libsrc/Makefile build only three target libraries.
Actually there's no need to fiddle with any automatic temp file name generation as we can just modify the library path name to generate a perfect temporary library path name.
There's no need to intentionally break things for people trying to build cc65 with some obscure compiler. It's enough to make sure that no new warnings sneak into the code base by having Travis CI builds fail.
The 'install' target primarily aims to support pacaking tools. Therefore...
- It just presumes a "capable" install program to be present.
- There's intentionally no 'uninstall' target.
If the variable 'prefix' is defined then the builtin search paths are set to
$(prefix)/lib/cc65/... allowing to build binaries intended for installation.
Note that the library build still works with these binaries as it generally
overrides the builtin search paths by setting the CC65_HOME env var.
The sim65 source code has been a construction site for over a decade.
I was looking for a simple cc65 program execution environment for
regression tests. So I decided to re-purpose sim65 for that task by
removing about everything but the 6502 emulation.
There's no memory mapped i/o emulation whatsoever. Rather exit(),
open(), close(), read() and write() calls are supported by mapping
them through a thin paravirtualization layer to the corresponding
host os functions.
Note: The sim65 6502 emulation provides means to switch between
6502 and 65C02 emulation but currently there are no actual 65C02
opcodes implemented.
There are two reasons for removing this dependency:
- If someone does 'make avail' on the top level Makefile he ends up with
binaries but without libraries - not nice. Better do just "nothing" and
have hin understand that he needs to do 'make [all]' on the top level
Makfile first.
- If 'make avail' is done via 'sudo' it isn't desirable to do a large amount
of work as root.
BTW: I wasn't sure if this dependency is a good thing in the first place
but I saw it in many examples ('install' depending on 'all') so I did it too.
The [un]install make goals have a rather fixed meaning for *ix users. The simple
symlinks provided here don't match the expectations users have from [un]install.
Therefore it is appropriate to rename them to "something" not tied to specific
expectations.
Maybe I'm naive but even after thinking about it for quite
some time I can't see why it should hurt to just build the
cc65 binaries from the sources "in place" and have 'make
install' simply create some symlinks in usr/local/bin.
The new Makfile builds the binaries with builtin search paths
matching their build location. So the symlinks in usr/local/bin
allow to allow to use them out-of-the-box without additional
environment variables.
compyx
rofl0r
Greg King
Björn Esser
existensialMemory
Oliver Schmidt
Stefan
Pascal de Bruijn
Christian Groessler