kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/16/2014 8:41 PM, Michael Narigon wrote:
> It appears that I can push the files to launchpad. I will make sure the Linux version builds and load it up so you can look at it to see if it is useful.  Michael

Thanks.  I'll take a look at it once you push it to launchpad.  Please
post the repo name once you get it pushed.  Maybe the folks who are
working on auto builders can take a look at it and see if there is
anything that would be helpful to them as well.

> 
> On Aug 16, 2014, at 5:15 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
> 
>> On 8/16/2014 6:28 PM, Michael Narigon wrote:
>>> 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.
>>
>> Feel free to post them to the mailing list so other developers can take
>> a look at them.  I prefer your build script solution what we are
>> currently doing.  If they prove to be useful, we could include them with
>> the other scripts that we provide.  If you have a nearly complete OSX
>> solution, I'm sure our OSX developers would like to take a look at what
>> you've done so far because they will be impacted the most by the changes
>> I am going to make.  Maybe your build scripts will help ease the
>> transition.  If you've modified any CMake files, please post the diffs
>> so I can see what you've changed and what impact the changes I am
>> planning to make will effect what you've done so far.
>>
>> Thanks,
>>
>> Wayne
>>
>>>
>>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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
> 
>