Open bradh opened 6 years ago
The easiest way for Windows developers to get started with OpenSphere is to install Docker (or similar container manager) and fire up a container with all our prerequisites (which we should create and host somewhere). This would also help with preinstalling nginx. Volume mapping would allow editing and npm install to take place in the dev workspace, and then the build and tests could be run in the container as well as served out via nginx (port mapping).
I am not saying that the Windows build should not work, but that this is the easiest workaround right now.
I am currently working with the OpenSphere baseline via the Windows Subsystem for Linux (WSL) without any problems on Windows 10. I am working on adding some documentation to that effect to the OpenSphere baseline. If Windows 10 is not an option, then the VM/Docker suggestion is likely the best option. If Windows 10 is an option, see https://docs.microsoft.com/en-us/windows/wsl/install-win10 to get the subsystem installed. After a WSL Linux distribution is installed, all the prerequisites for the OpenSphere project need to be installed via the WSL environment, after which, the project should build fine in the WSL environment.
Definite improvement. I still think it should be possible to do a native build on Windows - there is nothing inherently Posix-y about what we're trying.
In order to do this we'll have to find node packages to replace:
perl
- used for search/replace, should be a simple replacementgrep
- not only is this used once in package.json
, but it is also a dependency of the simple-grep
node package used in opensphere-build-resolver
cp
- we initially tried a couple of different node packages for this only to be frustrated that they didn't work as well as cp
find
- should be an easy replace, we just didn't bother because we'd already given up on replacements for cp
and grep
at the timexargs
- should be easy enough to replace or write a quick node script to process those filesAnd we would need to do a quick look over opensphere-build-resolver
and opensphere-build-index
to ensure that they are not depending on node wrappers for those native packages.
I've been trying to get the build to run on windows. The
package.json
build commands that assume Posix shell behaviour aren't working out - it appears that even when npm is run from a Posix shell, the commands get run on the default shell (which looks to be cmd.exe). Its possible to work around this with `"bash -c \"{blah command here}\"" for every command that requires proper shell behaviour (as opposed to those that just execute some command without using command substitution, fancy redirects...). Its ugly, but its only about 16 commands.After that, the closure compiler step dies with duplicate input files. Still tracking down why that happens - probably something in the way we build
.build\gcc-java-args
.