Alternative way of providing arguments to psc

[garyb]

It appears Windows has a limit on the length of command line arguments. I thought it was an issue with the gulp plugin, but it's not just that: purescript-deprecated/gulp-purescript#36.

One option is to allow a file input to parse the commands from, or perhaps we could accept glob paths in the executables themselves - it would certainly make for a friendlier interface for people not using pulp, gulp, etc.

This is going to become a real problem for me soon, as slamdata is very close to exceeding that limit 😉

[michaelficarra]

@paf31 expressed a desire to be able to pass a bower_components-structured directory to psc at PureScriptConf/LambdaConf, and I thought he opened an issue for it, but I can't seem to find the issue now.

[paf31]

I think I'd like to support glob paths rather than putting arguments in files.

[garyb]

👍

[garyb]

I spoke too soon with this, I'm already unable to build slamdata on Windows after updating to the latest revision 😉

I see there's a glob module on hackage, does that look any use for this?

[paf31]

I think glob would work, yeah.

[chexxor]

Holy buckets, this is huge. I was using Fish shell to use nice globs when using psc command, but it looks like I won't need to do that anymore.

Which doc page is the right place to demonstrate using globs with psc? My first reflex would be the Language Guide: Getting Started wiki page.

I wonder what happens if both a shell and the program try to handle globs. If the shell expands the glob, psc won't see it as a glob, right? When we see a demo usage, I'll give it a try.

[garyb]

The current gulp plugin expands blobs and works fine with this, so I wouldn't imagine it will introduce any problems with any existing build setup (aside from other changes like the --ffi requirement now).

[gbaz]

There's actually a standard way to handle this, which is response files (aka rsp files) and these are handled by many compilers including gcc. We had to teach cabal and ghc about them as well. The glob setup is only a partial solution because it limits our ability to be precise.

Cf:
https://ghc.haskell.org/trac/ghc/ticket/8596
https://msdn.microsoft.com/en-us/library/ms404301.aspx
https://gcc.gnu.org/wiki/Response_Files

We'd really like support for this, as our workarounds aren't nearly as nice as the precision we'd be able to get from using arbitrary length commandlines that say exactly what we want.

Would you be open to reopening this (especially if I volunteered to help with a patch? :-) )

[hdgarrood]

Can you give an example of a situation where the level of precision given by globbing is insufficient?

[gbaz]

So the issue that prompted this is we need to provide absolute paths, and hence we need to start with C:\ -- at which point we need to have very careful globs because we could accidentally slurp the entire filesystem, as we accidentally have once or twice, and its a bear to debug.

Meanwhile, we use msbuild, which actually can already produce response files by default. And backing into a "good glob" from those response files is tricky, and not subject to automation. But if we could use the generated response files, we'd have no work to do at all!

[paf31]

It would be nice if optparse-applicative could support this.

[gbaz]

Yeah, I checked and there doesn't seem to be direct support. On the other hand, I still think, done right, this should be a tiny patch :-)