scripts for building libmxnet binary and wheel

[szha]

Description

scripts for building libmxnet binary and wheel

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

• Changes are complete (i.e. I finished coding on this PR)
• To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

• add script for making all dependencies
• tools for building pip package
• build scripts for lib and wheel

[roywei]

@mxnet-label-bot add[Build, pr-awaiting-review]

[lanking520]

Please specify the $MAKE

[lanking520]

Thanks for your contribution! Me and @zachgk will follow up with a good README and instructions to use them.

[byronyi]

This makes no sense.

Why do you hard-code git clone to mxnet-build when you already have a source tree to start with?

What if I try to maintain a fork and doesn't want to do nested checkout to the upstream?

And how should I recruit more users, not to mention developers, if I cannot produce a wheel package from my own fork? Or do you expect your users to not fork and submit PRs at all, only waiting for installing the "official" wheel package from PyPI?

[szha]

@byronyi I imagine you can replace the clone command with a symlink to the parent folder. Or a copy.

[szha]

@byronyi we also didn't expect creating a wheel to be a prerequisite of submitting a PR. If there's any specific issue we can help with, feel free to create an issue.

[byronyi]

Symlink does the trick. I will take a closer look and see how to fix this.

And you’re right, building a wheel is not necessary before a PR. But it’s also makes little value for us to send out a PR without first trying it out, which usually requires a wheel package in our in-house environment. I thought it’s a common requirement for certain users, but I could be wrong.

It would be best if we could simply produce nightly packages in the same way you produce one and release it on PyPI. Currently I’m not sure how to do that.

[szha]

@byronyi I agree that simplifying it would add value, and a fix is definitely more than welcome. This PR is a simple migration of code from a separate repo and hence the current structure.