Distribute binaries on NPM

[auchenberg]

The Visual Studio team is apparently already shipped an version of ios-webkit-debug-proxy.exe in the vs-libimobile NPM package.

It would be helpful for the broader community to be able to download the latest binaries from an NPM package, much similar to how we have chosen to distribute the edge-diagnostics-adapter, where each NPM package only contains the binaries for x86 and x64.

[masahirotanaka]

Sounds like a very good idea. We are also embedding the binary into our npm library, but I'd like to separate this out to an external dependency.

In that case, I hope the original ios-webkit-debug-proxy (for macOS) to follow the same manner though.

[artygus]

@auchenberg cool! is there any official libimobiledevice VS port? because it's quite complicated for me to look for another fresh libimobiledevice VS fork each time something gets updates and incorporate those changes. For now I decided to go with mingw32 builds. libimobiledevice HEAD builds successfully with mingw and it does the job with much less hassle

[auchenberg]

@artygus I'm not aware of a "special VS" build of libimobiledevice, but I've seen you mentioning Visual Studio in a few issues. It's my understanding that VS is relying on the vs-libimobile package, which contains libimobiledevice.dll.

Can you enlighten me on this special VS build?

Generally I'd like to depend on as many regular builds as possible. For a few upcoming projects I like to use a new-as-possible build of ios-webkit-debug-proxy, and it be helpful if you could publish your binaries to NPM.

(I'm not Windows and build expert here, so I do apologize for the ignorance)

[artygus]

@auchenberg honestly I'm not expert too, and I don't even use windows for the dev anymore. What I was trying to say is that building ios-webkit-debug-proxy and libimobiledevice with visual studio is complicated because there's no official support for Visual Studio in libimobiledevice, you can see a few pulls here https://github.com/libimobiledevice/libimobiledevice/pulls but none of them made it to master branch. I'm just wondering how vs-libimobile is built. Regarding the shipping with NPM, sure it's great idea, there's already issue for that google/ios-webkit-debug-proxy#136, whenever I'll have enough time to finish win32 branch (google/ios-webkit-debug-proxy#124) I'll go for it.

[auchenberg]

@artygus I just had a chat with the engineer building the package, and it was compiled using MinGW.

[artygus]

@auchenberg thanks!

[auchenberg]

@artygus What are your principles about versioning and version numbers? I'd like to get NPM build going and I could grab the latest SourceForge files, dump them into https://github.com/auchenberg/ios-webkit-debug-proxy-win32-prebuilt, and make a NPM publish.

For that to work I need semantic versioning and a way to mark each release as a tag/github release

[artygus]

last time I did x64 build it was from google/ios-webkit-debug-proxy@0b2770c. x32 build based on google/ios-webkit-debug-proxy@fec01df

[auchenberg]

Okay, but we need to coordinate the binary releases with https://github.com/google/ios-webkit-debug-proxy/releases

Same goes for the win32 project, which doesnt seem to use tags/releases, and therefor makes it hard to publish versioned binaries. https://github.com/artygus/ios-webkit-debug-proxy-win32/releases

[artygus]

@auchenberg these commits correspond to 1.7.0 and 1.6.0 versions. Those were built with msys2/mingw32(64).

It would be more precise to call "win32" project a "visual studio" project, it's based more or less on 1.5.0. and I have no further intention to keep it up to date.

UPD: I hope to get back to work on mingw branch of original ios-webkit-debug-proxy, so win builds would be always up to date with other platforms, in the next two weeks

[auchenberg]

That would be wonderful. I think a good start would be to use Git tags for each binary release, which would make publishing much easier. Can you create two tags for 1.7.0 and 1.6.0?

At this point in time many projects relies on their own custom builds and we should avoid this by providing centralized builds. Happy to help to get the setup going.

[artygus]

google/ios-webkit-debug-proxy#136