Distribution / Publishing

[paul-marechal]

IIRC to be distributed correctly, this extension will have to be compiled once on each major platform and then somehow uploaded to the VS Code marketplace.

Right now to be able to use it in Theia for instance, I compile it and make a release on a fork.

Was just wondering if there was some kind of publishing made with this package as of now?

This issue can also be used to track this, until the CI is up and running.

[paul-marechal]

Ok it is only halfway through writing the issue that I remembered the distribution "issues" that came with the native part.

But the idea of building once on each platform sounds like the way to go :)

[dschaefer]

I don't think the VS Code Marketplace supports this yet. I'll have to dig into it again.

For now, we post the vsix files on the Jenkins jobs. I grab those and manually install them into my IDE.

This will come to a head when I'm ready to publish the main CDT vscode plug-in that will also bundle clangd. But I have a few things I'm waiting on before we can proceed with that. It's looking the earliest will be in April.

If the Market place isn't ready for per platform packages, we'll have to resort to a strategy of bundling the binaries for all three platforms into the extension and use dynamic requires to pick them up. I'll have Jenkins slaves for each set up by then to do that. They'll just be a bit big (>100MB).

[dschaefer]

Oh, and right now we only support Linux since I don't have the Win and Mac slaves yet.

[paul-marechal]

For now, we post the vsix files on the Jenkins jobs. I grab those and manually install them into my IDE.

Oh cool, I will look for where to download them, we have scripts that do that for us, nice!

Oh, and right now we only support Linux since I don't have the Win and Mac slaves yet.

Seems fine with me for now, as the native extension is Unix/Mac only anyway.

If the Market place isn't ready for per platform packages, we'll have to resort to a strategy of bundling the binaries for all three platforms into the extension and use dynamic requires to pick them up. I'll have Jenkins slaves for each set up by then to do that. They'll just be a bit big (>100MB).

Do you mean you would bundle both the adapter's native parts and clangd?

Wouldn't it be better to somehow have them downloaded by the extension after install (if not postinstall, right at runtime?) I mean... a 100mb+ extension does sound heavy :)

I don't know what's the heaviest, but I would guess clangd.
Could be a side download, I don't really know to be honest.

On the other hand, yes, whatever works is fine!

[dschaefer]

Do you mean you would bundle both the adapter's native parts and clangd?

Yup, I actually have a forked version of clangd to support additional targets and to deal with users using gcc.

Wouldn't it be better to somehow have them downloaded by the extension after install (if not postinstall, right at runtime?) I mean... a 100mb+ extension does sound heavy :)

I don't know what's the heaviest, but I would guess clangd.
Could be a side download, I don't really know to be honest.

Since the user has to do the download one way or another, not sure how much of a difference it makes for them. But yes, I'm considering that as an options. And I'm not sure that would be easier since I then have to implement the post install download code. But I've seen other extensions, e.g. the Red Hat Java/JDT one, that do that.

On the other hand, yes, whatever works is fine!

True. Can't wait to get this stuff up on the marketplace so we can get people trying it out and giving us feedback (and hopefully come help :))

[jonahgraham]

Duplicate of #42