kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #14328
Re: KiCad build.
All,
I am actually pretty far along with this separation of build. Is there a recommended location I could post some files so you could see how I approached it? I basically expanded the kicad-install.sh script with additional steps. One of the main things I do is I work with completely clean setups in virtual machines. That lets me check for dependencies that the average user might not have installed. I am furthest along on OS X (I am working out how to build a signed, drag and drop package containing all of the new modular programs.) I have it working on Linux although I do not have the Debian and RPM installers running yet. I am furthest from finishing on Windows.
Michael
On Aug 16, 2014, at 3:11 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
> On 8/16/2014 3:07 PM, Jason Whiteman wrote:
>> 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.
>
> That is one of the goals. The current situation contains a bunch of
> platform specific checks which break on other platforms or cross builds.
> This in and of itself is just plain wrong and probably what you have
> been experiencing. I know that it has been a thorn in my side for some
> time now. Testing for platforms in build tools be it CMake, autoconf,
> scons, etc. is broken by design. The general rule of thumb for
> configuration tools is test for features not platforms. If you don't
> understand how to configure you platform to build KiCad, it is your
> responsibility as a developer to correct and should not be part of the
> build configuration of KiCad. While I can sympathize with the plight of
> inexperienced developers, the only thing the KiCad build configuration
> should do is make sure you have the appropriate dependencies installed
> on your platform to build KiCad.
>
>>
>> Regards,
>> Jason
>>
>>
>>
>> On Sat, Aug 16, 2014 at 11:44 AM, Wayne Stambaugh
>> <stambaughw@xxxxxxxxxxx <mailto: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
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
>
> _______________________________________________
> 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
Follow ups
References