kicad-developers team mailing list archive

[Michael Narigon <mnarigon@xxxxxxxxx>]

Wayne, other developers,

Here is the repo: https://code.launchpad.net/~mnarigon/+junk/kicad-dev.

You can get this branch to get the tar file. Untar the file to create the directory structure. At the top level there is the build.sh file that contains the build script. If you run this with no arguments it will go through the steps to configure the environment, check pre-requisites, build tools, build libraries, get a kicad mirror, make a source directory, and build the KiCad sources. The build script doesn’t need sudo except for one step. It will let you know if it needs sudo.

It is alpha-quality in that install doesn’t work. Also, the debug build doesn’t work. I am furthest along on OS X and Linux. The check for pre-requisites is set up for Windows, but I do not have any of the Windows build working because I need to work out the compilers on cygwin/Windows.

I am currently working on creating OS X drag-and-drop installers that are signed and will automatically unpack. Once I get that working the Linux (and FreeBSD installers) are next. Then I was going to turn my attention to the Windows build.

You can see from the steps how I broke out the libraries that are either debian package installs or built separately from the KiCad source. Use build.sh -h to see the options. Usually, once I have the tools and libraries build I just use ./build.sh -k to build KiCad.

I want to get the OS X and Linux installs working before I publish.  Michael

On Aug 17, 2014, at 7:48 AM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:

> 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
>> 
>> 
> 
> 
> _______________________________________________
> 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