On 08/19/2014 03:37 PM, Wayne Stambaugh wrote: > On 8/19/2014 4:17 PM, Dick Hollenbeck wrote: >> On 08/18/2014 06:47 PM, Wayne Stambaugh wrote: >>> On 8/18/2014 6:45 PM, Brian Sidebotham wrote: >>>> On 16 August 2014 17:44, 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 >>>>> >>>> >>>> Hi Wayne, >>>> >>>> I think that sounds like a sane decision, although of course KiCad >>>> will be subject to the bugs in other libraries, but it's up to >>>> distribution maintainers to sort those out in my opinion. >>>> >>>> I hope that we can use some sort of deprecation system, please mark a >>>> lib as being deprecated so that I can sort out Winbuilder before the >>>> CMake system is broke. It's much easier to work that way round as >>>> opposed to a reactionary approach where we break everything and then >>>> everyone has to fix their build before being able to do anything. I >>>> will do the leg work to keep the Winbuilder people happy and do any >>>> projects necessary to package dependencies required by it. >>> >>> I will be making changes very slowly because I expect there to be some >>> breakage with some of the FindFoo.cmake changes I'm going to make. This >>> will give everyone time to respond should I break anything. I will be >>> pushing hard against adding personal install paths to every >>> FindFoo.cmake file. CMake knows how to find the correct default paths >>> on most platforms and I will always give the developer the chance to >>> override those using either and environment variable or a definition on >>> the CMake command line for custom library testing. I will start out >>> with the dependencies that don't require any patches to build and then >>> address the more complex ones like wxWidgets and finish up with the >>> nightmare that is Boost. If I change more than one FindFoo.cmake every >>> two weeks, that will be a blistering pace. The goal is to get each >>> dependency test working and properly designed before moving to the next one. >>> >>> Cheers, >>> >>> Wayne >> >> >> The current thinking among those using CMake for several large projects is >> that it can >> either find or it can build in the first pass. It struggles with finding a >> prerequisite >> and building the prerequisite as a fallback, then continuing to build that >> which does the >> depending. This is why when you dig into it, quite a number of larger >> projects have split >> their CMake builders into two. Sometimes this is done with or without a 3rd >> umbrella >> builder on top of the two. >> >> a) prerequisite builder >> b) core project builder > > I would be happy if b) would work well on every platform where the > developer had the appropriate prerequisites already built and installed. > As far as a) goes, I would prefer that this be completely separate code > and not a requirement to build KiCad.
They are called prerequisites because they are. I don't begin to understand this statement. It's like saying I wish my car never ran out of gas, so therefore I won't buy any. The prerequisites have to come from somewhere, the gas has to come from somewhere. Your statement confuses me to the point where I think its time for others to take up the mantle here. You folks have a difficult struggle ahead. Again, somebody needs to get on the phone with kitware and get their advice and help. You have the pieces, you need the expertise and help. I am out on this topic, I tried. I don't feel like I succeeded. Dick _______________________________________________ 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
