kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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 <stambaughw@xxxxxxxxxxx> 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