since the "empty prefix means run from current dir" hack was removed,
cl65 --print-target-path no longer prints the path relative to the
binary, but the hardcoded library path which points to prefix, because
the code adds the hardcoded path first to the pathsearch, but then actually
only returns the first entry rather than looking whether the path exists.
closes#1754
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
The general approach of cl65 when generating the command lines to be executed is to first put options and the put files. However, this doesn't work well with the --lib option which would rather need to be put when libraries in general are put. I opted to not add this special behavior to cl65 as
* the use case for the --lib option is _VERY_ specific
* cl65 is after all a wrapper for ordinary use cases
The Microsoft C Library needs to have spawnvp() parameters with spaces quoted manually. We do this only if actually necessary to limit issues with parameters already containing double quotes.
cc65 escapes spaces in paths it writes to dependency files (see WriteEscaped() in cc65/input.c). Given that the output of OptPrintTargetPath() is supposed to be used in Makefiles in pretty much the same way it is appropriate to escape spaces here too.
Reverted part of 3157e4be1e as it actually introduced a regression.
It doesn't make sense to check for Arg[3] == '\0' _before_ checking Arg[2] != '\0'. This made the Win32 builds fail to correctly parse e.g. cl65 -W unused-var test.c
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.
It seems more appropriate to trigger the inclusion of Makefile.inc via $TARGET (instead of $SRCDIR). This is btw. more consistent with extzp.s inclusion which is triggered via $TARGET too.
- Code specific to Windows was #ifdef'ed with _MSC_VER so it wasn't included with MinGW. So _MSC_VER is replaced with _WIN32.
- MinGW doesn't support _get_pgmptr() so it is necessary to directly call the Win32 function GetModuleFileName(). This implies including windows.h which in turn causes a name clash with the Win32 function SearchPath(). So the cc65 type SearchPath is renamed to SearchPaths.
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.
