[WIP] Documentation - Draft: Cross-platform considerations + Windows build #487
Conversation
docs/cross-platform.md
Outdated
|
|
||
| The good news is that the majority of OCaml build tools do support building from a `cygwin` environment - and often, that is the recommended environment for building on Windows. | ||
|
|
||
| Note that, even though our build commands on Windows are executed in a `cygwin` shell, the __binaries that are produced are truly native__. This applies both to all the packages we build, as well as the resultant binary for your project itself. Cygwin provides two compilers - a cygwin `gcc` compiler, and a `mingw` cross-compiler that compiles to native windows executables. We leverage the latter so the result is that `esy build` on Windows gives you native executables. This means that you can use `esy` to build apps natively for any platform! |
There was a problem hiding this comment.
The way people often distinguish this from typical cygwin environments is a "mingw" toolchain. When people talk about cygwin then usually mean an environment that produces binaries that aren't pure windows binaries, but require cygwin1.dll to run.
There was a problem hiding this comment.
Good point - tweaked the wording here to try and make that more explicit.
|
|
||
| Symlinks on Windows are not well-supported today. To create symlinks, a Windows user either needs to be running as _administrator_, or set up a special developer mode - neither which is the default behavior on the system. | ||
|
|
||
| Therefore, at this time, we should avoid using symlinks in cross-platform code. |
There was a problem hiding this comment.
We could note that esy currently uses symlinks in one place, and for the time being you must run in an administrator shell (but that eventually that limitation should go away).
There was a problem hiding this comment.
Discussing with @andreypopp - I believe the plan is to remove symlinks completely from esy. So it might not even be worth bringing it up, if that change is in the near-term.
|
|
||
| ## Long-term plans | ||
|
|
||
| As `esy` matures, we can minimize our dependency on `cygwin` for Windows - we can use `esy`'s DSL for specifying build commands to directly target native-windows executables, bypassing the `cygwin` layer. In parallel, we can start to migrate packages to more fully support cross-platform builds. |
There was a problem hiding this comment.
It would be cool to allow pure-Dune projects or inherently cross platform packages to opt out. There's no reason they even need cygwin at all! Something like a config "esy.platforms": ["osx", "windows", linux"] that you can specify to speed up your builds.
There was a problem hiding this comment.
Ah yes, for sure. One thing we discussed on Discord a bit back was making esy-bash a dependency (and renaming it esy-essentials or esy-native-toolchain or something). I logged an issue to track this further: #643
We could model this as an implicit dependency we add by default, but then if the user 'opts out', we wouldn't include this dependency.
|
|
||
| Long-term, we'd like to provide a cross-platform abstraction layer that frees the developer from the cognitive load of these challenges - something that Node/Javascript was very successful at. One thing the NPM/Node ecosystem was successful at is making it _simple_ to build cross-platform solutions, with minimal effort from the developer. | ||
|
|
||
| This section is the first stage of such a cross-platform abstraction layer - identifying pain points in cross-platform development today, so that we can iron those out. |
|
@bryphe do you think we can bring this in? |
No description provided.