Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated reference builder #4

Open
Farof opened this issue Jan 28, 2016 · 4 comments
Open

Automated reference builder #4

Farof opened this issue Jan 28, 2016 · 4 comments
Assignees

Comments

@Farof
Copy link
Owner

Farof commented Jan 28, 2016

Writing an automated reference builder should be fairly easy using the protocol data structure and events description.

It should be able to track what was added or removed in each build and be backward compatible.

It could either output directly a reference or some intermediate files to be consumed by existing automatic documentation builder.

@Farof
Copy link
Owner Author

Farof commented Jan 28, 2016

Should the reference stay in this project and in what form: files, wiki or both? Or make a dedicated project?

Would be nice to team up with people working in other languages if possible.

@jnovack
Copy link
Contributor

jnovack commented Jan 29, 2016

Because Javascript is interpreted, I'm not opposed to make node-gyp modules (using c) for these, especially the mpq functions. Most of the time wasted in extracting the data is there.

@Farof
Copy link
Owner Author

Farof commented Feb 2, 2016

Current work visible on the feature-automation branch.

It's a work in progress, currently porting from a local clone of the heroprotocol repository, but I want for the script to do it's own clone/pull.

The porting script reads the Python lines and transforms them into Javascript object representation of the data structure and events, thus paving the way for the automatically generated reference.

@jnovack
Copy link
Contributor

jnovack commented Feb 2, 2016

Considering the feature-automation branch, a conundrum has occurred. Should the porting script and the distributables be in the same repo?

The following two questions are not mutually exclusive:

  • Should the porting script be in this repo or a heroprotocoljs-build repo?
  • Should the distributables be in a repo at all, or just always built (e.g. in a dist/ folder to copy into higher-level application; or, automatic github uploader to personal repo; or, automatic npm uploader to personal namespace)

Two cases:

  • Is this repo trying to maintain as close a port as possible? If so, perhaps the -build repo automatically generates this repo.
  • Someone wants to create a fork of this project to change the template, a fork of the -build repo would let them do so. Example: I have a minimally-working fork using storm-replay rather than mpyqjs. If there was a -build repo, I could use it's script to grab the Blizzard/heroprotocol repo and update the templates.

Food for thought...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants