kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On May 18, 2013 5:20 AM, "Brian Sidebotham" <brian.sidebotham@xxxxxxxxx>
wrote:
>
> 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.

Exciting, thank you!  Possibly tidbits to borrow from the extension cmake
function() in a-ming-us' build scripts.  It has passed through two hands
already, might give you some ideas.

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

Shoot sorry to hear that.

>
> Anyway, I'll commit the changes now.
>
> Best Regards, Brian.
>