On 06/03/2019 18:39, Mark Roszko wrote: > Tom, > > Have you looked at vcpkg? > https://github.com/Microsoft/vcpkg > > It's basically Microsoft's C++ library manager that integrates with > CMake standalone and VS2017/VSCode/VS2019. > The downside is the libraries get built on each user's machine for a > given arch you specify but not that bad.
I don't understand the need for building the dependencies through a package manager. This is a must under Linux which is a moving target - different distributions use different versions, build options, etc. In the case of Windows builds, I would just release a binary archive of all dependencies (with instructions how to rebuild it from scratch for the brave/curious). It's a tedious process, especially if Python comes into play, so I'd rather spare this to "ordinary" programmers. Tom > > > > On Wed, Mar 6, 2019 at 12:17 PM Tomasz Wlostowski > <[email protected] <mailto:[email protected]>> wrote: > > Hi, > > This patchset enables building KiCad in MS Visual Studio (version 2017, > not tested on earlier versions). It is largely based on patches & > library builds by Simon Richter (thanks a lot!), with some improvements: > - no MSVC-specific patches other than setting the compiler parameters. > - no need for require boost::context workarounds as libcontext now > supports MSVC through native Windows Fiber API. > - prebuilt environment [1], containing the right versions of libraries > and tools (CMake & CMake modules). The supplied libraries currently > support only debug x86_64 targets. > > Some of you might ask why bother with MSVC support? Here's a bunch of > reasons: > - A debugger that really works. GDB under Windows offers, > euphemistically speaking, sub-optimal user experience (very slow, Ctrl-C > kills the debugger instead of stopping the application being debugged, > enormous size of debug symbols). > - Much faster builds. GCC is very fast under Unix systems, but under > Unix emulation (MINGW) all the speed disappears. > - MSVC runtime libraries are quite different from the GNU/OSX ones. This > has already led to discovery of some critical bugs (StrNumCmp()). In > general. Building and testing KiCad with a non-GCC/Clang compiler can > only improve the quality of our code. > - I'm hoping new developers will join us. After all, 90% of desktop > software is made for Windows, most of it is written in VS and proficient > developers don't like switching their IDEs too often. > > Happy testing, > Tom > > PS. Could someone of our website maintainers give some space to host the > archive [1] on kicad-pcb.org <http://kicad-pcb.org>? > > [1] https://cernbox.cern.ch/index.php/s/UaFwaznK4258kZC > > > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > > -- > Mark _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
