kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On May 17, 2013 9:44 PM, "Kaspar Bumke" <kaspar.bumke@xxxxxxxxx> wrote:
>
> It just occurred to me that a case for Python3 can genuinely be made
> as an Enum type is on it's way into the standard libraries.
> That should prove to be quite handy when binding C++.
>
> http://www.python.org/dev/peps/pep-0435/

2.7.4 on windows is what we are providing for users.  That is a result of
myriads of interlocking contraints.


>
> On 17 May 2013 23:00, Brian Sidebotham <brian.sidebotham@xxxxxxxxx> wrote:
> > On 17 May 2013 22:08, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> >>
> >> On 05/07/2013 08:01 AM, Brian Sidebotham wrote:
> >> > On 7 May 2013 13:51, Dick Hollenbeck <dick@xxxxxxxxxxx
> >> > <mailto:dick@xxxxxxxxxxx>> wrote:
> >> >
> >> >     On 05/06/2013 04:36 PM, Brian Sidebotham wrote:
> >> >     > This turned into just a set of notes about CTest and
Boost.Test:
> >> >     >
> >> >     > CTest integrates well with CMake [1] and allows us to run
> >> > executables that perform
> >> >     tests.
> >> >     > Each test can be set as required (to be passed) or not. The
result
> >> > of each test is based
> >> >     > on a rule that is defined in the each tests properties. For
> >> > example, the integer return
> >> >     > code from a process can be tested, or a regex match can be
> >> > performed on stdout or stderr
> >> >     > for the test process.
> >> >     >
> >> >     > Simple tests that depend on the integer return code of a
process
> >> > can be done via CMake's
> >> >     > execute_process by checking RESULT_VARIABLE.
> >> >     >
> >> >     > Using the process return code, both CTest and CMake can test
> >> > python API changes by
> >> >     > executing python scripts and checking python's return value.
> >> >     >
> >> >     > The Boost.Test framework provides easy methods for writing C++
> >> > test cases as
> >> >     executables.
> >> >     > A single executable can contain as many tests as required. Each
> >> > test is called
> >> >     > individually as a command line argument. The Boost.Test
framework
> >> > can work by
> >> >     returning a
> >> >     > different integer return code from the executable depending on
the
> >> > result of a test.
> >> >     It is
> >> >     > has some additional features which aid automatic regression
> >> > testing (for example on
> >> >     build
> >> >     > servers and the like) [2]
> >> >     >
> >> >     > Writing test cases using the Boost.Test framework provides an
easy
> >> > way to test
> >> >     > WorkerFunctions within the codebase as we can write test cases
and
> >> > link them to the
> >> >     > classes we're testing. This really requires code to be more
> >> > modular so that we can link
> >> >     > test executables against libraries.
> >> >     >
> >> >     > CTest and Boost.Test can allow memory leak testing as CTest
> >> > integrates well with
> >> >     Purify or
> >> >     > Valgrind.
> >> >     >
> >> >     > CTest allows subsets of tests to be run, so if you know you've
> >> > only been working on a
> >> >     > certain part of the codebase, you can quickly run just the
tests
> >> > that should be affected
> >> >     > by your changes before running the whole test suite.
> >> >     >
> >> >     > The Python API requires test cases for stability so we know
that
> >> > our changes to the C++
> >> >     > code do not break other peoples IP based on our Python API.
> >> >
> >> >
> >> >     Thanks very much.  I probably will not have much input into this
> >> > decision moving forward.
> >> >
> >> >     How is the wxPython build script coming for Windows?
> >> >
> >> >
> >> > Hi Dick,
> >> >
> >> > I am going to cmake-ify wxPython to build it (I will maintain a
patch,
> >> > and hope wxPython
> >> > will accept it), as I want to get rid of distutils which is really
very
> >> > broken for MinGW.
> >> > Building wxPython is actually relatively straight forward, but there
are
> >> > a lot of options
> >> > which translate to wxWidgets build options which need covering in
cmake.
> >> > This work isn't
> >> > yet off the ground.
> >> >
> >> > I'm currently working on the NSIS packaging of python-a-mingw-us. At
the
> >> > moment it looks
> >> > like we'll have to use an 8-bit colour BMP for the logo which doesn't
> >> > look great. There
> >> > seems to be some peculiarities with the BMP format used by makensis
> >> > because if it is
> >> > anything other than an 8-bit BMP the logo doesn't get displayed.
> >> >
> >> > I have read a lot of posts that sort-of relate to this, but most end
up
> >> > building the
> >> > windows installer on a windows machine and this limitation doesn't
then
> >> > appear to exist.
> >> >
> >> > Anyway, I have the installer pretty much up and running. I'd like to
> >> > email you a diff to
> >> > review before committing, just to make sure you're happy with what
I've
> >> > done. I'll email a
> >> > patch tonight. I had to rename one of the installable components
because
> >> > the name is
> >> > directly used as a variable name in the nsis script, and a few other
> >> > things too in order
> >> > to get the packaging to work.
> >>
> >> Its been weeks now.  I did not receive it.  I don't see it checked in
> >> either.
> >>
> >> >
> >> > I think everything except the headers component is a required
> >> > installation component.
> >>
> >> The headers are required for folks to stack C/C++ code on top, such as
> >> wxPython.  So
> >> unless we want to do a second "development" package, I don't think
there's
> >> harm in leaving
> >> them in a single package.
> >>
> >> Thanks,
> >>
> >> Dick
> >
> >
> > 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.
> >
> > Let me know if you're happy and I'll commit the changes. It re-enables
the
> > NSIS installer for the package target.
> >
> > 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?
> >
> > Best Regards, Brian.
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >