Use the original name as template for readability in
the map file, and use the process PID instead of platform-dependant
or deprecated random filename functions to make unique temporary
filenames. Also, create these temporary files in the output
directory.
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.
