<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 22/11/2013 02:20, Hans Wennborg
wrote:<br>
</div>
<blockquote
cite="mid:CAB8jPhfVvr3_2FDDChx_WGc4Yi8vzQzYKoFcb3-EBENOLrK_KQ@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Nov 21, 2013 at 5:55 PM, Alp Toker <a class="moz-txt-link-rfc2396E" href="mailto:alp@nuanti.com"><alp@nuanti.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Hans,
Impressed that you've coaxed cmake into building and bundling the VS
package..
</pre>
</blockquote>
<pre wrap="">
It's not exactly my proudest moment, but it seems to work ;)
</pre>
<blockquote type="cite">
<pre wrap="">However not so convinced it's the right deployment model:
1) The installer gets copied into Program Files -- then what? Does the user
have look for and install it separately, or is it the site administrator's
job?
</pre>
</blockquote>
<pre wrap="">
We could have the installer run it when it copies in the files for the
MSBuild integration. Or the user could install it manually - I'm kind
of torn about this.
</pre>
<blockquote type="cite">
<pre wrap="">When the main uninstaller is run, does the extension get left behind?
</pre>
</blockquote>
<pre wrap="">
That's definitely an issue. If we teach install.bat to install the
extension, uninstall.bat should remove it. From what I understand, the
way to do this is to find vsxinstaller.exe and run that with
/uninstall.</pre>
</blockquote>
<br>
Another data point: According to the VSIX Deployment guide,
extensions usually install per-user, whereas LLVM tends to get
installed system-wide by default.<br>
<br>
(The more I read through that page, the more I get the impression a
balancing act with CPack/nsis isn't going to work out.)<br>
<br>
<blockquote
cite="mid:CAB8jPhfVvr3_2FDDChx_WGc4Yi8vzQzYKoFcb3-EBENOLrK_KQ@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">If the main LLVM install is upgraded, what happens the the extension, and
which clang-format.exe version will it end up calling into post-upgrade?
</pre>
</blockquote>
<pre wrap="">
The new installer would presumably install the new extension too.
But note that the clang-format extension is just a thing that calls
clang-format in the LLVM installation dir. It doesn't contain a copy
of clang-format itself, so it will always just call what's installed.
</pre>
<blockquote type="cite">
<pre wrap="">2) The target audiences are fairly distinct. Most clang-format Visual Studio
extension users likely don't want or need an LLVM installation. This is the
crowd who'd benefit most from a single click installation on the download
page that works the same way as other VS extensions.
Wouldn't it make more sense to offer the Visual Studio extension as a
separate download?
</pre>
</blockquote>
<pre wrap="">
If we want to support that, we should bake clang-format into the
extension itself.</pre>
</blockquote>
<br>
That sounds much better. Redacted from VSIX Best Practices:<br>
<ul>
<li>Distribute your whole product in one independent VSIX if you
can.</li>
<li>If you ship more than one VSIX, and they share common
assemblies, copy the common assemblies into each separate VSIX.</li>
</ul>
The technique for bundling resources should work with
clang-format.exe:<br>
<br>
<a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/en-us/library/vstudio/ff363239.aspx">http://msdn.microsoft.com/en-us/library/vstudio/ff363239.aspx</a><br>
<br>
Alp.<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.nuanti.com">http://www.nuanti.com</a>
the browser experts
</pre>
</body>
</html>