kicad-developers team mailing list archive

[Jason Whiteman <whitemanjason@xxxxxxxxx>]

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 <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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>