<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Well, we consider it clean and best practice to put all tools that are required by our build scripts into the repo itself. Our goal is that you can checkout any repo (or any label) on any clean PC that does not even need to have internet access and immediately being able build from the working directory by double clicking something like a build.bat script file without any dependencies to the outside (of the repo). We sometimes make exceptions for huge stuff (like e.g. VS itself) or software that cannot run without running an installer (again VS - but we add the installers to the repo in that case). Working like this has many advantages, e.g. you can use different versions of the same tool on the same machine because these versions are inside the various different repo working directories and not on PATH; also this is a really good archiving method that allows us to build even very old repos and old labels of a product with the tools that have been used n years ago.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">We do basically the same thing with libraries. Even though we use NuGet now for download libraries and their dependencies, we always add the downloaded libraries to the repo too in order to never being dependent on some outside server that may or may not be online at the time when we want to build our software.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The price of this is big (sometimes huge) repositories and working directories of course. But we gladly pay that price to have the advantages.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Markus</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-08 18:22 GMT+01:00 Michael Jerris <span dir="ltr"><<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I'm a bit out of date on what these tools provide and need someone to get me up to speed on what is available. Can you help me understand what the options are for maintaining c libraries in a way that is cleaner than needing to stuff them all into our build.<span class=""><div><br></div><div><br><div><blockquote type="cite"><div>On Dec 8, 2014, at 5:29 AM, Markus von Arx <<a href="mailto:mkvonarx@gmail.com" target="_blank">mkvonarx@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">We are fine with your Visual Studio plans. We only use VS2012 at the moment and actually would like to migrate to VS2013.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Not so sure about the use of chocolatey though. Are you planning to use it to download libraries required by the build or for installing software/tools required for the build? Both look a bit problematic to me, because chocolatey (as far as I understand it) always acts globally on the target machine, meaning that it installs the libs/tools/software not locally inside the build directory but globally on the machine. I wouldn't like that at all. I don't want a build tool/process to install anything outside the build directory. If you manage to use chocolatey to only work in the build directory that's fine for me. But I'd strongly vote against any use of chocolatey to install libraries, tools or any software globally or outside the build directory. I wouldn't like a build tool/process/system installing anything on my machine for me automatically. Kind of like calling apt-get on a Linux machine from a build script. I think that is a no-go. Also, chocolatey is not so good detecting installed software that was not installed by chocolatey itself and would often try to re-install software that is already there. I'd vote against using chocolatey in the FreeSWITCH build if you ask me. Wouldn't nuget be the more natural choice anyway to install modules/libraries in Visual Studio? Just my opinion.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Markus</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-03 21:31 GMT+01:00 Michael Jerris <span dir="ltr"><<a href="mailto:mike@jerris.com" target="_blank">mike@jerris.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Given the recent announcements by Microsoft about the community edition 2013 being available, we are working to migrate the build system towards using that as our primary build. As part of this process we will be very soon dropping support for any version of Visual Studio prior to 2012. If you feel strongly about needing support for these older versions, please speak up now with an offer to maintain these legacy build systems. We are also investigating moving to using chocolatey as a new system to manage dependencies on windows instead of maintaining the build for all our deps ourselves. It is also possible we will drop support for the 2012 build system in the not so distant future. Could the community chime in here as to what their needs are, and what they are willing to do to help support the windows builds so we can determine what we plan to support going forward.<div><br></div><div>Thanks</div><div>Mike</div><div><br></div><div><a href="https://chocolatey.org/" target="_blank">https://chocolatey.org/</a></div><div><a href="http://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx" target="_blank">http://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx</a></div></div></blockquote></div></div></div></blockquote></div></div></span></div><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br></blockquote></div></div>