os.translateCommands uses target OS as default

[smbradley]

Given that the docs (https://github.com/premake/premake-core/wiki/os.translateCommands) explicitly refer to this behaviour, I'm assuming this is intentional, but I'd like to understand why this and os.translateCommandsAndPaths aren't using the host OS instead?

Eg. If you're using Visual Studio to cross compile for Android, wouldn't you want tokens in build commands to map to windows?

[smbradley]

To further clarify: we're seeing problems with this when building for android/consoles under vstudio in combination with build commands containing tokens. The tokens will map to posix style commands which are invalid when run on the windows host by vstudio during the build.

Switching the default to os.host() fixes the issue, but I'm wondering if there's legitimate use cases where the current default is required? Looking at the code, the issue seems to be largely sidestepped by avoiding any usage of tokens internally with calls to os.execute() and so on.

Note we're using this style: premake vs2017 --os=android to generate the projects.

Thanks!

[TurkeyMan]

@starkos @tvandijck Any have any idea on this?

[samsinsane]

Using the host OS would be incorrect - host OS is the OS that Premake was run on. Running premake5 --os=linux gmake2 on Windows, you would want the commands and paths to be use Linux commands and paths. Premake relies on this for the source packaging.

I do agree that using VS to build for Android, you'd want to use Windows paths and commands. Similarly, when using VS to build for Linux, you'd actually want a mix depending on where things run. I believe all things currently run on the remote machine, but I would expect a future update to provide a distinction between running on the local and remote machines - if it hasn't already.

The issue is really that only Windows has a set of functions, everything else will default to the _ OS: https://github.com/premake/premake-core/blob/b173d0890a43a35b1cda48ef019274fc58b232bb/src/base/os.lua#L621-L624

Adding an Android option in here would make sense - or probably in the Android module instead actually. Basically, each function would need to be wrapped:

android = {
  func = function(v)
    local map = os.commandTokens["_"]
    if _ACTION:startswith("vs") then
      map = os.commandTokens[os.host()] or map
    end
    return map.func(v)
  end,
}

This won't allow a user to generate projects on Windows, for VS for Mac though. Perhaps we need to expand os.host() or os.target() so that we have a concept of what OS is running Premake, what OS will be used for the IDE/whatever and what OS the binary output will be for.

[smbradley]

Separating the concept of a host build OS from the host premake OS would be the nicer route I think. Otherwise you're essentially explicitly defining different platform combinations which seems like something that would easily get out of date.

I haven't yet looked into how VS sets up its remote build projects, but I imagine that could be handled by the module itself. Especially if there's a need to distinguish between local/remote commands.

[samsinsane]

Otherwise you're essentially explicitly defining different platform combinations which seems like something that would easily get out of date.

I'm not sure it would get out of date too often, the OS command system is largely driven by exceptions. "Everything uses Unix commands, except Windows." and the above would just change it to, "Everything uses Unix commands, except Android (which uses the host OS instead) and Windows."

I haven't yet looked into how VS sets up its remote build projects, but I imagine that could be handled by the module itself. Especially if there's a need to distinguish between local/remote commands.

Definitely, but you would still need the concept of "build host" and "Premake host" within the module - again, for the VS for Mac situation. Perhaps a better example would be VSCode support, or Eclipse and other multi-platform IDEs that support remote compilation.

[smbradley]

I'm not sure it would get out of date too often, the OS command system is largely driven by exceptions. "Everything uses Unix commands, except Windows." and the above would just change it to, "Everything uses Unix commands, except Android (which uses the host OS instead) and Windows."

I was thinking mostly in regards to adding new target platforms and/or new tokens. Albeit that doesn't happen often, but it seems like something that could easily be missed.

[Jarod42]

Commands and path should be dissociated IMO:

• Some tools uses only unix path separator internally (even if they might translate path afterward).
• Command depends on "shell" used. (powershell/cmd would use copy, whereas bash/sh/.. would use cp). Tools/target (as Codelite, Mingw) might be based on some shell, even on other OS.