[SDL -> JSON ] parsing error building Lime
I tried to build one of my projects with Redub and got this error:
object.Exception@source/redub/parsers/json.d(86): preGenerateCommand 'n "$${DUB_EXE}" \n --arch="$$(echo "$$DUB_ARCH" | sed -E 's/ .+//g')" \n --compiler="$${DC}" \n --single tools/setup_plugins_overrides.dn ; exited with code 127
----------------
??:? object.Throwable.TraceInfo core.runtime.defaultTraceHandler(void*) [0x100352c6b]
??:? _d_run_main [0x10035b177]
??:? start [0x183dd20df]
??:? 0x0 [0x2c557fffffffffff]
The package I tried to build is: https://github.com/jacob-carlborg/lime. It contains some more advance use cases of preGenerateCommand, so it might be a good test bed.
This one was handled now. Basically it needed:
- Implementation of the --single mode. Redub currently will forward the command to dub.
- The variable DUB_ARCH is now being correctly initialized
- The variable DUB_EXE is now being correctly initialized
- The preGenerateCommands now will use the existing environment so it can reuse some variables such as ROOT_PACKAGE_DIRECTORY or other related things.
@jacob-carlborg With those refactors, your problem was fixed for the following usage:
preGenerateCommands "%DUB_EXE%" --arch="%DUB_ARCH:* =%" --compiler=dmd --single tools/setup_plugins_overrides.d platform="windows"
For some yet unknown reason, it seems to not work when, instead of using --compiler=dmd, using %DC%, it gets some error about the setup_plugins_overrides.exe being denied.
I don't know how to solve this problem yet. And from my tests, %DC% was, in fact, being initialized, so, I'm very confused about that
I tried your latest changes and got a new error:
Running preGenerateCommands for config
/bin/sh: n: command not found
object.Exception@source/redub/parsers/json.d(93): preGenerateCommand 'n "$${DUB_EXE}" \n --arch="$$(echo "$$DUB_ARCH" | sed -E 's/ .+//g')" \n --compiler="$${DC}" \n --single tools/setup_plugins_overrides.dn ' exited with code 127
----------------
??:? object.Throwable.TraceInfo core.runtime.defaultTraceHandler(void*) [0x102186a0b]
??:? _d_run_main [0x10218ef17]
??:? start [0x183dd20df]
??:? 0x0 [0xa00affffffffffff]
I'm running this on macOS. Seems you're using Windows?
@jacob-carlborg looks like the problem is the "\r\n" on posix side. I'm unsure on how should I deal with those whitespaces inside the build command
@jacob-carlborg Actually I think I might have identified the problem: Looks like dub convert actually puts those line breaks inside the JSON, instead of escaping those spaces and treating them as simply spaces.
Look at that, this is the input SDL:
preGenerateCommands `
"$${DUB_EXE}" \
--arch="$$(echo "$$DUB_ARCH" | sed -E 's/ .+//g')" \
--compiler="$${DC}" \
--single tools/setup_plugins_overrides.d
` platform="posix"
Output JSON:
"preGenerateCommands-posix": [
"\r\n \"$${DUB_EXE}\" \\\r\n --arch=\"$$(echo \"$$DUB_ARCH\" | sed -E 's/ .+//g')\" \\\r\n --compiler=\"$${DC}\" \\\r\n --single tools/setup_plugins_overrides.d\r\n "
],
Hmm, so I guess there's a bug in Dub?
Exactly, it is how it is expected to treat a \ on dub.sdl
If that is supposed to escape a \n so it would be included as a space, there is a bug
This was fixed by preprocessing the SDL file using the following code:
string fixSDLParsingBugs(string inputSdl)
{
import std.file;
import std.string:replace;
version(Windows)
enum lb = "\r\n";
else
enum lb = "\n";
return readText(inputSdl).replace("\\"~lb, " ").replace("`"~lb, "`");
}