Windows Support

[yudilevi]

process.env.PWD is undefned on Windows systems.
It's usually encouraged to use process.env.cmd instead but I'm not sure what the implications are on this specific project.

[mswezey23]

Windows devs would love to have this doxity work on their dev setups.

Or if someone can point me in a general direction on what is needed and perhaps I can help fix Windows support.

[JamesCullum]

Still doesnt work - stuck during init (workarounds dont work), can't read .doxityrc and gets ""contracts/*"" is not found during build.

[romaric-juniet]

I cloned Doxity to make it work on my windows machine. I didn't take the time to properly fix it and test it so I wouldn't recommend that you use it, but hopefully it will help you
https://github.com/romaric-juniet/doxity

[alexpArtos]

@JamesCullum I had the same problem in Linux. I found that passing an absolute path instead of contracts/* worked.

[alexpArtos]

I have cloned Doxity in my windows platform, and done some changes to make it run.
I'm still new to contributing to public gitHub projects like this. What would be the best way for me to share this work with the community?

At the moment, I am able to produce documentation successfully on Windows. The changes I made fall in these categories:

• use path.join to concatenate paths, instead of using hardcoded '/'
• add logic to detect the platform, and run npm.cmd or npm as appropriate (in init.js or publish.js)
• added logic to expand a final '*' wildcard in the path to contracts to all the files below it, since this is not automatically done by the Windows command line
• changed the name of the tarball file downloaded in init.js, to avoid whitespaces, because these were giving me some trouble.

There are 2 more changes that are necessary to make the tool run, but which I don't personally like:

• I changed my package.json to make the "compile" target work in Windows. I don't know how to make it work both for windows and *nix simultaneously, so this is a very targeted change. I welcome suggestions on how to make it more general.

• In order to get around the process.env.pwd, I used a maybe hacky solution: I created a new doxity.cmd that I invoke locally and which sets an environment variable called PWD. I have seen people using cwd(). When I started adapting Doxity, I looked it up to see what cwd() does and I found this post:
  https://stackoverflow.com/questions/31414852/process-env-pwd-vs-process-cwd
  which put me off using cwd(). Any comments welcome.

[JamesCullum]

You can create fork the project, pull it via git, apply you changes, push them back and then create a pull request to have those changes reflected here 👍

Thank you for the detailed instructions, I will try those things later.

[JamesCullum]

Thanks everyone for your support - using the fork of @romaric-juniet I was able to get it running. I will leave this open for other users as a guide until it is fixed on the main version.

Steps to take to make it run on Windows

1. Find the path of the doxity you probably already installed via where doxity
2. Visit that folder and delete the doxity files (npm uninstall -g doxity supposedly does the same but didn't remove it for me)
3. Download the Windows version of solc here and extract the files directly into the same folder from 1 (as it points to %PATH% and allows you to use the solc command inside the script)
4. npm install -g romaric-juniet/doxity to install the fork as global doxity. You should see the doxity files reappear in the folder.
5. Open up the command line and navigate to the dproject directory
6. Run doxity init which now works (original can't even init)
7. I've had to point it directly to the parent contract via doxity build --src "contracts\Contract.sol", as neither wildcards, nor absolute paths worked.
8. It compiles the contract and creates all files in the docs folder. Deploy that folder on your webhost.

Optional
Opening the HTML files in your browser won't work, as the docs folder creates some files only once. Use npm install -g http-server to install a webserver. Navigate to the docs folder with the javascript files on the same level and run http-server - now you can navigate and have all pages render correctly.

[alexpArtos]

Thanks @JamesCullum .
In my experience, passing a specific contract to the --src parameter only gave the documentation for the contracts "pulled" by that one (inherited or used, I believe). It did not give me all the contracts in that directory.
Maybe I have something different in my environment.

[alexpArtos]

I've just added a pull request with my changes. Would be grateful if they could be reviewed and merged with romaric/juniet's, as I think they are complementary.

[JamesCullum]

Good approach - make sure to reference this issue in it to clarify the background 👍
Yes, this only works for the contract and all the inherited ones - for me, that is enough.
Otherwise you can try to play around with wildcards or run it multiple times for the different main contracts.