Closed NiklasRosenstein closed 8 years ago
Steps to resolve this problem:
Session
class should get a export
attribute that is set when the -e
option is passedsession.export
and eventually export a commands file that is then passed via the command-line instead. These files should be put into a .cmd
folder in the build directory and saved under the full-spec target name.A Windows link command could then look like this: link @.cmd/nr.projection_lens.plugin
. Ideally, this would only happen when really necessary and otherwise pass the arguments traditionally on the command-line.
This is a bit more problematic than I initially thought since the command-line contains the Ninja variables $in
and $out
and checking if the command-line would be too long is not an obvious task. Eventually, commands that support @file
syntax should always use it.
It seems like this issue is only present when prefixing a command with cmd /c
! Unfortunately in some cases, we have to run it through cmd /c
as some programs are not found otherwise. Gotta investigate what these cases are.
Some systems shouldn't be used for development :)
On Sun, Jan 3, 2016, 6:42 AM Niklas Rosenstein notifications@github.com wrote:
It seems like this issue is only present when prefixing a command with cmd /c! Unfortunately in some cases, we have to run it through cmd /c as some programs are not found otherwise. Gotta investigate what these cases are.
— Reply to this email directly or view it on GitHub https://github.com/craftr-build/craftr/issues/67#issuecomment-168502059.
I'm bound to using Windows for work unfortunately. ;-)
So it seems like the Win32 API CreateProcess()
function "can only be used with executable images". [reference]
Ok so on Windows I'll just try to find the program that is being executed, check if it is an executable image, and if it is not, run it via cmd /c
.
Not sure about linux, but Windows has a hard cap on the length of a command-line. Windows commands like
cl
andlink
support a@filename
syntax from which they'll read the arguments.