kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 18 May 2013 05:46, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

>
> On May 17, 2013 5:00 PM, "Brian Sidebotham" <brian.sidebotham@xxxxxxxxx>
> wrote:
> >
>
> > Sorry Dick! Please find the diff attached. It took me ages to sort the
> branding out. It turns out that NSIS is only happy with an 8-bit windows
> bitmap with no colourspace information or run-length-encoding. Once I found
> that out, I could generate some initial bitmaps for the nsis installer.
> I've attached a few images of what the installer steps look like on my
> machine.
>
> Looks as good as it can.  Thanks for sorting that out.
>
>
> >
> > Let me know if you're happy and I'll commit the changes. It re-enables
> the NSIS installer for the package target.
> >
>
> Can we have a variable to test which reenables the zip packaging?  So
> either can be built by cmake.
>
> I assume your higher level cmake scripts, say in winbuilder, will be
> easier if python is installable as a zip.
>
> I will put both types of packaging at google.
>

I've not excluded the ZIP packaging, so at the moment make package results
in a zip and installer executable which I guess is right if we're going to
supply both packages.

Yes, a zip package is easier to deal with for something like winbuilder as
it can be installed locally and doesn't need to be installed machine-wide.


> > I've marked all components as "required to be installed"
> >
> > Is pointing the the installer licence page to the LICENCE file correct?
> Or do we want to do a separate licence file for Python-a-mingw-us?
>
> It is still python.  Python is plagued with an evolutionary license.
> What about simply pointing via url to python's license at python site?
> That way any confusion is pinned there.
>
> On a-mingus itself, for extension building on windows, maybe a cmake
> template, which has knowledge of header and lib locs?  Since no distutils
> for mingw?  Possibly a python wrapper to the cmake creation from template
> process?  Could code the cmake script tempate in the python wrapper file.
> Customize it, write out cmakelists.txt, with proper dirs and libs and
> targets in it.  Runs cmake, then make, then make install.
>
> That sounds like a great idea. It will be good to give support to people
who want to buiild extensions with it seen as that is it's main purpose.
I'll look into that next. I have been looking at SWIG recently, so I'm a
bit more familiar with python extension writing. SWIG and <stdbool.h> don't
play nice together at all :(

Anyway, I'll commit the changes now.

Best Regards, Brian.