I'm not sure if I'm in the minority - but I have deferred work due to build issues with the dependencies. I'm capable of sorting this out myself - but wasn't willing to invest the time beyond what I had already invested in order to move forward. Your decoupling will lead to more burden on the developer for builds -- but perhaps the new structure will eventually change the paradigm and allow for easier management of platform-specific build requirements.
Thumbs up on any work to arrive at this goal. Regards, Jason On Sat, Aug 16, 2014 at 11:44 AM, Wayne Stambaugh <stambau...@verizon.net> wrote: > One of the tasks that I have committed to working on in the KiCad road > map is to clean up the current mess we have created by allowing > dependency libraries to be built as part of the KiCad source build. The > only exception I see for the time being is Boost. Although I am have my > reservations on that as well. Why you ask? I've spent several days > trying to get KiCad to build on Windows using MSYS2 as my build > environment and mingw64 as my target environment. Every single library > dependency with the exception of our custom Boost and avhttp (which > could easily be build and installed using CMake) are already packaged > for me. However, the current KiCad build insists on downloading and > building some libraries from source that are already installed. This is > silly. I can resolve the issues by passing all of the > PACKAGE_ROOT_PATHs when I run CMake but that is silly as well since my > build environment already points the correct path. > > Originally I intended to create a separate project to build the KiCad > library dependencies but I have since changed my mind. I do *not* think > it is asking too much of developers to learn how to build and/or install > libraries on their preferred platform. If as a developer you must have > this done for you automatically, I am going to please ask that *you* > create a separate platform specific build tool such as the excellent > kicad-winbuilder that Brian has created. This will significantly > simplify the KiCad CMake files and eliminate the situation I described > above. My preference and goal is that the KiCad CMake files be used to > build KiCad, not library dependencies. > > Initially, I plan to remove the dependencies that do not require any > patching to build which currently are avhttp, swig, cairo, libpng, > pixman, pcre, pkgconfig, and glew. Then I will remove the dependencies > with platform specific patches which are openssl, wxwidgets and > wxpython. Then I will try to figure out what to do with the problem > child that is Boost. I would also suggest that all platform specific > library dependency build patches be remove as well leaving only the > Boost patches that are required for all platforms (except the context > switching patches). > > My goal here is not to step on anyone's toes it is to get our build > system under control so that I can build *KiCad* rather than figure out > how to get the dependencies to build or not as the platform dictates. I > expect our code to be well designed and I don't think expecting the same > from our build system design is out of line. If any one has major > objections then we will have to figure something out because I am not > going to continue to spend valuable time fighting our build tools to get > them to properly use the dependencies already installed on my platform. > > Wayne > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp