Support and test on Windows
wende opened this issue · comments
Test and write down possible differences when setting up Elchemy for developers using Windows
Split from #284
Since I am the one who asked for Windows support I will puts my 2 cents in. I am a Windows developer with little knowledge with Elixir/Erlang and Elm and that much in node too, so please take my words with a grain of salt.
From my (little) knowledge, Elm and Elixir/Erlang/OTP have good support for Windows so it seems safe to say if the usage made of those tools does not dive to close to some OS specific stuff most code written with those languages should work the same on Windows and Linux.
Taking that into account, I browse through the repo and elchemy-core too and try to identify files (based on their extensions or names) that are usually tied to a specific platform. I only found a couple of files (but I may missed some) with names and extensions that are known to only works on Linux.
They are:
First, elmchemy is deprecated so in my opinion it don't even make sense to port it to a new platform.
Then, the .travis.sh file seems to only be used by travis and a similar file can be written for AppVeyor (which is generally the go-to continuas integration on Windows for open source project).
Then, bump.sh seems to be used to generated a changelog and does not seems strictly necessary for a working installation on Windows. At least, it probably can be ported to Windows later on.
That leaves only 2 files: Makefile and elchemy which are tied to Unix tools where a similar tool might not exist on Windows. There I see mostly 2 ways to deal with them.
Firstly, they can be rewritten for a specific shell for Windows. From my experience this will be painful to maintain and fragile at the same time since the Linux and Windows version should maintained in parallel while keeping the same behavior.
Then, To my knowledge, there are 2 shells under Windows. There is cmd and the more recent Powershell. They have different capabilites out of the box (Powershell being more powerfull).
To add more complexity to the problem, some users (me for instance) install git while choosing to add the git bash' unix tools in the PATH.
This mean that on my computer find will not call the default Windows find but the same one that is on Linux.
The other option for porting these file is to rewrite them using cross platform technologies (ie, same tool on every platform). It may be a Mix task for the Makefile and the elchemy script (since the user is expected to have Elixir it could be convenient).
It may also be for instance, a gulp script for the Makefile and a node.js one for elchemy. Anyway, this solution has probably a lot of room and I am not the best person to recommend one (due to my poor knowledge of Elixir and Elm) but if you ask me I would go with the same tool on every platform solution.
Hope this helps.
Hi @codec-abc. Great report!
That would be correct. The only two files requiring tweaks would be a Makefile and elchemy (elmchemy exists just to recall people that the name is no longer supported)
Not sure what is a way that other common tools use to support Windows, but I'm assuming writing that Powershell is a dependency is a very decent consensus and would make porting it much easier.
I'll mark this issue as "Help needed" and maybe there'll be someone with enough will to fight to make the port a whole thing 👍
Do note, powershell cannot run powershell scripts unless the script is signed with a security certificate or unsigned scripts are allowed via system options (requires admin).
You know, if they have elixir anyway, why not just make the elchemy and makefile or whatever just normal elixir stand-alone escripts? Then they could just run it via escript elchemy ... or so.
@OvermindDL1
My main concern why I didn't do it that way in the first place was performance (There is a lot of file content piping and stuff bash tools were specifically made to do)
But rewriting it to an escript would solve all of the platform related problems. Both the language of date, Windows support and probably many more in future. And also the code would be much more manageable.
The only concern I have would be performance (find -newermt, content streaming etc)
The only concern I have would be performance (find -newermt, content streaming etc)
The beam is designed for IO, so although not all of the 'obvious' calls are efficient, you can get things efficient. If you need help with anything definitely ask on the forums!
Also for benchmarking elixir code, nothing beats Benchee. :-)
Also, as Elixir will inherently use every-single-core-on-every-single-cpu-possible, you'll be able to parallize everything that is possible to parallize with ease.
Blocked by #288