The libraries build is prepared to work with binaries not part of the current
working tree. But in this case the default search path surely points to some
other working tree. Even the binaries in this working tree might have been
compiled with non-standard builtin search paths.
Anyway when building the libraries we want always to use the headers from
the current working tree. Therefore we want to set them explicitly. Instead
of setting all in all five paths on the command lines of ca65, cc65 and ld65 I
opted to just set the single environment variable.
The target 'atarixl' is to be used for Atari XL (and better) machines.
It will disable the OS ROM and enable the Shadow RAM available on
those machine.
Note: This commit is only the inital step towards for this goal that just
replicates the target 'atari' as a starting point!
The targets allow to run cc65 programs in the sim65 exection
einvironment. As there are no "real" i/o facilities there's no
need for header files. Paravirtualized entry points are mapped
to $FFF0 ff. There's a large cc65 progam area from $0200-$FFEF.
The binary format includes a one-byte header indicating the required
execution environment: The value 0 means 6502 and the value 1
means 65C02. The load adress for the binary is fixed to $0200.
Note: Running sim65C02 programs currently doesn't work bcause
sim65 doesn't actually implement 65C02 opcodes.
There's a quite special case of a targetutil for the TARGET geos-apple having to be
built as TARGET apple2enh binary. We can't just add a dependency to ../lib/apple2enhlib
because the TARGETs are built in individual make instances (because of vpath).
Doing that the "right way" would be _very_ complicated and would turn the Makefiles way
less readable. Therefore I decided to solve that by just reordering the TARGETs. Surely
this won't work if i.e. 'make geos-apple' is entered on a clean system. But still I consider
it appropriate.
I ordered the TARGETs btw so that they are more in an alphabetical order...
Now that we're pretty much independent from CC65_HOME
it doesn't make sense anymore to look for it in the Makefiles.
So rather dynamically check if there are "local" binaries in the
../bin directory. If there are "local" binaries use them - and
otherwise rely on "installed" binaries found in the path.
- No complex shell logic.
- "Source file shadowing" for all targets via vpath.
- Dependency handling.
- True incremental build.
- Don't write into source directories.
- Easy cleanup by just removing 'wrk'.
Now the whole GEOSLib is built in a single make instance running in 'libsrc/geos-cbm' - which is just what the cc65 library build system can handle. The 'libsrc/geos-cbm' sub-directories still contain Makefiles. However those files only define the set of object files to create from their sub-directory and get included into the 'libsrc/geos-cbm' Makefile.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5429 b7a2c559-68d2-44c3-8de9-860c34a00d81
These two patches speed up library building:
Do the "runtime" directory before doing the platform directory, because
platform drivers need a file from the runtime directory (the old code
ran "runtime/Makefile" three times for each target!!!).
Clean only the shared directories -- the target directories don't need
cleaning.
Changes by Greg King.
git-svn-id: svn://svn.cc65.org/cc65/trunk@5019 b7a2c559-68d2-44c3-8de9-860c34a00d81
main() is encountered. Define this symbol in the startup code. This will
automatically force linking of the startup code which can then reside inside
the standard library as any other object file.
git-svn-id: svn://svn.cc65.org/cc65/trunk@3988 b7a2c559-68d2-44c3-8de9-860c34a00d81
