kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 29 July 2013 20:26, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> On 07/21/2013 06:46 PM, Brian Sidebotham wrote:
> > Hi Dick,
> >
> > I've just committed some fixes for the installer, and a fix for ZLIB
> because the download
> > URL is broken since their latest release (They do not keep older files
> on their server). I
> > simply switched it to sourceforge instead.
>
>
> For a similar project I upgraded to zlib 1.28 without issue.  I might play
> with that
> possibility instead if you don't mind.  But I cannot fault the less risky
> path you took.
>
> But zlib has been pretty stable in it core support for some time, and I
> structured the
> CMake script so we can roll with the latest of all external libraries
> quite easily.
>
>
Excellent, thanks for committing the update to V1.28.


>
>
> > The installer now has separate copies of the cmake NSIS installer
> templates so they can be
> > easily modified to add the extra functionality we require. I've added an
> extra option to
> > set PYTHONHOME on install, and also fixed the PATH setting.
>
>
> This is very excellent.  Going around the built in CMake NSIS support to
> extend the NSIS
> support is very smart and *ambitious*.  This is sounding like a quality
> effort.
>
> I wonder if we should look at doing this for KiCad?
>
>
> It will certainly make a nicer impression having a glitzy installer for
> a-mingw-us.
>
>
>
The included template for CMake is great to get started with, but it's very
limited. Moving to our own means we can easily add the glitzy bits. I will
look at adding some more glamour to it soon. For the moment it's good to
just have an installer that works as intended. The NSIS script syntax is
not pretty!



> >
> > I'm also working on the wxWidgets-cmake project as it's in desperate
> need of supporting
> > MSVC builds. At the moment it's still MinGW only, but it's getting close
> to having MSVC
> > support.
>
>
> No idea what MSVC is?  (... probably intentional amnesia, but I forgot
> forgetting.)
>
>
MicroSoft Visual-C. As much as I may not like using it, the wxWidgets
people are all over it and the cmake build system will go nowhere if it is
left only supporting gcc. I've yet to commit the changes for supporting GTK
and Monolithic builds too. The MSVC support is now virtually complete
though, I know what the final problem with the MSVC build is now so
hopefully I can commit that tonight.

It's a steep learning curve as I'm not used to using Visual Studio much.

Once Monolithic and GTK support are in to that project I can start
releasing some binary packages. One of these is what KiCad-Winbuilder will
use and will include wxPython.


>
> >
> > I think next weekend I might be able to have the binaries ready and it
> looks like a
> > KiCad-Winbuilder with scripting support is not long away. There are only
> minimal changes
> > required to our current CMakeLists.txt file in KiCad.
>
>
>
> > I do have a problem with Python-a-mingw-us though. The Readline module
> forces python to
> > quit straight away. If I simply rename the readline module so it fails
> to load,
> > python-a-mingw-us appears to work well. I've attached the output from
> python-a-mingw-us
> > with the readline module in place using the -v option.
> >
> > When redirecting this output, like:
> >
> > python -v > python-a-mingw-us-v.txt 2>&1
> >
> > it did not quit straight away - instead I had to quit() properly. But if
> I run this
> > without the output redirection it quits straight away.
>
>
> Have you had any luck with the thought that it might be un-findable
> 'terminal data' files
> (for Windows).  If so, maybe a windows specific subset put in the right
> place may appease.
>
>
I've not had a chance to look at this yet, however I should be looking at
it in the next few days. At the weekend I successfully built KiCad with
scripting support using the latest commit to KiCad-WinBuilder which uses
the temporary hosted binary set from the wxwidgets-cmake project.

There is a bug though, the plugins fail to load, and the PyCrust console
hangs the application when you move focus to it (click the panel with the
mouse).

But getting the entire build together is a start. There is a basic cmake
module for finding Python-a-mingw-us based on a variable, or known install
location. There are a few changes to the KiCad CMakeLists.txt too to
support using Python-a-mingw-us too. But nothing too obtrusive. I've added
some more paths and filename patterns to KiCad's FindWxWidgets.cmake module
too.

So the next thing to fix for the KiCad scripting build is the readline
issue in Python-a-mingw-us to rule out that as being the problem behind the
hanging PyCrust and non-loading plugins. I doubt it it, but it's a known
issue so I should fix that before embarking on anything else.


> >
> > There is a long pause in the installer, but it executes successfully.
> I'm unsure what's
> > causing the pause at the moment.
> >
> > I can roll the new release files for python-a-mingw-us if you add me to
> the project. My
> > "username" should simply be brian.sidebotham@xxxxxxxxx <mailto:
> brian.sidebotham@xxxxxxxxx>
>
>
> Done, you are an admin of that project on code.google.com.
>
> I was on vacation last week and half, sorry it took so long.
>
>
> Dick
>
>
>
Excellent, thanks again Dick. Don't worry about the delay! It feels like
it's taking forever to get the scripting build all tied together, but it's
getting there and soon we should see the fruits of the work.

Best Regards, Brian.