Oliver Schmidt [Tue, 7 May 2013 15:58:56 +0000 (17:58 +0200)]
Removed reference to CC65_HOME.
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.
Oliver Schmidt [Mon, 6 May 2013 22:47:37 +0000 (00:47 +0200)]
Have cl65 run the binaries from its own directory.
While ca65, cc65 and ld65 have built-in paths cl65 doesn't.
That means that up to now cl65 depended on the binaries
being found in the path env var. However it makes sense
to presume that the binaries are located in the very same
directory cl65 is located in. So whatever pathname was
suitable to run cl65 should be suitable to run the other
binaries too. But if for some reason there's no valid
argv[0] or if it doesn't contain at least one directory
delimiter ('/' or '\') then fall back to relying on the
path env var.
Oliver Schmidt [Mon, 6 May 2013 21:20:56 +0000 (23:20 +0200)]
Added search path relative to running binary on Windows.
In contrast to *IX it doesn't make much sense to add compile time defined
search paths to Windows binaries: There's no standard path like /usr/local/bin
(and there are no symbolic links to link from there to another location).
On the other hand it's (again in contrast to *IX) easy for Windows binaries
to determine their own paths. Therefore it's appropriate to make use of that
to add run time defined default search paths.
Oliver Schmidt [Sat, 4 May 2013 20:15:30 +0000 (22:15 +0200)]
Replaced whole bunch for Makefiles with a single generic Makefile.
- 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'.
Oliver Schmidt [Sat, 4 May 2013 20:10:48 +0000 (22:10 +0200)]
Replaced whole bunch for Makefiles with a single generic Makefile.
- 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'.
Oliver Schmidt [Sun, 28 Apr 2013 20:30:18 +0000 (22:30 +0200)]
Replaced elaborate install logic with just a bunch of symlinks.
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.
Oliver Schmidt [Fri, 26 Apr 2013 19:54:54 +0000 (21:54 +0200)]
In general "\%s" doesn't seem to be a valid printf format specifier. Given where it originally came from and how OneLine() is used elsewhere I'm pretty sure that it should rather read "%s".
Greg King [Mon, 22 Apr 2013 19:55:52 +0000 (15:55 -0400)]
Stopped interrupt dispatcher from being linked even when there are no interruptors.
Put ld65's CONDES import names into object module's list instead of linker's list.
ol.sc [Thu, 14 Feb 2013 16:48:05 +0000 (16:48 +0000)]
Save some bytes by sharing the code doing the actual vector setting. Note: Jumping from segemnt INIT to segment CODE is okay while the other way wouldn't be.
ol.sc [Tue, 12 Feb 2013 22:39:38 +0000 (22:39 +0000)]
Moved IRQ hooking / unhooking from startup code to constructor / destructor to avoid linking in the hooking / unhooking code (and callirq) for the majority of cc65 prorams not linking in interruptors.
uz [Tue, 12 Feb 2013 19:51:11 +0000 (19:51 +0000)]
Quick fix for a problem in the OptLoad3 function. The fix isn't perfect and
may fail for inline assembly code, but at least it's less buggy than before.
uz [Sun, 10 Feb 2013 20:56:13 +0000 (20:56 +0000)]
Fixed several issues where an object file reference or line infos were
accessed when they in fact didn't exist, because the symbol was linker
generated (in the config or on the command line).
Fixed a problem: When a struct or unit was declared with a tag name, it was
possible to use the opposite type with the tag name. That is "struct a" after
declaring "union a" and vice versa.
projects / cc65 / log