kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/16/2014 3:27 PM, Dick Hollenbeck wrote:
> On 08/16/2014 11:44 AM, Wayne Stambaugh 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
> 
> 
> I empathize with you.  I say you simply put your foot down.  This is one of those "Linus
> sends the ARM maintainers back to the drawing board with device tree" moments.  Except
> that CMake is better than device tree.  Here the Mac and windows builders have to pay.
> 
> 
> My suggestions:
> 
> Really you Wayne could just delete stuff you don't want in there.  Then do a diff.  Take
> the negative of the diff and make that a second CMake "kicad prerequisites" builder.    So
> it gets split into two builders, and initially the second half will not work, but the Mac
> and Windows guys can clean it up.

That was my thinking.  Except for Boost, I have had very few problems
building dependency libraries with MinGW on Windows.  I'm even having
trouble understanding what the issue is on OSX.  All the KiCad
dependency libraries except Boost, wxWidgets, and wxPython can be built
on OSX without any patching if I'm reading the download_foo.cmake files
correctly.  That would indicate that configure && make && make install
should do the trick.  Am I missing something on OSX?  Does CMake not set
the proper system paths to where the headers and library files are
installed.  Given what I have seen in our CMake files, that appears to
be the case.

> 
> After all from your perspective you are not breaking anything, you are restoring order to
> a build system you've used for years without issue until recently.

That is my frustration.  We are using the KiCad build configuration tool
as a platform configuration tool and we are paying the price for that
decision.

> 
> But caution.  CMake is an awesome builder.  One should not assume that anything in there
> is expendable.  Its all very valuable information, it just needs to be separated out.  I
> would also say that this is NOT a platform specific discussion.

Exactly.  My guess is that if your platform is configured correctly,
CMake will gather all of the appropriate pieces together in order to
create a correct build configuration for KiCad.  Not the other way
around which is the direction we are heading.  The goal is to root out
the platform specific stuff that is breaking configuration and building
on other platforms.

> 
> If someone wants to build a windows KiCad on linux, then they certainly have few to no
> previously installed packages and the knowledge embodied in these recipes is critical (and
> cross-platform/cross-compiling with minor work).

When you cross build Mingw on linux, the libraries are still installed
in the proper target platform paths so that when you specify a build
target, CMake knows where to find them without requiring any special
configuration irregardless of the host.

> 
> Each external_project in the second build system could be Yes/No selectable.  It is a real
> opportunity for a someone to develop a valuable tool that would extend beyond KiCad.  And
> maybe some of the folks that put together CMake would be willing to offer help and advice.
>  There are some advanced ways for information to flow from the first pass builder into the
> kicad builder.

I'm all for creating an external tool for developers who aren't
interesting in having fine grain control over there build environment.
I doubt I would ever use it but I do understand the value of such a tool
for new developers.  It might be useful for the guys who run auto
builders as well.  I would also expect experience developers to
understand how to properly build and install development libraries on
their systems.  This includes how to use temporary and custom libraries
that do not replace the system libraries for testing purposes.

> 
> This is an opportunity for many and for much.   It is also potentially a junk yard, unless
> enough step up to pick up the pieces.  I won't be able to help, but I see much promise in
> this.

As long as the repo lives, nothing is completely lost.  Initially, I
plan to systematically disconnect the download_foo.cmake files and
related platform specific code and use find_package accordingly.  I also
plan on fixing some really poorly design FindFoo.cmake files so that
they work properly on all properly configured platforms.  I'll keep the
legacy cmake stuff around long enough so that developers working on
platform specific build tools can extract the information they need.

> 
> Certainly the MAC developers have the most to lose here, and with a little help can keep
> this from becoming a catastrophic blow to the KiCad Mac support.  While at the same time
> bringing value to the Mac and Windows platforms for a broad range of other projects.

My guess is that done properly, this will bring value to OSX in the long
term.  In the short term I expect wailing and gnashing of teeth.  I
think windows is pretty well covered by Brian's winbuilder.  I suspect
that one of the issues with development on OSX is a lack of experience
using the platform properly.  OSX is after all a variant of UNIX (BSD I
believe) so my guess is the key to getting things set up properly is
understanding where all of the libraries need to be installed for CMake
to find them without any special changes to find package files.  The way
everything else is standardized on OSX, I find it hard to believe that
there are not standardized paths for install development headers and
libraries.

> 
> 
> Dick