Command-line option to specify gupfile extension? (for Windows...)

[xparq]

gup almost works in the default native Windows cmd space as-is (i.e. not depending on sh at all), and I think it should, too, since sh is a pretty arbitrary constraint that gup probably doesn't even make use of. (Is that true, actually?)

But, since Windows is against it with full force, and the canonical assoc+ftype+pathext solution fails for me (cannot execute gupfiles, for no apparent reason, despite everything seems to be set), a hopefully simple addition could push it through the obstacle for good.

For an experiment, I changed

    self.gupfile = GUPFILE if indirect else target + '.gup'

to

    self.gupfile = GUPFILE if indirect else target + '.gup.cmd'

and it seemed to work OK with the renamed test gupfile (the simplest example from your repo).
(Note: currently, this is the ONLY way I can run gup on this Win7-32 setup.)

Could it be officially supported, so that

1. the extension can be set on the command-line
2. and invocations from within a gupfile would use the current gupfile's extension as the default? (I'm not sure if this is already the case, or how non-trivial it can get, if not.)

Not having the ".gup" naming fixed might be useful on Unix, too.

[timbertson]

I'm not quite sure what your trouble is. I admittedly don't use windows much (aside from testing things), so maybe you can explain a little more.

Specifically:

• gup doesn't depend on sh at all. Your gup scripts can be written in sh if you want them to, but that's entirely your choice. Can I ask what led you to believe gup depends on sh?
• what do you mean by "cannot exec gupfiles"? gupfiles do not need to be individually executed, they are invoked by gup itself.

A gupfile can be an .exe on windows, but it can also be any text file with a shebang line (#!<program>).

My typical assumption is that your build process will be as cross-platform as you need it to be. So if your project only works on windows or only on unix, your gup scripts only need to work in the same places. But if your project is cross-platform, I'd expect you to write your gup scripts cross-platform too. This means no bash or cmd, but rather something like python which can happily execute everywhere. It should be possible to use cmd to run your gup script, but only if you can get it to ignore a leading #!cmd.exe line in the script. Otherwise, you may have to resort to a Gupfile:

foo.gup.cmd:
    foo
( etc )

This is tedious and repetitious, but to be honest I'm not very motivated to support windows-specific functionality in gup, because that goes against the goal of being simple and platform-agnostic.

Having the default gupfile extension (.gup) be OS-specific is pretty drastic, and I think would cause a lot more cross-platform issues than it could ever solve. So having indirect targets be named foo.gup.cmd on windows is not going to happen.

There could be a use in having multiple build targets (e.g. foo can be built by foo-unix.sh or foo-win.cmd). This would have to be specified in a Gupfile somehow, because making default ruls are not going to be flexible enough.

Does that help? If not I'm a little unclear on what your problem is, so maybe you could provide a more concrete example? i.e. a simple example with the contents of each relevant file, and the exact command you're running which isn't working.