[Cppia] Sys.args contain name of program file

[AlexHaxe]

When running haxelib run hxcpp myProgram.cppia -v or bin/Cppia myProgram.cppia -v calling Sys.args () will return ["myProgram.cppia", "-v"] instead of just ["-v"] (like e.g. a cpp compiled version does).
According to https://api.haxe.org/Sys.html argument list should not contain interpreter nor name of program file.

[Aurel300]

So haxelib run hxcpp <ARGS> just invokes bin/Cppia <ARGS>. bin/Cppia I believe is just the binary produced by building cpp.cppia.Host. Within the host, Sys.args() can be read, but not really written. A patch probably has to be applied to the Sys.args method directly:

https://github.com/HaxeFoundation/haxe/blob/abcf23120811c5efdfd63bf230ed3e4640de08d9/std/cpp/_std/Sys.hx#L54-L57

Perhaps add #if cppia .slice(1) #end plus a method to get the zeroth argument on cppia only? The solution seems a bit messy though :/

[AlexHaxe]

I was trying to figure out why formatter benchmark would not run on cppia target. After experimenting and figuring out what happened, I patched formatter locally to remove the first argument (and had to stop formatter from removing the last argument *) and then it ran just fine.

So projects can add a workaround, I was hoping there was something hxcpp could do to make it consistent with C++ target. I mean technically the manual doesn't really mention cppia...

*) The reason why formatter removes the last argument is that when running haxelib run formatter haxelib will add current working directory as a last arg. Luckily haxelib sets HAXELIB_RUN env var, so programs know they run "inside" haxelib and can remove or deal with that extra arg.

[hughsando]

Yes, not sure what the solution is here. In nme, I have System.getArgs and System.setArgs which can account for this.
I could hack the arg out, but that would now break your fix.
Maybe I could add host script.cppia -args x y z and hack out everything before '-args'

[tobil4sk]

from #1174:

Perhaps the cpp.cppia.Host.runFile() should take an args argument, then runFile should store the script file name and arguments somewhere. Sys.args() and Sys.programPath() should be virtual calls that return these values.

This would require the host to create a new script-specific context per script invocation that intercepts Sys.args()/Sys.programPath() calls to use the correct values. I'm not sure if cppia hosts can do something like this already.

I think this would be a flexible solution that would make sense even outside of the default bundled cppia host