Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Babar Malik]

Thank you Nick,
But I am still figuring out the problem.



Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford

On 29 January 2018 at 18:42, Nick Østergaard  wrote:

> In the future, remember to state your goal and expectation when asking
> these sort of questions. I will make it easier for people to help you.
>
> 2018-01-29 11:30 GMT+01:00 Babar Malik :
>
>> Dear Jean,
>> Thank you so much, you are right as i am able to install these packages.
>> I was facing this problem from three days and you provided a quick
>> solution. Thanks a lot for the help. :)
>>
>> Regards,
>> Babar Malik.
>>
>> Best Regards,
>> Muhammad Babar Malik
>> Namal College Mianwali
>> An Associate College of University of Bradford
>>
>> On 29 January 2018 at 15:16, Jean-Samuel Reynaud 
>> wrote:
>>
>>> Hi Babar,
>>>
>>> As far as I know, on ubuntu 14.04, those packages version are not
>>> available. You can install manually backports from adam's ppa:
>>>
>>> https://launchpad.net/~adamwolf/+archive/ubuntu/kicad-trusty-backports
>>>
>>> or from KiCad's PPA:
>>> https://launchpad.net/~js-reynaud/+archive/ubuntu/ppa-kicad
>>> But this last PPA include also KiCad himself...
>>>
>>> Regards,
>>> Le 29/01/2018 à 08:35, Babar Malik a écrit :
>>> > HI,
>>> > its sill the same error which can be seen below
>>> > "*E: Unable to locate package python-wxgtk3.0-dev*
>>> > *E: Couldn't find any package by regex 'python-wxgtk3.0-dev'"*
>>> > *
>>> > *
>>> > *Regards,*
>>> > *Babar Malik.*
>>> >
>>> > Best Regards,
>>> > Muhammad Babar Malik
>>> > Namal College Mianwali
>>> > An Associate College of University of Bradford
>>> >
>>> > On 29 January 2018 at 12:26, jp charras >> > > wrote:
>>> >
>>> > Le 29/01/2018 à 08:08, Babar Malik a écrit :
>>> > > Thank you so much Carsten,
>>> > > I have installed all the other packages but the only problem is
>>> with "python-wxgtk3.0-dev" when i
>>> > > try to install this the terminal shows me the following error
>>> message
>>> > > "*E: Unable to locate package pythton-wxgtk3.0-dev*
>>> > > *E: Couldn't find any package by regex 'pythton-wxgtk3.0-dev*"
>>> > >
>>> > > Please help me to solve this issue.
>>> > > Regards,
>>> > > Babar Malik.
>>> > >
>>> >
>>> > "python-wxgtk3.0-dev", not "pythton-wxgtk3.0-dev"
>>> >
>>> > > Best Regards,
>>> > > Muhammad Babar Malik
>>> > > Namal College Mianwali
>>> > > An Associate College of University of Bradford
>>> > >
>>> > > On 29 January 2018 at 11:19, Carsten Schoenert <
>>> c.schoen...@t-online.de 
>>> > > >>
>>> wrote:
>>> > >
>>> > > Hello Babar,
>>> > >
>>> > > Am 29.01.2018 <29%2001%2020%2018> um 05:12 schrieb Babar
>>> Malik:
>>> > > > I have tried a lot to install wxPython 3.0 but none of the
>>> solution is
>>> > > > working. Can you please suggest any solution?
>>> > >
>>> > > but you have not installed the package Maciej has suggested?
>>> If you ask
>>> > > for help please give us all information what you have done
>>> (or tried to
>>> > > do) and also the error messages you see.
>>> > >
>>> > > You will need all of the following packages have installed
>>> on your
>>> > > system to get a recent version of KiCad nightly/development
>>> built on a
>>> > > recent Ubuntu or Debian stretch or testing system.
>>> > >
>>> > > > $ sudo apt install cmake doxygen libboost-context-dev
>>> libboost-dev \
>>> > > > libboost-system-dev libboost-test-dev libcairo2-dev
>>> libcurl4-openssl-dev \
>>> > > > libgl1-mesa-dev libglew-dev libglm-dev
>>> liboce-foundation-dev liboce-ocaf-dev \
>>> > > > libssl-dev libwxbase3.0-dev libwxgtk3.0-dev python-dev
>>> python-wxgtk3.0-dev \
>>> > > > swig wx-common
>>> > >
>>> > > --
>>> > > Regards
>>> > > Carsten Schoenert
>>> > >
>>> > > ___
>>> > > Mailing list: https://launchpad.net/~kicad-developers
>>> > 
>>> > >> > >
>>> > > Post to : kicad-developers@lists.launchpad.net
>>> > 
>>> > >> > >
>>> > > Unsubscribe : https://launchpad.net/~kicad-developers
>>> > 
>>> > >> > >
>>> > > More help   : https://help.launchpad.net/ListHelp
>>> > 
>>> > 

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Nick Østergaard]

In the future, remember to state your goal and expectation when asking
these sort of questions. I will make it easier for people to help you.

2018-01-29 11:30 GMT+01:00 Babar Malik :

> Dear Jean,
> Thank you so much, you are right as i am able to install these packages. I
> was facing this problem from three days and you provided a quick solution.
> Thanks a lot for the help. :)
>
> Regards,
> Babar Malik.
>
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
>
> On 29 January 2018 at 15:16, Jean-Samuel Reynaud 
> wrote:
>
>> Hi Babar,
>>
>> As far as I know, on ubuntu 14.04, those packages version are not
>> available. You can install manually backports from adam's ppa:
>>
>> https://launchpad.net/~adamwolf/+archive/ubuntu/kicad-trusty-backports
>>
>> or from KiCad's PPA:
>> https://launchpad.net/~js-reynaud/+archive/ubuntu/ppa-kicad
>> But this last PPA include also KiCad himself...
>>
>> Regards,
>> Le 29/01/2018 à 08:35, Babar Malik a écrit :
>> > HI,
>> > its sill the same error which can be seen below
>> > "*E: Unable to locate package python-wxgtk3.0-dev*
>> > *E: Couldn't find any package by regex 'python-wxgtk3.0-dev'"*
>> > *
>> > *
>> > *Regards,*
>> > *Babar Malik.*
>> >
>> > Best Regards,
>> > Muhammad Babar Malik
>> > Namal College Mianwali
>> > An Associate College of University of Bradford
>> >
>> > On 29 January 2018 at 12:26, jp charras > > > wrote:
>> >
>> > Le 29/01/2018 à 08:08, Babar Malik a écrit :
>> > > Thank you so much Carsten,
>> > > I have installed all the other packages but the only problem is
>> with "python-wxgtk3.0-dev" when i
>> > > try to install this the terminal shows me the following error
>> message
>> > > "*E: Unable to locate package pythton-wxgtk3.0-dev*
>> > > *E: Couldn't find any package by regex 'pythton-wxgtk3.0-dev*"
>> > >
>> > > Please help me to solve this issue.
>> > > Regards,
>> > > Babar Malik.
>> > >
>> >
>> > "python-wxgtk3.0-dev", not "pythton-wxgtk3.0-dev"
>> >
>> > > Best Regards,
>> > > Muhammad Babar Malik
>> > > Namal College Mianwali
>> > > An Associate College of University of Bradford
>> > >
>> > > On 29 January 2018 at 11:19, Carsten Schoenert <
>> c.schoen...@t-online.de 
>> > > >>
>> wrote:
>> > >
>> > > Hello Babar,
>> > >
>> > > Am 29.01.2018 <29%2001%2020%2018> um 05:12 schrieb Babar
>> Malik:
>> > > > I have tried a lot to install wxPython 3.0 but none of the
>> solution is
>> > > > working. Can you please suggest any solution?
>> > >
>> > > but you have not installed the package Maciej has suggested?
>> If you ask
>> > > for help please give us all information what you have done
>> (or tried to
>> > > do) and also the error messages you see.
>> > >
>> > > You will need all of the following packages have installed on
>> your
>> > > system to get a recent version of KiCad nightly/development
>> built on a
>> > > recent Ubuntu or Debian stretch or testing system.
>> > >
>> > > > $ sudo apt install cmake doxygen libboost-context-dev
>> libboost-dev \
>> > > > libboost-system-dev libboost-test-dev libcairo2-dev
>> libcurl4-openssl-dev \
>> > > > libgl1-mesa-dev libglew-dev libglm-dev
>> liboce-foundation-dev liboce-ocaf-dev \
>> > > > libssl-dev libwxbase3.0-dev libwxgtk3.0-dev python-dev
>> python-wxgtk3.0-dev \
>> > > > swig wx-common
>> > >
>> > > --
>> > > Regards
>> > > Carsten Schoenert
>> > >
>> > > ___
>> > > Mailing list: https://launchpad.net/~kicad-developers
>> > 
>> > > > >
>> > > Post to : kicad-developers@lists.launchpad.net
>> > 
>> > > > >
>> > > Unsubscribe : https://launchpad.net/~kicad-developers
>> > 
>> > > > >
>> > > More help   : https://help.launchpad.net/ListHelp
>> > 
>> > > > >
>> > >
>> > >
>> > >
>> > >
>> > > ___
>> > > Mailing list: https://launchpad.net/~kicad-developers
>> > 
>> > > Post to : kicad-developers@lists.launchpad.net

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Babar Malik]

Dear Jean,
Thank you so much, you are right as i am able to install these packages. I
was facing this problem from three days and you provided a quick solution.
Thanks a lot for the help. :)

Regards,
Babar Malik.

Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford

On 29 January 2018 at 15:16, Jean-Samuel Reynaud 
wrote:

> Hi Babar,
>
> As far as I know, on ubuntu 14.04, those packages version are not
> available. You can install manually backports from adam's ppa:
>
> https://launchpad.net/~adamwolf/+archive/ubuntu/kicad-trusty-backports
>
> or from KiCad's PPA:
> https://launchpad.net/~js-reynaud/+archive/ubuntu/ppa-kicad
> But this last PPA include also KiCad himself...
>
> Regards,
> Le 29/01/2018 à 08:35, Babar Malik a écrit :
> > HI,
> > its sill the same error which can be seen below
> > "*E: Unable to locate package python-wxgtk3.0-dev*
> > *E: Couldn't find any package by regex 'python-wxgtk3.0-dev'"*
> > *
> > *
> > *Regards,*
> > *Babar Malik.*
> >
> > Best Regards,
> > Muhammad Babar Malik
> > Namal College Mianwali
> > An Associate College of University of Bradford
> >
> > On 29 January 2018 at 12:26, jp charras  > > wrote:
> >
> > Le 29/01/2018 à 08:08, Babar Malik a écrit :
> > > Thank you so much Carsten,
> > > I have installed all the other packages but the only problem is
> with "python-wxgtk3.0-dev" when i
> > > try to install this the terminal shows me the following error
> message
> > > "*E: Unable to locate package pythton-wxgtk3.0-dev*
> > > *E: Couldn't find any package by regex 'pythton-wxgtk3.0-dev*"
> > >
> > > Please help me to solve this issue.
> > > Regards,
> > > Babar Malik.
> > >
> >
> > "python-wxgtk3.0-dev", not "pythton-wxgtk3.0-dev"
> >
> > > Best Regards,
> > > Muhammad Babar Malik
> > > Namal College Mianwali
> > > An Associate College of University of Bradford
> > >
> > > On 29 January 2018 at 11:19, Carsten Schoenert <
> c.schoen...@t-online.de 
> > > >>
> wrote:
> > >
> > > Hello Babar,
> > >
> > > Am 29.01.2018 um 05:12 schrieb Babar Malik:
> > > > I have tried a lot to install wxPython 3.0 but none of the
> solution is
> > > > working. Can you please suggest any solution?
> > >
> > > but you have not installed the package Maciej has suggested?
> If you ask
> > > for help please give us all information what you have done (or
> tried to
> > > do) and also the error messages you see.
> > >
> > > You will need all of the following packages have installed on
> your
> > > system to get a recent version of KiCad nightly/development
> built on a
> > > recent Ubuntu or Debian stretch or testing system.
> > >
> > > > $ sudo apt install cmake doxygen libboost-context-dev
> libboost-dev \
> > > > libboost-system-dev libboost-test-dev libcairo2-dev
> libcurl4-openssl-dev \
> > > > libgl1-mesa-dev libglew-dev libglm-dev liboce-foundation-dev
> liboce-ocaf-dev \
> > > > libssl-dev libwxbase3.0-dev libwxgtk3.0-dev python-dev
> python-wxgtk3.0-dev \
> > > > swig wx-common
> > >
> > > --
> > > Regards
> > > Carsten Schoenert
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > 
> >  > >
> > > Post to : kicad-developers@lists.launchpad.net
> > 
> >  > >
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> >  > >
> > > More help   : https://help.launchpad.net/ListHelp
> > 
> >  > >
> > >
> > >
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > > Post to : kicad-developers@lists.launchpad.net
> > 
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > > More help   : https://help.launchpad.net/ListHelp
> > 
> > >
> >
> >
> > --
> > Jean-Pierre CHARRAS
> >
> > ___

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Jean-Samuel Reynaud]

Hi Babar,

As far as I know, on ubuntu 14.04, those packages version are not
available. You can install manually backports from adam's ppa:

https://launchpad.net/~adamwolf/+archive/ubuntu/kicad-trusty-backports

or from KiCad's PPA:
https://launchpad.net/~js-reynaud/+archive/ubuntu/ppa-kicad
But this last PPA include also KiCad himself...

Regards,
Le 29/01/2018 à 08:35, Babar Malik a écrit :
> HI,
> its sill the same error which can be seen below
> "*E: Unable to locate package python-wxgtk3.0-dev*
> *E: Couldn't find any package by regex 'python-wxgtk3.0-dev'"*
> *
> *
> *Regards,*
> *Babar Malik.*
> 
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
> 
> On 29 January 2018 at 12:26, jp charras  > wrote:
> 
> Le 29/01/2018 à 08:08, Babar Malik a écrit :
> > Thank you so much Carsten,
> > I have installed all the other packages but the only problem is with 
> "python-wxgtk3.0-dev" when i
> > try to install this the terminal shows me the following error message
> > "*E: Unable to locate package pythton-wxgtk3.0-dev*
> > *E: Couldn't find any package by regex 'pythton-wxgtk3.0-dev*"
> >
> > Please help me to solve this issue. 
> > Regards, 
> > Babar Malik. 
> >
> 
> "python-wxgtk3.0-dev", not "pythton-wxgtk3.0-dev"
> 
> > Best Regards,
> > Muhammad Babar Malik
> > Namal College Mianwali
> > An Associate College of University of Bradford
> >
> > On 29 January 2018 at 11:19, Carsten Schoenert  
> > >> 
> wrote:
> >
> >     Hello Babar,
> >
> >     Am 29.01.2018 um 05:12 schrieb Babar Malik:
> >     > I have tried a lot to install wxPython 3.0 but none of the 
> solution is
> >     > working. Can you please suggest any solution?
> >
> >     but you have not installed the package Maciej has suggested? If you 
> ask
> >     for help please give us all information what you have done (or 
> tried to
> >     do) and also the error messages you see.
> >
> >     You will need all of the following packages have installed on your
> >     system to get a recent version of KiCad nightly/development built 
> on a
> >     recent Ubuntu or Debian stretch or testing system.
> >
> >     > $ sudo apt install cmake doxygen libboost-context-dev 
> libboost-dev \
> >     > libboost-system-dev libboost-test-dev libcairo2-dev 
> libcurl4-openssl-dev \
> >     > libgl1-mesa-dev libglew-dev libglm-dev liboce-foundation-dev 
> liboce-ocaf-dev \
> >     > libssl-dev libwxbase3.0-dev libwxgtk3.0-dev python-dev 
> python-wxgtk3.0-dev \
> >     > swig wx-common
> >
> >     --
> >     Regards
> >     Carsten Schoenert
> >
> >     ___
> >     Mailing list: https://launchpad.net/~kicad-developers
> 
>  >
> >     Post to     : kicad-developers@lists.launchpad.net
> 
>  >
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> 
>  >
> >     More help   : https://help.launchpad.net/ListHelp
> 
>  >
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> 
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> 
> > More help   : https://help.launchpad.net/ListHelp
> 
> >
> 
> 
> --
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-devel

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Nick Østergaard]

Read the error message and try to figure out what is missing. I should be a
good excercise for you. :)

Den 29. jan. 2018 08.39 skrev "Babar Malik" :

I turned off python then the kicad was built sucessfully. But when i used
"make" command after building it, it shown following error message.
"*[  0%] creating 'boost scratch repo' specifically for boost to track
boost patches*
*/bin/sh: 1: bzr: not found*
*make[2]: ***
[../../.downloads-by-cmake/boost_1_54_0/src/boost-stamp/boost-bzr_init_boost]
Error 127*
*make[1]: *** [CMakeFiles/boost.dir/all] Error 2*
*make: *** [all] Error 2*
"
Can you please have a look on that?
I will be really thankful for the assistance.

Regards,
Babar Malik.

Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford

On 26 January 2018 at 19:03, Jeff Young  wrote:

> If you don’t need Python you can turn it off by adding:
>
> -DKICAD_SCRIPTING_WXPYTHON=OFF
>
> to your cmake command.
>
> Might be a short-term solution until someone who knows Ubuntu can help get
> you up and running.
>
> Cheers,
> Jeff
>
> On 26 Jan 2018, at 13:45, Babar Malik  wrote:
>
> Dear all,
> I am trying to build Kicad on Ubuntu 14.04 but I am facing a problem with
> "wxPython". I tried a lot to install this package but the problem is still
> here. The exact error shown on the terminal is *"CMake Error at
> CMakeLists.txt:708 (message):*
> *  wxPython version 3.0 does not appear to be installed on the system.*
> *"*
> Can anyone please suggest me the solution. Your assistance will be highly
> appreciated.
>
>
>
>
>
>
>
>
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Babar Malik]

I turned off python then the kicad was built sucessfully. But when i used
"make" command after building it, it shown following error message.
"*[  0%] creating 'boost scratch repo' specifically for boost to track
boost patches*
*/bin/sh: 1: bzr: not found*
*make[2]: ***
[../../.downloads-by-cmake/boost_1_54_0/src/boost-stamp/boost-bzr_init_boost]
Error 127*
*make[1]: *** [CMakeFiles/boost.dir/all] Error 2*
*make: *** [all] Error 2*
"
Can you please have a look on that?
I will be really thankful for the assistance.

Regards,
Babar Malik.

Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford

On 26 January 2018 at 19:03, Jeff Young  wrote:

> If you don’t need Python you can turn it off by adding:
>
> -DKICAD_SCRIPTING_WXPYTHON=OFF
>
> to your cmake command.
>
> Might be a short-term solution until someone who knows Ubuntu can help get
> you up and running.
>
> Cheers,
> Jeff
>
> On 26 Jan 2018, at 13:45, Babar Malik  wrote:
>
> Dear all,
> I am trying to build Kicad on Ubuntu 14.04 but I am facing a problem with
> "wxPython". I tried a lot to install this package but the problem is still
> here. The exact error shown on the terminal is *"CMake Error at
> CMakeLists.txt:708 (message):*
> *  wxPython version 3.0 does not appear to be installed on the system.*
> *"*
> Can anyone please suggest me the solution. Your assistance will be highly
> appreciated.
>
>
>
>
>
>
>
>
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Babar Malik]

HI,
its sill the same error which can be seen below
"*E: Unable to locate package python-wxgtk3.0-dev*
*E: Couldn't find any package by regex 'python-wxgtk3.0-dev'"*

*Regards,*
*Babar Malik.*

Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford

On 29 January 2018 at 12:26, jp charras  wrote:

> Le 29/01/2018 à 08:08, Babar Malik a écrit :
> > Thank you so much Carsten,
> > I have installed all the other packages but the only problem is with
> "python-wxgtk3.0-dev" when i
> > try to install this the terminal shows me the following error message
> > "*E: Unable to locate package pythton-wxgtk3.0-dev*
> > *E: Couldn't find any package by regex 'pythton-wxgtk3.0-dev*"
> >
> > Please help me to solve this issue.
> > Regards,
> > Babar Malik.
> >
>
> "python-wxgtk3.0-dev", not "pythton-wxgtk3.0-dev"
>
> > Best Regards,
> > Muhammad Babar Malik
> > Namal College Mianwali
> > An Associate College of University of Bradford
> >
> > On 29 January 2018 at 11:19, Carsten Schoenert  > > wrote:
> >
> > Hello Babar,
> >
> > Am 29.01.2018 um 05:12 schrieb Babar Malik:
> > > I have tried a lot to install wxPython 3.0 but none of the
> solution is
> > > working. Can you please suggest any solution?
> >
> > but you have not installed the package Maciej has suggested? If you
> ask
> > for help please give us all information what you have done (or tried
> to
> > do) and also the error messages you see.
> >
> > You will need all of the following packages have installed on your
> > system to get a recent version of KiCad nightly/development built on
> a
> > recent Ubuntu or Debian stretch or testing system.
> >
> > > $ sudo apt install cmake doxygen libboost-context-dev libboost-dev
> \
> > > libboost-system-dev libboost-test-dev libcairo2-dev
> libcurl4-openssl-dev \
> > > libgl1-mesa-dev libglew-dev libglm-dev liboce-foundation-dev
> liboce-ocaf-dev \
> > > libssl-dev libwxbase3.0-dev libwxgtk3.0-dev python-dev
> python-wxgtk3.0-dev \
> > > swig wx-common
> >
> > --
> > Regards
> > Carsten Schoenert
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/%7Ekicad-developers>
> > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/%7Ekicad-developers>
> > More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/ListHelp>
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[jp charras]

Le 29/01/2018 à 08:08, Babar Malik a écrit :
> Thank you so much Carsten,
> I have installed all the other packages but the only problem is with 
> "python-wxgtk3.0-dev" when i
> try to install this the terminal shows me the following error message
> "*E: Unable to locate package pythton-wxgtk3.0-dev*
> *E: Couldn't find any package by regex 'pythton-wxgtk3.0-dev*"
> 
> Please help me to solve this issue. 
> Regards, 
> Babar Malik. 
> 

"python-wxgtk3.0-dev", not "pythton-wxgtk3.0-dev"

> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
> 
> On 29 January 2018 at 11:19, Carsten Schoenert  > wrote:
> 
> Hello Babar,
> 
> Am 29.01.2018 um 05:12 schrieb Babar Malik:
> > I have tried a lot to install wxPython 3.0 but none of the solution is
> > working. Can you please suggest any solution?
> 
> but you have not installed the package Maciej has suggested? If you ask
> for help please give us all information what you have done (or tried to
> do) and also the error messages you see.
> 
> You will need all of the following packages have installed on your
> system to get a recent version of KiCad nightly/development built on a
> recent Ubuntu or Debian stretch or testing system.
> 
> > $ sudo apt install cmake doxygen libboost-context-dev libboost-dev \
> > libboost-system-dev libboost-test-dev libcairo2-dev 
> libcurl4-openssl-dev \
> > libgl1-mesa-dev libglew-dev libglm-dev liboce-foundation-dev 
> liboce-ocaf-dev \
> > libssl-dev libwxbase3.0-dev libwxgtk3.0-dev python-dev 
> python-wxgtk3.0-dev \
> > swig wx-common
> 
> --
> Regards
> Carsten Schoenert
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to     : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Marco Ciampa]

On Mon, Jan 29, 2018 at 09:16:30AM +0500, Babar Malik wrote:
> Hi dear,
> Where can I add this script,  on command line which is terminal in case of
> Ubutnu? Or i need to add this script in any file?

Try running:

cmake-gui

it should be easier to set.

PS: probably this is not the right place to post this questions, please
try a kicad user list or forum instead first...

Regards,


--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Marco Ciampa]

On Fri, Jan 26, 2018 at 03:18:32PM +0100, Maciej Sumiński wrote:
> Hi Babar,
> 
> You need to install wxPython development files, package
> python-wxgtk3.0-dev or similar.
> 

I confirm: exactly that package on an Ubuntu 16.04...

Regards,

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Babar Malik]

Thank you so much Carsten,
I have installed all the other packages but the only problem is with
"python-wxgtk3.0-dev" when i try to install this the terminal shows me the
following error message
"*E: Unable to locate package pythton-wxgtk3.0-dev*
*E: Couldn't find any package by regex 'pythton-wxgtk3.0-dev*"

Please help me to solve this issue.
Regards,
Babar Malik.

Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford

On 29 January 2018 at 11:19, Carsten Schoenert 
wrote:

> Hello Babar,
>
> Am 29.01.2018 um 05:12 schrieb Babar Malik:
> > I have tried a lot to install wxPython 3.0 but none of the solution is
> > working. Can you please suggest any solution?
>
> but you have not installed the package Maciej has suggested? If you ask
> for help please give us all information what you have done (or tried to
> do) and also the error messages you see.
>
> You will need all of the following packages have installed on your
> system to get a recent version of KiCad nightly/development built on a
> recent Ubuntu or Debian stretch or testing system.
>
> > $ sudo apt install cmake doxygen libboost-context-dev libboost-dev \
> > libboost-system-dev libboost-test-dev libcairo2-dev libcurl4-openssl-dev
> \
> > libgl1-mesa-dev libglew-dev libglm-dev liboce-foundation-dev
> liboce-ocaf-dev \
> > libssl-dev libwxbase3.0-dev libwxgtk3.0-dev python-dev
> python-wxgtk3.0-dev \
> > swig wx-common
>
> --
> Regards
> Carsten Schoenert
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Carsten Schoenert]

Hello Babar,

Am 29.01.2018 um 05:12 schrieb Babar Malik:
> I have tried a lot to install wxPython 3.0 but none of the solution is
> working. Can you please suggest any solution?

but you have not installed the package Maciej has suggested? If you ask
for help please give us all information what you have done (or tried to
do) and also the error messages you see.

You will need all of the following packages have installed on your
system to get a recent version of KiCad nightly/development built on a
recent Ubuntu or Debian stretch or testing system.

> $ sudo apt install cmake doxygen libboost-context-dev libboost-dev \
> libboost-system-dev libboost-test-dev libcairo2-dev libcurl4-openssl-dev \
> libgl1-mesa-dev libglew-dev libglm-dev liboce-foundation-dev liboce-ocaf-dev \
> libssl-dev libwxbase3.0-dev libwxgtk3.0-dev python-dev python-wxgtk3.0-dev \
> swig wx-common

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Babar Malik]

Hi dear,
Where can I add this script,  on command line which is terminal in case of
Ubutnu? Or i need to add this script in any file?

Regards,
Babar Malik.

Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford

On 26 January 2018 at 19:03, Jeff Young  wrote:

> If you don’t need Python you can turn it off by adding:
>
> -DKICAD_SCRIPTING_WXPYTHON=OFF
>
> to your cmake command.
>
> Might be a short-term solution until someone who knows Ubuntu can help get
> you up and running.
>
> Cheers,
> Jeff
>
> On 26 Jan 2018, at 13:45, Babar Malik  wrote:
>
> Dear all,
> I am trying to build Kicad on Ubuntu 14.04 but I am facing a problem with
> "wxPython". I tried a lot to install this package but the problem is still
> here. The exact error shown on the terminal is *"CMake Error at
> CMakeLists.txt:708 (message):*
> *  wxPython version 3.0 does not appear to be installed on the system.*
> *"*
> Can anyone please suggest me the solution. Your assistance will be highly
> appreciated.
>
>
>
>
>
>
>
>
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Babar Malik]

I have tried a lot to install wxPython 3.0 but none of the solution is
working. Can you please suggest any solution?

Regards,
Babar Malik.


Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford

On 26 January 2018 at 19:18, Maciej Sumiński 
wrote:

> Hi Babar,
>
> You need to install wxPython development files, package
> python-wxgtk3.0-dev or similar.
>
> Regards,
> Orson
>
> On 01/26/2018 02:45 PM, Babar Malik wrote:
> > Dear all,
> > I am trying to build Kicad on Ubuntu 14.04 but I am facing a problem with
> > "wxPython". I tried a lot to install this package but the problem is
> still
> > here. The exact error shown on the terminal is *"CMake Error at
> > CMakeLists.txt:708 (message):*
> > *  wxPython version 3.0 does not appear to be installed on the system.*
> > *"*
> > Can anyone please suggest me the solution. Your assistance will be highly
> > appreciated.
> >
> >
> >
> >
> >
> >
> >
> >
> > Best Regards,
> > Muhammad Babar Malik
> > Namal College Mianwali
> > An Associate College of University of Bradford
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Maciej Sumiński]

Hi Babar,

You need to install wxPython development files, package
python-wxgtk3.0-dev or similar.

Regards,
Orson

On 01/26/2018 02:45 PM, Babar Malik wrote:
> Dear all,
> I am trying to build Kicad on Ubuntu 14.04 but I am facing a problem with
> "wxPython". I tried a lot to install this package but the problem is still
> here. The exact error shown on the terminal is *"CMake Error at
> CMakeLists.txt:708 (message):*
> *  wxPython version 3.0 does not appear to be installed on the system.*
> *"*
> Can anyone please suggest me the solution. Your assistance will be highly
> appreciated.
> 
> 
> 
> 
> 
> 
> 
> 
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Build Issue on Ubuntu

[Jeff Young]

If you don’t need Python you can turn it off by adding:

-DKICAD_SCRIPTING_WXPYTHON=OFF

to your cmake command.

Might be a short-term solution until someone who knows Ubuntu can help get you 
up and running.

Cheers,
Jeff

> On 26 Jan 2018, at 13:45, Babar Malik  wrote:
> 
> Dear all,
> I am trying to build Kicad on Ubuntu 14.04 but I am facing a problem with 
> "wxPython". I tried a lot to install this package but the problem is still 
> here. The exact error shown on the terminal is "CMake Error at 
> CMakeLists.txt:708 (message):
>   wxPython version 3.0 does not appear to be installed on the system.
> "
> Can anyone please suggest me the solution. Your assistance will be highly 
> appreciated. 
>  
> 
> 
> 
> 
> 
> 
> 
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Kicad Build Issue on Ubuntu

[Babar Malik]

Dear all,
I am trying to build Kicad on Ubuntu 14.04 but I am facing a problem with
"wxPython". I tried a lot to install this package but the problem is still
here. The exact error shown on the terminal is *"CMake Error at
CMakeLists.txt:708 (message):*
*  wxPython version 3.0 does not appear to be installed on the system.*
*"*
Can anyone please suggest me the solution. Your assistance will be highly
appreciated.








Best Regards,
Muhammad Babar Malik
Namal College Mianwali
An Associate College of University of Bradford
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build using your nightly build scripts.

[Bernhard Stegmaier]

Hi,

it is probably not about an unpatched boost.

if you have multiple boost libraries on your system (which can be found by 
cmake) and you want to use the “internal” boost then partly the wrong ones seem 
to be linked/used… which causes immediate crashes.
We discussed that around christmas already… so either compile with the external 
one (use -DSKIP_…) or hide any other boost installations.


Regards,
Bernhard

> On 19 Mar 2015, at 17:13, Bob Gustafson  wrote:
> 
> Yes, I downloaded it (5525) and it ran fine on my Mac - thanks much. I 
> checked all of the crash sites - and no crashes on your build.
> 
> I will have to search for unpatched Boost files deep in my computer before I 
> do another build.
> 
> Thanks again Adam
> 
> Bob G
> 
> On 03/18/2015 09:11 PM, Adam Wolf wrote:
>> Hi folks,
>> 
>> After clearing some files off that system, the build completed without issue.
>> 
>> Bob, I'll see about making a build for you with trackpad support.  I have to 
>> test the new footprint GUI thing first.
>> 
>> Adam Wolf
>> 
>> On Wed, Mar 18, 2015 at 7:40 PM, Adam Wolf > > wrote:
>> I do not know about boost issues.  I do not have them.  They don't occur on 
>> my builds, right?
>> 
>> The only build failures since March 3rd have been due to disk space on one 
>> of my build boxes, two days ago.  I deleted some files, and restarted the 
>> job. We'll see if that fixes it.
>> 
>> Adam Wolf
>> Cofounder and Engineer
>> Wayne and Layne, LLC
>> 
>> On Wed, Mar 18, 2015 at 7:28 PM, Bob Gustafson > > wrote:
>> Hi Adam
>> 
>> I was able to compile and execute kicad using your build files, but I have 
>> some questions
>> Application: kicad
>> Version: (2015-03-17 BZR 5524)-product Release build
>> wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 
>> 4.2.1,STL containers,compatible with 2.8)
>> Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac
>> Boost version: 1.57.0
>>  USE_WX_GRAPHICS_CONTEXT=OFF
>>  USE_WX_OVERLAY=ON
>>  KICAD_SCRIPTING=ON
>>  KICAD_SCRIPTING_MODULES=ON
>>  KICAD_SCRIPTING_WXPYTHON=ON
>>  USE_FP_LIB_TABLE=HARD_CODED_ON
>>  BUILD_GITHUB_PLUGIN=ON
>>  KICAD_USE_WEBKIT=OFF
>> 
>> The odd thing about this is that it reports using Boost 1.57.0, but not the 
>> 1.54.0 which it downloaded, patched (successfully) and built.
>> 
>> I probably have a few boost libraries lying around on my disk. I think even 
>> brew downloaded a bottle with Boost 1.57.0. If the label above is accessed 
>> by a utility, perhaps it picked up the wrong label.
>> 
>> --
>> 
>> I was able to run the main KiCad and eeSchema, but when I clicked on the 
>> icons for pcbnew (I clicked on both the main page icon and the 2nd from 
>> right at the top on eeSchema - same results), it crashed.
>> 
>> 
>> Crash of pcbnew when opened - console output
>> 
>> Bobs-MacBook-Air:bin bobgus$ kicad.app/Contents/MacOS/kicad
>> Traceback (most recent call last):
>> File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>> __init__.py", line 45, in 
>> from wx._core import *
>> File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>> _core.py", line 4, in 
>> import _core_
>> ImportError: dlopen(/usr/local/lib/python2.7/site-packages/wx-3.0-
>> osx_cocoa/wx/_core_.so, 2): Symbol not found:
>> __ZTV20wxwxMenuItemListNode
>> Referenced from: /usr/local/lib/python2.7/site-packages/wx-3.0-
>> osx_cocoa/wx/_core_.so
>> Expected in: /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib
>> in /usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>> _core_.so
>> Segmentation fault: 11
>> Bobs-MacBook-Air:bin bobgus$
>> 
>> Some excerpts from the build log files - may not have any bearing on the 
>> problem though. Does seem to indicate that boost 1.54.0 is being used.
>> 
>> 990:
>> src='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
>> kicad/.downloads-by-cmake/boost_1_54_0.tar.bz2'
>> 991:
>> dst='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
>> kicad/.downloads-by-cmake/boost_1_54_0/src/boost'
>> 997:[ 32%] [ 32%] Performing update step for 'boost'
>> 998:creating 'boost scratch repo' specifically for boost to track
>> boost patches
>> 999:[ 32%] adding pristine boost files to 'boost scratch repo'
>> 1000:[ 32%] committing pristine boost files to 'boost scratch repo'
>> 1001:[ 32%] Performing patch step for 'boost'
>> 1002:patching file boost/polygon/detail/minkowski.hpp
>> 1003:patching file boost/cstdint.hpp
>> 1010:patching file boost/asio/ssl/impl/context.ipp
>> 1018:patching file boost/detail/interlocked.hpp
>> 1039:[ 32%] Performing configure step for 'boost'
>> 1057:
>> http://www.boost.org/more/getting_started/unix 
>> -
>> variants.html
>> 1060:
>> http://www.boost.org/boost-build2/doc/html/index.html 
>> 
>> 1062:[ 32%] Performing build

Re: [Kicad-developers] KiCad build using your nightly build scripts.

[Adam Wolf]

I believe your boost build issues will change shortly.  After the stable
release, the dependency building stuff is going to be completely changed.

Adam Wolf
On Mar 19, 2015 11:13 AM, "Bob Gustafson"  wrote:

>  Yes, I downloaded it (5525) and it ran fine on my Mac - thanks much. I
> checked all of the crash sites - and no crashes on your build.
>
> I will have to search for unpatched Boost files deep in my computer before
> I do another build.
>
> Thanks again Adam
>
> Bob G
>
> On 03/18/2015 09:11 PM, Adam Wolf wrote:
>
> Hi folks,
>
>  After clearing some files off that system, the build completed without
> issue.
>
>  Bob, I'll see about making a build for you with trackpad support.  I
> have to test the new footprint GUI thing first.
>
>  Adam Wolf
>
> On Wed, Mar 18, 2015 at 7:40 PM, Adam Wolf 
> wrote:
>
>> I do not know about boost issues.  I do not have them.  They don't occur
>> on my builds, right?
>>
>>  The only build failures since March 3rd have been due to disk space on
>> one of my build boxes, two days ago.  I deleted some files, and restarted
>> the job. We'll see if that fixes it.
>>
>>  Adam Wolf
>> Cofounder and Engineer
>> Wayne and Layne, LLC
>>
>> On Wed, Mar 18, 2015 at 7:28 PM, Bob Gustafson  wrote:
>>
>>>  Hi Adam
>>>
>>> I was able to compile and execute kicad using your build files, but I
>>> have some questions
>>>
>>> Application: kicad
>>> Version: (2015-03-17 BZR 5524)-product Release build
>>> wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC
>>> 4.2.1,STL containers,compatible with 2.8)
>>> Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac
>>> Boost version: 1.57.0
>>>  USE_WX_GRAPHICS_CONTEXT=OFF
>>>  USE_WX_OVERLAY=ON
>>>  KICAD_SCRIPTING=ON
>>>  KICAD_SCRIPTING_MODULES=ON
>>>  KICAD_SCRIPTING_WXPYTHON=ON
>>>  USE_FP_LIB_TABLE=HARD_CODED_ON
>>>  BUILD_GITHUB_PLUGIN=ON
>>>  KICAD_USE_WEBKIT=OFF
>>>
>>>
>>> The odd thing about this is that it reports using Boost 1.57.0, but not
>>> the 1.54.0 which it downloaded, patched (successfully) and built.
>>>
>>> I probably have a few boost libraries lying around on my disk. I think
>>> even brew downloaded a bottle with Boost 1.57.0. If the label above is
>>> accessed by a utility, perhaps it picked up the wrong label.
>>>
>>> --
>>>
>>> I was able to run the main KiCad and eeSchema, but when I clicked on the
>>> icons for pcbnew (I clicked on both the main page icon and the 2nd from
>>> right at the top on eeSchema - same results), it crashed.
>>>
>>>
>>> Crash of pcbnew when opened - console output
>>>
>>> Bobs-MacBook-Air:bin bobgus$ kicad.app/Contents/MacOS/kicad
>>> Traceback (most recent call last):
>>> File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>>> __init__.py", line 45, in 
>>> from wx._core import *
>>> File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>>> _core.py", line 4, in 
>>> import _core_
>>> ImportError: dlopen(/usr/local/lib/python2.7/site-packages/wx-3.0-
>>> osx_cocoa/wx/_core_.so, 2): Symbol not found:
>>> __ZTV20wxwxMenuItemListNode
>>> Referenced from: /usr/local/lib/python2.7/site-packages/wx-3.0-
>>> osx_cocoa/wx/_core_.so
>>> Expected in: /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib
>>> in /usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>>> _core_.so
>>> Segmentation fault: 11
>>> Bobs-MacBook-Air:bin bobgus$
>>>
>>>  Some excerpts from the build log files - may not have any bearing on
>>> the problem though. Does seem to indicate that boost 1.54.0 is being used.
>>>
>>> 990:
>>> src='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
>>> kicad/.downloads-by-cmake/boost_1_54_0.tar.bz2'
>>> 991:
>>> dst='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
>>> kicad/.downloads-by-cmake/boost_1_54_0/src/boost'
>>> 997:[ 32%] [ 32%] Performing update step for 'boost'
>>> 998:creating 'boost scratch repo' specifically for boost to track
>>> boost patches
>>> 999:[ 32%] adding pristine boost files to 'boost scratch repo'
>>> 1000:[ 32%] committing pristine boost files to 'boost scratch repo'
>>> 1001:[ 32%] Performing patch step for 'boost'
>>> 1002:patching file boost/polygon/detail/minkowski.hpp
>>> 1003:patching file boost/cstdint.hpp
>>> 1010:patching file boost/asio/ssl/impl/context.ipp
>>> 1018:patching file boost/detail/interlocked.hpp
>>> 1039:[ 32%] Performing configure step for 'boost'
>>> 1057:
>>> http://www.boost.org/more/getting_started/unix-
>>> variants.html
>>> 1060:
>>> http://www.boost.org/boost-build2/doc/html/index.html
>>> 1062:[ 32%] Performing build step for 'boost'
>>>
>>> The copy/paste below shows some possible problems.
>>>
>>> 1161:In file included from ./boost/filesystem/detail/
>>> utf8_codecvt_facet.hpp:18:
>>> 1162:./boost/detail/utf8_codecvt_facet.hpp:171:17: warning:
>>> 'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides
>>> overloaded virtual function [-Woverloaded-virtual]
>>> 1180:In file includ

Re: [Kicad-developers] KiCad build using your nightly build scripts.

[Bob Gustafson]

Yes, I downloaded it (5525) and it ran fine on my Mac - thanks much. I 
checked all of the crash sites - and no crashes on your build.


I will have to search for unpatched Boost files deep in my computer 
before I do another build.


Thanks again Adam

Bob G

On 03/18/2015 09:11 PM, Adam Wolf wrote:

Hi folks,

After clearing some files off that system, the build completed without 
issue.


Bob, I'll see about making a build for you with trackpad support.  I 
have to test the new footprint GUI thing first.


Adam Wolf

On Wed, Mar 18, 2015 at 7:40 PM, Adam Wolf 
mailto:adamw...@feelslikeburning.com>> 
wrote:


I do not know about boost issues.  I do not have them.  They don't
occur on my builds, right?

The only build failures since March 3rd have been due to disk
space on one of my build boxes, two days ago.  I deleted some
files, and restarted the job. We'll see if that fixes it.

Adam Wolf
Cofounder and Engineer
Wayne and Layne, LLC

On Wed, Mar 18, 2015 at 7:28 PM, Bob Gustafson mailto:bob...@rcn.com>> wrote:

Hi Adam

I was able to compile and execute kicad using your build
files, but I have some questions

Application: kicad
Version: (2015-03-17 BZR 5524)-product Release build
wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++
ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8)
Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little
endian, wxMac
Boost version: 1.57.0
 USE_WX_GRAPHICS_CONTEXT=OFF
 USE_WX_OVERLAY=ON
 KICAD_SCRIPTING=ON
 KICAD_SCRIPTING_MODULES=ON
 KICAD_SCRIPTING_WXPYTHON=ON
 USE_FP_LIB_TABLE=HARD_CODED_ON
 BUILD_GITHUB_PLUGIN=ON
 KICAD_USE_WEBKIT=OFF


The odd thing about this is that it reports using Boost
1.57.0, but not the 1.54.0 which it downloaded, patched
(successfully) and built.

I probably have a few boost libraries lying around on my disk.
I think even brew downloaded a bottle with Boost 1.57.0. If
the label above is accessed by a utility, perhaps it picked up
the wrong label.

--

I was able to run the main KiCad and eeSchema, but when I
clicked on the icons for pcbnew (I clicked on both the main
page icon and the 2nd from right at the top on eeSchema - same
results), it crashed.


Crash of pcbnew when opened - console output

Bobs-MacBook-Air:bin bobgus$ kicad.app/Contents/MacOS/kicad
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
__init__.py", line 45, in 
from wx._core import *
File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
_core.py", line 4, in 
import _core_
ImportError: dlopen(/usr/local/lib/python2.7/site-packages/wx-3.0-
osx_cocoa/wx/_core_.so, 2): Symbol not found:
__ZTV20wxwxMenuItemListNode
Referenced from: /usr/local/lib/python2.7/site-packages/wx-3.0-
osx_cocoa/wx/_core_.so
Expected in: /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib
in /usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
_core_.so
Segmentation fault: 11
Bobs-MacBook-Air:bin bobgus$

Some excerpts from the build log files - may not have any
bearing on the problem though. Does seem to indicate that
boost 1.54.0 is being used.

990:
src='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
kicad/.downloads-by-cmake/boost_1_54_0.tar.bz2'
991:
dst='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
kicad/.downloads-by-cmake/boost_1_54_0/src/boost'
997:[ 32%] [ 32%] Performing update step for 'boost'
998:creating 'boost scratch repo' specifically for boost to track
boost patches
999:[ 32%] adding pristine boost files to 'boost scratch repo'
1000:[ 32%] committing pristine boost files to 'boost scratch
repo'
1001:[ 32%] Performing patch step for 'boost'
1002:patching file boost/polygon/detail/minkowski.hpp
1003:patching file boost/cstdint.hpp
1010:patching file boost/asio/ssl/impl/context.ipp
1018:patching file boost/detail/interlocked.hpp
1039:[ 32%] Performing configure step for 'boost'
1057:
http://www.boost.org/more/getting_started/unix-
variants.html
1060:
http://www.boost.org/boost-build2/doc/html/index.html
1062:[ 32%] Performing build step for 'boost'

The copy/paste below shows some possible problems.

1161:In file included from ./boost/filesystem/detail/
utf8_codecvt_facet.hpp:18:
1162:./boost/detail/utf8_code

Re: [Kicad-developers] KiCad build using your nightly build scripts.

[Bob Gustafson]

Super. No hurry, I will be away in NYC for about a week. Not sure about 
my time/connection for testing.


Bob G

On 03/18/2015 09:11 PM, Adam Wolf wrote:

Hi folks,

After clearing some files off that system, the build completed without 
issue.


Bob, I'll see about making a build for you with trackpad support.  I 
have to test the new footprint GUI thing first.


Adam Wolf

On Wed, Mar 18, 2015 at 7:40 PM, Adam Wolf 
mailto:adamw...@feelslikeburning.com>> 
wrote:


I do not know about boost issues.  I do not have them.  They don't
occur on my builds, right?

The only build failures since March 3rd have been due to disk
space on one of my build boxes, two days ago.  I deleted some
files, and restarted the job. We'll see if that fixes it.

Adam Wolf
Cofounder and Engineer
Wayne and Layne, LLC

On Wed, Mar 18, 2015 at 7:28 PM, Bob Gustafson mailto:bob...@rcn.com>> wrote:

Hi Adam

I was able to compile and execute kicad using your build
files, but I have some questions

Application: kicad
Version: (2015-03-17 BZR 5524)-product Release build
wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++
ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8)
Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little
endian, wxMac
Boost version: 1.57.0
 USE_WX_GRAPHICS_CONTEXT=OFF
 USE_WX_OVERLAY=ON
 KICAD_SCRIPTING=ON
 KICAD_SCRIPTING_MODULES=ON
 KICAD_SCRIPTING_WXPYTHON=ON
 USE_FP_LIB_TABLE=HARD_CODED_ON
 BUILD_GITHUB_PLUGIN=ON
 KICAD_USE_WEBKIT=OFF


The odd thing about this is that it reports using Boost
1.57.0, but not the 1.54.0 which it downloaded, patched
(successfully) and built.

I probably have a few boost libraries lying around on my disk.
I think even brew downloaded a bottle with Boost 1.57.0. If
the label above is accessed by a utility, perhaps it picked up
the wrong label.

--

I was able to run the main KiCad and eeSchema, but when I
clicked on the icons for pcbnew (I clicked on both the main
page icon and the 2nd from right at the top on eeSchema - same
results), it crashed.


Crash of pcbnew when opened - console output

Bobs-MacBook-Air:bin bobgus$ kicad.app/Contents/MacOS/kicad
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
__init__.py", line 45, in 
from wx._core import *
File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
_core.py", line 4, in 
import _core_
ImportError: dlopen(/usr/local/lib/python2.7/site-packages/wx-3.0-
osx_cocoa/wx/_core_.so, 2): Symbol not found:
__ZTV20wxwxMenuItemListNode
Referenced from: /usr/local/lib/python2.7/site-packages/wx-3.0-
osx_cocoa/wx/_core_.so
Expected in: /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib
in /usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
_core_.so
Segmentation fault: 11
Bobs-MacBook-Air:bin bobgus$

Some excerpts from the build log files - may not have any
bearing on the problem though. Does seem to indicate that
boost 1.54.0 is being used.

990:
src='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
kicad/.downloads-by-cmake/boost_1_54_0.tar.bz2'
991:
dst='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
kicad/.downloads-by-cmake/boost_1_54_0/src/boost'
997:[ 32%] [ 32%] Performing update step for 'boost'
998:creating 'boost scratch repo' specifically for boost to track
boost patches
999:[ 32%] adding pristine boost files to 'boost scratch repo'
1000:[ 32%] committing pristine boost files to 'boost scratch
repo'
1001:[ 32%] Performing patch step for 'boost'
1002:patching file boost/polygon/detail/minkowski.hpp
1003:patching file boost/cstdint.hpp
1010:patching file boost/asio/ssl/impl/context.ipp
1018:patching file boost/detail/interlocked.hpp
1039:[ 32%] Performing configure step for 'boost'
1057:
http://www.boost.org/more/getting_started/unix-
variants.html
1060:
http://www.boost.org/boost-build2/doc/html/index.html
1062:[ 32%] Performing build step for 'boost'

The copy/paste below shows some possible problems.

1161:In file included from ./boost/filesystem/detail/
utf8_codecvt_facet.hpp:18:
1162:./boost/detail/utf8_codecvt_facet.hpp:171:17: warning:
'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides
overloaded virtual function [-Wover

Re: [Kicad-developers] KiCad build using your nightly build scripts.

[Adam Wolf]

Hi folks,

After clearing some files off that system, the build completed without
issue.

Bob, I'll see about making a build for you with trackpad support.  I have
to test the new footprint GUI thing first.

Adam Wolf

On Wed, Mar 18, 2015 at 7:40 PM, Adam Wolf 
wrote:

> I do not know about boost issues.  I do not have them.  They don't occur
> on my builds, right?
>
> The only build failures since March 3rd have been due to disk space on one
> of my build boxes, two days ago.  I deleted some files, and restarted the
> job. We'll see if that fixes it.
>
> Adam Wolf
> Cofounder and Engineer
> Wayne and Layne, LLC
>
> On Wed, Mar 18, 2015 at 7:28 PM, Bob Gustafson  wrote:
>
>>  Hi Adam
>>
>> I was able to compile and execute kicad using your build files, but I
>> have some questions
>>
>> Application: kicad
>> Version: (2015-03-17 BZR 5524)-product Release build
>> wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC
>> 4.2.1,STL containers,compatible with 2.8)
>> Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac
>> Boost version: 1.57.0
>>  USE_WX_GRAPHICS_CONTEXT=OFF
>>  USE_WX_OVERLAY=ON
>>  KICAD_SCRIPTING=ON
>>  KICAD_SCRIPTING_MODULES=ON
>>  KICAD_SCRIPTING_WXPYTHON=ON
>>  USE_FP_LIB_TABLE=HARD_CODED_ON
>>  BUILD_GITHUB_PLUGIN=ON
>>  KICAD_USE_WEBKIT=OFF
>>
>>
>> The odd thing about this is that it reports using Boost 1.57.0, but not
>> the 1.54.0 which it downloaded, patched (successfully) and built.
>>
>> I probably have a few boost libraries lying around on my disk. I think
>> even brew downloaded a bottle with Boost 1.57.0. If the label above is
>> accessed by a utility, perhaps it picked up the wrong label.
>>
>> --
>>
>> I was able to run the main KiCad and eeSchema, but when I clicked on the
>> icons for pcbnew (I clicked on both the main page icon and the 2nd from
>> right at the top on eeSchema - same results), it crashed.
>>
>>
>> Crash of pcbnew when opened - console output
>>
>> Bobs-MacBook-Air:bin bobgus$ kicad.app/Contents/MacOS/kicad
>> Traceback (most recent call last):
>> File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>> __init__.py", line 45, in 
>> from wx._core import *
>> File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>> _core.py", line 4, in 
>> import _core_
>> ImportError: dlopen(/usr/local/lib/python2.7/site-packages/wx-3.0-
>> osx_cocoa/wx/_core_.so, 2): Symbol not found:
>> __ZTV20wxwxMenuItemListNode
>> Referenced from: /usr/local/lib/python2.7/site-packages/wx-3.0-
>> osx_cocoa/wx/_core_.so
>> Expected in: /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib
>> in /usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
>> _core_.so
>> Segmentation fault: 11
>> Bobs-MacBook-Air:bin bobgus$
>>
>>  Some excerpts from the build log files - may not have any bearing on
>> the problem though. Does seem to indicate that boost 1.54.0 is being used.
>>
>> 990:
>> src='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
>> kicad/.downloads-by-cmake/boost_1_54_0.tar.bz2'
>> 991:
>> dst='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
>> kicad/.downloads-by-cmake/boost_1_54_0/src/boost'
>> 997:[ 32%] [ 32%] Performing update step for 'boost'
>> 998:creating 'boost scratch repo' specifically for boost to track
>> boost patches
>> 999:[ 32%] adding pristine boost files to 'boost scratch repo'
>> 1000:[ 32%] committing pristine boost files to 'boost scratch repo'
>> 1001:[ 32%] Performing patch step for 'boost'
>> 1002:patching file boost/polygon/detail/minkowski.hpp
>> 1003:patching file boost/cstdint.hpp
>> 1010:patching file boost/asio/ssl/impl/context.ipp
>> 1018:patching file boost/detail/interlocked.hpp
>> 1039:[ 32%] Performing configure step for 'boost'
>> 1057:
>> http://www.boost.org/more/getting_started/unix-
>> variants.html
>> 1060:
>> http://www.boost.org/boost-build2/doc/html/index.html
>> 1062:[ 32%] Performing build step for 'boost'
>>
>> The copy/paste below shows some possible problems.
>>
>> 1161:In file included from ./boost/filesystem/detail/
>> utf8_codecvt_facet.hpp:18:
>> 1162:./boost/detail/utf8_codecvt_facet.hpp:171:17: warning:
>> 'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides
>> overloaded virtual function [-Woverloaded-virtual]
>> 1180:In file included from ./boost/detail/utf8_codecvt_facet.ipp:13:
>> 1181:./boost/detail/utf8_codecvt_facet.hpp:171:17: warning:
>> 'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides
>> overloaded virtual function [-Woverloaded-virtual]
>> 1189:darwin.archive bin.v2/libs/filesystem/build/darwin-4.2.1/
>> release/link-static/threading-multi/libboost_filesystem.a
>>
>> The beginning of the actual crash report is shown below:
>>
>> Process:   kicad [92019]\
>> Path:  /Users/USER/*/kicad.app/Contents/MacOS/kicad
>> Identifier:org.kicad-eda.kicad
>> Version:   ??? (???)
>> Code Type: X86-64 (Na

Re: [Kicad-developers] KiCad build using your nightly build scripts.

[Adam Wolf]

I do not know about boost issues.  I do not have them.  They don't occur on
my builds, right?

The only build failures since March 3rd have been due to disk space on one
of my build boxes, two days ago.  I deleted some files, and restarted the
job. We'll see if that fixes it.

Adam Wolf
Cofounder and Engineer
Wayne and Layne, LLC

On Wed, Mar 18, 2015 at 7:28 PM, Bob Gustafson  wrote:

>  Hi Adam
>
> I was able to compile and execute kicad using your build files, but I have
> some questions
>
> Application: kicad
> Version: (2015-03-17 BZR 5524)-product Release build
> wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC
> 4.2.1,STL containers,compatible with 2.8)
> Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac
> Boost version: 1.57.0
>  USE_WX_GRAPHICS_CONTEXT=OFF
>  USE_WX_OVERLAY=ON
>  KICAD_SCRIPTING=ON
>  KICAD_SCRIPTING_MODULES=ON
>  KICAD_SCRIPTING_WXPYTHON=ON
>  USE_FP_LIB_TABLE=HARD_CODED_ON
>  BUILD_GITHUB_PLUGIN=ON
>  KICAD_USE_WEBKIT=OFF
>
>
> The odd thing about this is that it reports using Boost 1.57.0, but not
> the 1.54.0 which it downloaded, patched (successfully) and built.
>
> I probably have a few boost libraries lying around on my disk. I think
> even brew downloaded a bottle with Boost 1.57.0. If the label above is
> accessed by a utility, perhaps it picked up the wrong label.
>
> --
>
> I was able to run the main KiCad and eeSchema, but when I clicked on the
> icons for pcbnew (I clicked on both the main page icon and the 2nd from
> right at the top on eeSchema - same results), it crashed.
>
>
> Crash of pcbnew when opened - console output
>
> Bobs-MacBook-Air:bin bobgus$ kicad.app/Contents/MacOS/kicad
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
> __init__.py", line 45, in 
> from wx._core import *
> File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
> _core.py", line 4, in 
> import _core_
> ImportError: dlopen(/usr/local/lib/python2.7/site-packages/wx-3.0-
> osx_cocoa/wx/_core_.so, 2): Symbol not found:
> __ZTV20wxwxMenuItemListNode
> Referenced from: /usr/local/lib/python2.7/site-packages/wx-3.0-
> osx_cocoa/wx/_core_.so
> Expected in: /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib
> in /usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
> _core_.so
> Segmentation fault: 11
> Bobs-MacBook-Air:bin bobgus$
>
>  Some excerpts from the build log files - may not have any bearing on the
> problem though. Does seem to indicate that boost 1.54.0 is being used.
>
> 990:
> src='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
> kicad/.downloads-by-cmake/boost_1_54_0.tar.bz2'
> 991:
> dst='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
> kicad/.downloads-by-cmake/boost_1_54_0/src/boost'
> 997:[ 32%] [ 32%] Performing update step for 'boost'
> 998:creating 'boost scratch repo' specifically for boost to track
> boost patches
> 999:[ 32%] adding pristine boost files to 'boost scratch repo'
> 1000:[ 32%] committing pristine boost files to 'boost scratch repo'
> 1001:[ 32%] Performing patch step for 'boost'
> 1002:patching file boost/polygon/detail/minkowski.hpp
> 1003:patching file boost/cstdint.hpp
> 1010:patching file boost/asio/ssl/impl/context.ipp
> 1018:patching file boost/detail/interlocked.hpp
> 1039:[ 32%] Performing configure step for 'boost'
> 1057:
> http://www.boost.org/more/getting_started/unix-
> variants.html
> 1060:
> http://www.boost.org/boost-build2/doc/html/index.html
> 1062:[ 32%] Performing build step for 'boost'
>
> The copy/paste below shows some possible problems.
>
> 1161:In file included from ./boost/filesystem/detail/
> utf8_codecvt_facet.hpp:18:
> 1162:./boost/detail/utf8_codecvt_facet.hpp:171:17: warning:
> 'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides
> overloaded virtual function [-Woverloaded-virtual]
> 1180:In file included from ./boost/detail/utf8_codecvt_facet.ipp:13:
> 1181:./boost/detail/utf8_codecvt_facet.hpp:171:17: warning:
> 'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides
> overloaded virtual function [-Woverloaded-virtual]
> 1189:darwin.archive bin.v2/libs/filesystem/build/darwin-4.2.1/
> release/link-static/threading-multi/libboost_filesystem.a
>
> The beginning of the actual crash report is shown below:
>
> Process:   kicad [92019]\
> Path:  /Users/USER/*/kicad.app/Contents/MacOS/kicad
> Identifier:org.kicad-eda.kicad
> Version:   ??? (???)
> Code Type: X86-64 (Native)
> Parent Process:bash [46543]
> Responsible:   Terminal [458]
> User ID:   501
>
> Date/Time: 2015-03-17 22:45:30.130 -0500
> OS Version:Mac OS X 10.10.2 (14C1510)
> Report Version:11
> Anonymous UUID:5EC3DCC9-7506-88B6-B795-E06635F030BC
>
> Sleep/Wake UUID:   D3B1E849-EB3E-4A40-AA14-0AE38FED6F59
>
> Time Awake Since 

[Kicad-developers] KiCad build using your nightly build scripts.

[Bob Gustafson]

Hi Adam

I was able to compile and execute kicad using your build files, but I 
have some questions


   Application: kicad
   Version: (2015-03-17 BZR 5524)-product Release build
   wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC
   4.2.1,STL containers,compatible with 2.8)
   Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac
   Boost version: 1.57.0
 USE_WX_GRAPHICS_CONTEXT=OFF
 USE_WX_OVERLAY=ON
 KICAD_SCRIPTING=ON
 KICAD_SCRIPTING_MODULES=ON
 KICAD_SCRIPTING_WXPYTHON=ON
 USE_FP_LIB_TABLE=HARD_CODED_ON
 BUILD_GITHUB_PLUGIN=ON
 KICAD_USE_WEBKIT=OFF


The odd thing about this is that it reports using Boost 1.57.0, but not 
the 1.54.0 which it downloaded, patched (successfully) and built.


I probably have a few boost libraries lying around on my disk. I think 
even brew downloaded a bottle with Boost 1.57.0. If the label above is 
accessed by a utility, perhaps it picked up the wrong label.


--

I was able to run the main KiCad and eeSchema, but when I clicked on the 
icons for pcbnew (I clicked on both the main page icon and the 2nd from 
right at the top on eeSchema - same results), it crashed.



Crash of pcbnew when opened - console output

Bobs-MacBook-Air:bin bobgus$ kicad.app/Contents/MacOS/kicad
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
__init__.py", line 45, in 
from wx._core import *
File "/usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
_core.py", line 4, in 
import _core_
ImportError: dlopen(/usr/local/lib/python2.7/site-packages/wx-3.0-
osx_cocoa/wx/_core_.so, 2): Symbol not found:
__ZTV20wxwxMenuItemListNode
Referenced from: /usr/local/lib/python2.7/site-packages/wx-3.0-
osx_cocoa/wx/_core_.so
Expected in: /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib
in /usr/local/lib/python2.7/site-packages/wx-3.0-osx_cocoa/wx/
_core_.so
Segmentation fault: 11
Bobs-MacBook-Air:bin bobgus$

Some excerpts from the build log files - may not have any bearing on the 
problem though. Does seem to indicate that boost 1.54.0 is being used.


990:
src='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
kicad/.downloads-by-cmake/boost_1_54_0.tar.bz2'
991:
dst='/Users/bobgus/KiCad-adam/kicad-mac-packaging-python/
kicad/.downloads-by-cmake/boost_1_54_0/src/boost'
997:[ 32%] [ 32%] Performing update step for 'boost'
998:creating 'boost scratch repo' specifically for boost to track
boost patches
999:[ 32%] adding pristine boost files to 'boost scratch repo'
1000:[ 32%] committing pristine boost files to 'boost scratch repo'
1001:[ 32%] Performing patch step for 'boost'
1002:patching file boost/polygon/detail/minkowski.hpp
1003:patching file boost/cstdint.hpp
1010:patching file boost/asio/ssl/impl/context.ipp
1018:patching file boost/detail/interlocked.hpp
1039:[ 32%] Performing configure step for 'boost'
1057:
http://www.boost.org/more/getting_started/unix-
variants.html
1060:
http://www.boost.org/boost-build2/doc/html/index.html
1062:[ 32%] Performing build step for 'boost'

The copy/paste below shows some possible problems.

1161:In file included from ./boost/filesystem/detail/
utf8_codecvt_facet.hpp:18:
1162:./boost/detail/utf8_codecvt_facet.hpp:171:17: warning:
'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides
overloaded virtual function [-Woverloaded-virtual]
1180:In file included from ./boost/detail/utf8_codecvt_facet.ipp:13:
1181:./boost/detail/utf8_codecvt_facet.hpp:171:17: warning:
'boost::filesystem::detail::utf8_codecvt_facet::do_length' hides
overloaded virtual function [-Woverloaded-virtual]
1189:darwin.archive bin.v2/libs/filesystem/build/darwin-4.2.1/
release/link-static/threading-multi/libboost_filesystem.a

The beginning of the actual crash report is shown below:

Process:   kicad [92019]\
Path: /Users/USER/*/kicad.app/Contents/MacOS/kicad
Identifier:org.kicad-eda.kicad
Version:   ??? (???)
Code Type: X86-64 (Native)
Parent Process:bash [46543]
Responsible:   Terminal [458]
User ID:   501

Date/Time: 2015-03-17 22:45:30.130 -0500
OS Version:Mac OS X 10.10.2 (14C1510)
Report Version:11
Anonymous UUID:5EC3DCC9-7506-88B6-B795-E06635F030BC

Sleep/Wake UUID:   D3B1E849-EB3E-4A40-AA14-0AE38FED6F59

Time Awake Since Boot: 62 seconds
Time Since Wake:   94000 seconds

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x40490fe4

VM Regions Near 0x40490fe4:
-->
__TEXT 000103cec000-000103daa000 [  760K] r-x/rwx SM=COW 
/Users/USER/*/kicad.app/Contents/MacOS/kicad


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   _pcbnew.kiface0x00010ccdefe0 
KIGFX::VIEW::SetGAL(KIGFX::GAL*) + 112
1   _pcbnew.kifa

Re: [Kicad-developers] KiCad build.

[Dick Hollenbeck]

On 08/21/2014 04:38 PM, Jon Neal wrote:
> Looking from the outside that is very aggressive, harsh, and childish. I 
> thought you were
> stepping away from the project Dick (At least that is what you said a few 
> weeks ago).


Jon,

Your uninformed opinion will have no effect on the SoftPLC policy.  In fact, I 
won't even
bring up your opinion at my SoftPLC Corporation's board of director's meeting, 
nor at the
corporation's share holder's meeting.  Because I can already anticipate what 
they would say:


"Dick, we invested in your company in order to make a profit.  Every minute you 
spend on
KiCad is a minute you are not making product to improve sales and enhance 
profits and our
return on investments.  It's clear to us that your recent 41,000 line and 
21,000 line
patches are unheard of and with Jon's comments, it is clear that they are under
appreciated and not instantaneously enhancing corporate goodwill.  So there's no
justifiable reason, from a business standpoint for you to continue.  KiCad is 
good enough
now for our own corporate use.  Every minute you spend on KiCad is lost 
opportunity cost
to the corporation."

"However, those copyrights in KiCad are our corporate assets.  We view them as 
providing
corporate goodwill long term.  They establish corporate competency, corporate 
visibility,
and may in the long run lead to other kinds of business.  You did the right 
thing in
sending a message that the corporation intends to defend the copyrights 
rigorously, either
inside the project or out.  You also put into place a filter which prefers like 
minded
code contributors who know how to be respectful of prior ownership investments 
and also
value their own copyrights and would make good alliance partners in the event 
of some kind
of project wide code theft."

"It should be enough that the code is licensed under a license which allows 
respectful end
user use.  However, we live in a world where personal and corporate character 
seem to be
deteriorating."

"Sending an early warning signal may have allowed the corporation to avoid 
lawsuits in the
future, while at the same time signalling that SoftPLC Corporation is a viable 
alliance
partner in defending the collective KiCad copyrights."

"You did the right thing, but its time for you to focus on product development. 
 You have
made KiCad sufficiently good for our own internal corporate use, and it is 
clear your time
is better spent focusing on product development."


And at that point the most I could say would be, "well Jon thought his point of 
view was
important enough to get thrown off the mailing list.  So I owed him that."



> Maybe it is best to let more than just yourself offer an opinion on this.

See above.


> Is there a reason ANY of the code in KiCad is copyright anyone except KiCad 
> itself? Other
> projects I have worked on did not allow copyright by anyone except for the 
> project itself.

See above.


Jon, here you have offered an opinion first, and sought knowledge second.
Please don't vote that way.As we're seeing in the U.S. now, this can only 
lead to bad
things.

You will be let you back on the developer's list in a couple of weeks if you 
promise to go
read about how the GPL works and the importance of corporate sponsors in an 
open source
project.

Generally however, this mailing list is for code contributors.  
Non-contributors who come
in here with critical points of view have been thrown out before.  The recourse 
is for the
developers to do everything by private email, and I don't think that is what is 
best for
the project.

As Cirilo accurately stated, code contributors are ownership share holders in 
this
project.  Mere lurkers and users are not, so they have no standing on this 
mailing list.





>>
>> Jon Neal
>>
>> On Aug 21, 2014 9:56 AM, "Dick Hollenbeck" > >
> wrote:
>>>
>>> On 08/21/2014 07:57 AM, Michael Narigon wrote:
>>> > OK, thanks for your comment.  Michael
>>>
>>> Actually I'm not done:
>>>
>>> Neither the KiCad project, nor SoftPLC Corporation will tolerate the 
>>> removal of copyright
>>> messages unless either a) authorized by the copyright holder or b) 
>>> incorrectly placed in
>>> the first place, irrespective of opined legality of such removal.  It will 
>>> not be
> tolerated.
>>>
>>>
>>> Historically, it has not been tolerated because it has never before 
>>> happened.  Now that it
>>> has happened, this statement needed to be made.
>>>
>>>
>>> Michael has been removed from the project mailing list (after having been 
>>> given a chance
>>> to offer immediate correction), as will anyone who challenges this stance.
>>>
>>>
>>> Dick
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Cirilo Bernardo]

>
> From: Jon Neal 
>To: KiCad Developers  
>Sent: Friday, August 22, 2014 7:38 AM
>Subject: Re: [Kicad-developers] KiCad build.
> 
>
>
>Looking from the outside that is very aggressive, harsh, and childish. I 
>thought you were stepping away from the project Dick (At least that is what 
>you said a few weeks ago). Maybe it is best to let more than just yourself 
>offer an opinion on this.
>Is there a reason ANY of the code in KiCad is copyright anyone except KiCad 
>itself? Other projects I have worked on did not allow copyright by anyone 
>except for the project itself.
>>
>> Jon Neal
>>


That would be plain weird and contrary to Copyright law in any country. 
Depending on jurisdiction, copyright belongs to all authors or else all authors 
with 'substantive contribution'. In the case of GNU source code the FSF asks 
all contributors to transfer copyright to the FSF, which requires a legal 
document. Simply saying that a project 'owns' copyright is 100% pure nonsense. 
Only a legal entity such as individuals and a corporation can claim copyright. 
Simply changing the copyright statement on Dick's work is a clear violation of 
copyright so of course he's furious about it. He's already made huge 
contributions at his own expense and receives little thanks - is he expected to 
tolerate people stealing his work as well?

- Cirilo


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Jon Neal]

Looking from the outside that is very aggressive, harsh, and childish. I
thought you were stepping away from the project Dick (At least that is what
you said a few weeks ago). Maybe it is best to let more than just yourself
offer an opinion on this.

Is there a reason ANY of the code in KiCad is copyright anyone except KiCad
itself? Other projects I have worked on did not allow copyright by anyone
except for the project itself.

>
> Jon Neal
>
> On Aug 21, 2014 9:56 AM, "Dick Hollenbeck"  wrote:
>>
>> On 08/21/2014 07:57 AM, Michael Narigon wrote:
>> > OK, thanks for your comment.  Michael
>>
>> Actually I'm not done:
>>
>> Neither the KiCad project, nor SoftPLC Corporation will tolerate the
removal of copyright
>> messages unless either a) authorized by the copyright holder or b)
incorrectly placed in
>> the first place, irrespective of opined legality of such removal.  It
will not be tolerated.
>>
>>
>> Historically, it has not been tolerated because it has never before
happened.  Now that it
>> has happened, this statement needed to be made.
>>
>>
>> Michael has been removed from the project mailing list (after having
been given a chance
>> to offer immediate correction), as will anyone who challenges this
stance.
>>
>>
>> Dick
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Dick Hollenbeck]

On 08/21/2014 07:57 AM, Michael Narigon wrote:
> OK, thanks for your comment.  Michael

Actually I'm not done:

Neither the KiCad project, nor SoftPLC Corporation will tolerate the removal of 
copyright
messages unless either a) authorized by the copyright holder or b) incorrectly 
placed in
the first place, irrespective of opined legality of such removal.  It will not 
be tolerated.


Historically, it has not been tolerated because it has never before happened.  
Now that it
has happened, this statement needed to be made.


Michael has been removed from the project mailing list (after having been given 
a chance
to offer immediate correction), as will anyone who challenges this stance.


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Michael Narigon]

OK, thanks for your comment.  Michael

On Aug 20, 2014, at 9:19 PM, Dick Hollenbeck  wrote:

> On 08/20/2014 05:07 PM, Michael Narigon wrote:
>> Gents,
>> It probably landed in your spam filter (half the e-mails from the developers 
>> list do to me) but I sent a message that I am pretty far along on what you 
>> are discussing. See the tar file at https://code.launchpad.net/~mnarigon.
>> 
>> I used the good work you guys had and cleaned it up. I used the 
>> kicad-build.sh concept of the build steps (and KiCadOSXBuilder) and 
>> separated out the KiCad build process into a number of steps that can be 
>> selectively executed. For those platforms where the dependencies exist I 
>> take advantage of them.
>> 
>> The steps are roughly check the environment, check for pre-requisites, build 
>> tools, build dependent libraries, pull source from the repository, build, 
>> install, and package.
>> 
>> The scripts are alpha but the steps I have completed are pretty robust. I am 
>> still working on the install and packaging steps, debug builds do not work, 
>> and I have not yet worked on windows other than to check the cygwin 
>> dependencies although I intend these script to fully support Windows.
>> 
>> Currently, I can build KiCad on OS X and Linux. I am currently focussed on 
>> getting a drag and drop install working on OS X.
>> 
>> In the tar there is the top-level build script called build.sh. Read this to 
>> understand what is going on, and try it out by running it.
>> 
>> I intend this to work on OS X, Linux (debian and Redhat) and Windows.
>> 
>> Michael
> 
> 
> 
> 
> scripts/CMakeLists-pcbnew-github.txt.in
> 
> 
> Why is this now somebody else's copyright?
> 
> That was actually my fucking work.
> 
> Your license is incompatible with the project.
> 
> You only have one chance to make a first impression.
> 
> Yours has been made.
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Dick Hollenbeck]

On 08/20/2014 05:07 PM, Michael Narigon wrote:
> Gents,
> It probably landed in your spam filter (half the e-mails from the developers 
> list do to me) but I sent a message that I am pretty far along on what you 
> are discussing. See the tar file at https://code.launchpad.net/~mnarigon.
> 
> I used the good work you guys had and cleaned it up. I used the 
> kicad-build.sh concept of the build steps (and KiCadOSXBuilder) and separated 
> out the KiCad build process into a number of steps that can be selectively 
> executed. For those platforms where the dependencies exist I take advantage 
> of them.
> 
> The steps are roughly check the environment, check for pre-requisites, build 
> tools, build dependent libraries, pull source from the repository, build, 
> install, and package.
> 
> The scripts are alpha but the steps I have completed are pretty robust. I am 
> still working on the install and packaging steps, debug builds do not work, 
> and I have not yet worked on windows other than to check the cygwin 
> dependencies although I intend these script to fully support Windows.
> 
> Currently, I can build KiCad on OS X and Linux. I am currently focussed on 
> getting a drag and drop install working on OS X.
> 
> In the tar there is the top-level build script called build.sh. Read this to 
> understand what is going on, and try it out by running it.
> 
> I intend this to work on OS X, Linux (debian and Redhat) and Windows.
> 
> Michael




scripts/CMakeLists-pcbnew-github.txt.in


Why is this now somebody else's copyright?

That was actually my fucking work.

Your license is incompatible with the project.

You only have one chance to make a first impression.

Yours has been made.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Michael Narigon]

Gents,
It probably landed in your spam filter (half the e-mails from the developers 
list do to me) but I sent a message that I am pretty far along on what you are 
discussing. See the tar file at https://code.launchpad.net/~mnarigon.

I used the good work you guys had and cleaned it up. I used the kicad-build.sh 
concept of the build steps (and KiCadOSXBuilder) and separated out the KiCad 
build process into a number of steps that can be selectively executed. For 
those platforms where the dependencies exist I take advantage of them.

The steps are roughly check the environment, check for pre-requisites, build 
tools, build dependent libraries, pull source from the repository, build, 
install, and package.

The scripts are alpha but the steps I have completed are pretty robust. I am 
still working on the install and packaging steps, debug builds do not work, and 
I have not yet worked on windows other than to check the cygwin dependencies 
although I intend these script to fully support Windows.

Currently, I can build KiCad on OS X and Linux. I am currently focussed on 
getting a drag and drop install working on OS X.

In the tar there is the top-level build script called build.sh. Read this to 
understand what is going on, and try it out by running it.

I intend this to work on OS X, Linux (debian and Redhat) and Windows.

Michael

On Aug 20, 2014, at 11:53 AM, Dick Hollenbeck  wrote:

> On 08/20/2014 11:45 AM, Wayne Stambaugh wrote:
>> On 8/19/2014 5:17 PM, Dick Hollenbeck wrote:
>>> On 08/19/2014 03:37 PM, Wayne Stambaugh wrote:
 On 8/19/2014 4:17 PM, Dick Hollenbeck wrote:
> On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
>> On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
>>> On 16 August 2014 17:44, 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.
 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Dick Hollenbeck]

On 08/20/2014 11:45 AM, Wayne Stambaugh wrote:
> On 8/19/2014 5:17 PM, Dick Hollenbeck wrote:
>> On 08/19/2014 03:37 PM, Wayne Stambaugh wrote:
>>> On 8/19/2014 4:17 PM, Dick Hollenbeck wrote:
 On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
> On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
>> On 16 August 2014 17:44, 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
>>>
>>
>> Hi Wayne,
>>
>> I think that sounds like a sane decision, although of course KiCad
>> will be subject to the bugs in other libraries, but it's up to
>> distribution maintainers to sort those out in my opinion.
>>
>> I hope that we can use some sort of deprecation system, please mark a
>> lib as being deprecated so that I can sort out Winbuilder before the
>> CMake system is broke. It's much easier to work that way round as
>> opposed to a reactionary approach where we break everything and then
>> everyone has to fix their build before being able to do anything. I
>> will do the leg work to keep the Winbuilder people happy and do any
>> projects necessary to package dependencies required by it.
>
> I will be making changes very slowly because I expect there to be some
> breakage with some of the FindFoo.cmake changes I'm going to make.  This
> will give everyone time to respond should I break anything.  I will be
> pushing hard against adding personal install paths to every
> FindFoo.cmake file.  CMake knows how to find the correct default paths
> on most platforms and I will always give the developer the chance to
> override those using either and environment variable or a definition on
> the CMake command line for custom library testing.  I will start out
> with the dependencies that don't require any patches to build and then
> address the more complex ones like wxWidgets and fin

Re: [Kicad-developers] KiCad build.

[Wayne Stambaugh]

On 8/19/2014 5:17 PM, Dick Hollenbeck wrote:
> On 08/19/2014 03:37 PM, Wayne Stambaugh wrote:
>> On 8/19/2014 4:17 PM, Dick Hollenbeck wrote:
>>> On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
 On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
> On 16 August 2014 17:44, 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
>>
>
> Hi Wayne,
>
> I think that sounds like a sane decision, although of course KiCad
> will be subject to the bugs in other libraries, but it's up to
> distribution maintainers to sort those out in my opinion.
>
> I hope that we can use some sort of deprecation system, please mark a
> lib as being deprecated so that I can sort out Winbuilder before the
> CMake system is broke. It's much easier to work that way round as
> opposed to a reactionary approach where we break everything and then
> everyone has to fix their build before being able to do anything. I
> will do the leg work to keep the Winbuilder people happy and do any
> projects necessary to package dependencies required by it.

 I will be making changes very slowly because I expect there to be some
 breakage with some of the FindFoo.cmake changes I'm going to make.  This
 will give everyone time to respond should I break anything.  I will be
 pushing hard against adding personal install paths to every
 FindFoo.cmake file.  CMake knows how to find the correct default paths
 on most platforms and I will always give the developer the chance to
 override those using either and environment variable or a definition on
 the CMake command line for custom library testing.  I will start out
 with the dependencies that don't require any patches to build and then
 address the more complex ones like wxWidgets and finish up with the
 nightmare that is Boost.  If I change more than one FindFoo.cmake every
 two weeks, that will be a bl

Re: [Kicad-developers] KiCad build.

[Dick Hollenbeck]

On 08/19/2014 03:37 PM, Wayne Stambaugh wrote:
> On 8/19/2014 4:17 PM, Dick Hollenbeck wrote:
>> On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
>>> On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
 On 16 August 2014 17:44, 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
>

 Hi Wayne,

 I think that sounds like a sane decision, although of course KiCad
 will be subject to the bugs in other libraries, but it's up to
 distribution maintainers to sort those out in my opinion.

 I hope that we can use some sort of deprecation system, please mark a
 lib as being deprecated so that I can sort out Winbuilder before the
 CMake system is broke. It's much easier to work that way round as
 opposed to a reactionary approach where we break everything and then
 everyone has to fix their build before being able to do anything. I
 will do the leg work to keep the Winbuilder people happy and do any
 projects necessary to package dependencies required by it.
>>>
>>> I will be making changes very slowly because I expect there to be some
>>> breakage with some of the FindFoo.cmake changes I'm going to make.  This
>>> will give everyone time to respond should I break anything.  I will be
>>> pushing hard against adding personal install paths to every
>>> FindFoo.cmake file.  CMake knows how to find the correct default paths
>>> on most platforms and I will always give the developer the chance to
>>> override those using either and environment variable or a definition on
>>> the CMake command line for custom library testing.  I will start out
>>> with the dependencies that don't require any patches to build and then
>>> address the more complex ones like wxWidgets and finish up with the
>>> nightmare that is Boost.  If I change more than one FindFoo.cmake every
>>> two weeks, that will be a blistering pace.  The goal is to get each
>>> dependency test working and properly designed before moving to the next one.
>>>

Re: [Kicad-developers] KiCad build.

[Wayne Stambaugh]

On 8/19/2014 4:17 PM, Dick Hollenbeck wrote:
> On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
>> On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
>>> On 16 August 2014 17:44, 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

>>>
>>> Hi Wayne,
>>>
>>> I think that sounds like a sane decision, although of course KiCad
>>> will be subject to the bugs in other libraries, but it's up to
>>> distribution maintainers to sort those out in my opinion.
>>>
>>> I hope that we can use some sort of deprecation system, please mark a
>>> lib as being deprecated so that I can sort out Winbuilder before the
>>> CMake system is broke. It's much easier to work that way round as
>>> opposed to a reactionary approach where we break everything and then
>>> everyone has to fix their build before being able to do anything. I
>>> will do the leg work to keep the Winbuilder people happy and do any
>>> projects necessary to package dependencies required by it.
>>
>> I will be making changes very slowly because I expect there to be some
>> breakage with some of the FindFoo.cmake changes I'm going to make.  This
>> will give everyone time to respond should I break anything.  I will be
>> pushing hard against adding personal install paths to every
>> FindFoo.cmake file.  CMake knows how to find the correct default paths
>> on most platforms and I will always give the developer the chance to
>> override those using either and environment variable or a definition on
>> the CMake command line for custom library testing.  I will start out
>> with the dependencies that don't require any patches to build and then
>> address the more complex ones like wxWidgets and finish up with the
>> nightmare that is Boost.  If I change more than one FindFoo.cmake every
>> two weeks, that will be a blistering pace.  The goal is to get each
>> dependency test working and properly designed before moving to the next one.
>>
>> Cheers,
>>
>> Wayne
> 
> 
> The current thinking among those using CMake for several large projects is 
> that it can
> eithe

Re: [Kicad-developers] KiCad build.

[Dick Hollenbeck]

On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
> On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
>> On 16 August 2014 17:44, 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
>>>
>>
>> Hi Wayne,
>>
>> I think that sounds like a sane decision, although of course KiCad
>> will be subject to the bugs in other libraries, but it's up to
>> distribution maintainers to sort those out in my opinion.
>>
>> I hope that we can use some sort of deprecation system, please mark a
>> lib as being deprecated so that I can sort out Winbuilder before the
>> CMake system is broke. It's much easier to work that way round as
>> opposed to a reactionary approach where we break everything and then
>> everyone has to fix their build before being able to do anything. I
>> will do the leg work to keep the Winbuilder people happy and do any
>> projects necessary to package dependencies required by it.
> 
> I will be making changes very slowly because I expect there to be some
> breakage with some of the FindFoo.cmake changes I'm going to make.  This
> will give everyone time to respond should I break anything.  I will be
> pushing hard against adding personal install paths to every
> FindFoo.cmake file.  CMake knows how to find the correct default paths
> on most platforms and I will always give the developer the chance to
> override those using either and environment variable or a definition on
> the CMake command line for custom library testing.  I will start out
> with the dependencies that don't require any patches to build and then
> address the more complex ones like wxWidgets and finish up with the
> nightmare that is Boost.  If I change more than one FindFoo.cmake every
> two weeks, that will be a blistering pace.  The goal is to get each
> dependency test working and properly designed before moving to the next one.
> 
> Cheers,
> 
> Wayne


The current thinking among those using CMake for several large projects is that 
it can
either find or it can build in the first pass.  It struggles with finding a 
prerequisite
and building the prerequisite as a fallback, then 

Re: [Kicad-developers] KiCad build.

[Wayne Stambaugh]

On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
> On 16 August 2014 17:44, 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
>>
> 
> Hi Wayne,
> 
> I think that sounds like a sane decision, although of course KiCad
> will be subject to the bugs in other libraries, but it's up to
> distribution maintainers to sort those out in my opinion.
> 
> I hope that we can use some sort of deprecation system, please mark a
> lib as being deprecated so that I can sort out Winbuilder before the
> CMake system is broke. It's much easier to work that way round as
> opposed to a reactionary approach where we break everything and then
> everyone has to fix their build before being able to do anything. I
> will do the leg work to keep the Winbuilder people happy and do any
> projects necessary to package dependencies required by it.

I will be making changes very slowly because I expect there to be some
breakage with some of the FindFoo.cmake changes I'm going to make.  This
will give everyone time to respond should I break anything.  I will be
pushing hard against adding personal install paths to every
FindFoo.cmake file.  CMake knows how to find the correct default paths
on most platforms and I will always give the developer the chance to
override those using either and environment variable or a definition on
the CMake command line for custom library testing.  I will start out
with the dependencies that don't require any patches to build and then
address the more complex ones like wxWidgets and finish up with the
nightmare that is Boost.  If I change more than one FindFoo.cmake every
two weeks, that will be a blistering pace.  The goal is to get each
dependency test working and properly designed before moving to the next one.

Cheers,

Wayne

> 
> So far in august there have been 1685 builds using KiCad-Winbuilder.
> 
> So at least people have been finding it useful!
> 
> Best Regards,
> 
> Brian.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
Mor

Re: [Kicad-developers] KiCad build.

[Brian Sidebotham]

On 16 August 2014 17:44, 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
>

Hi Wayne,

I think that sounds like a sane decision, although of course KiCad
will be subject to the bugs in other libraries, but it's up to
distribution maintainers to sort those out in my opinion.

I hope that we can use some sort of deprecation system, please mark a
lib as being deprecated so that I can sort out Winbuilder before the
CMake system is broke. It's much easier to work that way round as
opposed to a reactionary approach where we break everything and then
everyone has to fix their build before being able to do anything. I
will do the leg work to keep the Winbuilder people happy and do any
projects necessary to package dependencies required by it.

So far in august there have been 1685 builds using KiCad-Winbuilder.

So at least people have been finding it useful!

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Michael Narigon]

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

Re: [Kicad-developers] KiCad build.

[Wayne Stambaugh]

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  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  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
> mailto:stambau...@verizon.net>> 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
>   lib

Re: [Kicad-developers] KiCad build.

[Michael Narigon]

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

On Aug 16, 2014, at 5:15 PM, Wayne Stambaugh  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  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
 mailto:stambau...@verizon.net>> 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

Re: [Kicad-developers] KiCad build.

[Wayne Stambaugh]

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  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
>>> mailto:stambau...@verizon.net>> 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

Re: [Kicad-developers] KiCad build.

[Wayne Stambaugh]

On 8/16/2014 6:22 PM, Cirilo Bernardo wrote:
> - Original Message -
> 
>> From: Wayne Stambaugh 
>> To: KiCad Developers 
>> Cc: 
>> Sent: Sunday, August 17, 2014 2:44 AM
>> Subject: [Kicad-developers] KiCad build.
>>
>> 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
>>
> 
> 
> No objections at all here. I agree with Dick that this will probably
> hurt MacOSX users the most.

I would hope it wouldn't be an issue for users as much as for
developers.  We really need to get to the point where we can provide
nightly builds (or at least current builds) of OSX and Windows.

> 
> Personally I wouldn't mind seeing libdxf ripped out either unless there
> are some KiCad specific changes in there which prevent us from using the
> stock library. I can check this out on my system in about a week's time;
> I'll attempt to link the DXF importer and DXF/IDF  tools to
> libdxflib-2.5.0.0 and see what breaks.

Thanks for looking at this.  JP can probably add some insight as to
whether or not he had to make any changes to libdxf to work with KiCad.
 Out of curiosity, what build system does libdxf use?  As long as its
autoconf or CMake, there should be no problems building it on all platforms.

> 
> As for devs, for the most part I think issues will be solved by running
> ldd on the executables, writing up a requirements list and updating the
> web page. All Linux distributions will have a slightly different way of
> dealing with things but generally there should be no problems and
> package maintainers will have an easier life with the changes. OSX and
> MSWin users will have to work out the necessary voodoo for their own
> systems and update documentation or platform-specific build instructions.

There are build ins

Re: [Kicad-developers] KiCad build.

[Wayne Stambaugh]

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
crea

Re: [Kicad-developers] KiCad build.

[Michael Narigon]

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  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
>> mailto:stambau...@verizon.net>> 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
>> 

Re: [Kicad-developers] KiCad build.

[Cirilo Bernardo]

- Original Message -

> From: Wayne Stambaugh 
> To: KiCad Developers 
> Cc: 
> Sent: Sunday, August 17, 2014 2:44 AM
> Subject: [Kicad-developers] KiCad build.
> 
> 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
> 


No objections at all here. I agree with Dick that this will probably
hurt MacOSX users the most.

Personally I wouldn't mind seeing libdxf ripped out either unless there
are some KiCad specific changes in there which prevent us from using the
stock library. I can check this out on my system in about a week's time;
I'll attempt to link the DXF importer and DXF/IDF  tools to
libdxflib-2.5.0.0 and see what breaks.

As for devs, for the most part I think issues will be solved by running
ldd on the executables, writing up a requirements list and updating the
web page. All Linux distributions will have a slightly different way of
dealing with things but generally there should be no problems and
package maintainers will have an easier life with the changes. OSX and
MSWin users will have to work out the necessary voodoo for their own
systems and update documentation or platform-specific build instructions.

- Cirilo


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad build.

[Wayne Stambaugh]

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
> mailto:stambau...@verizon.net>> 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@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 


___
Mail

Re: [Kicad-developers] KiCad build.

[Dick Hollenbeck]

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.

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.

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.

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).

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.

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.

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.


Dick






___

Re: [Kicad-developers] KiCad build.

[Jason Whiteman]

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

[Kicad-developers] KiCad build.

[Wayne Stambaugh]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp