On May 17, 2013 9:44 PM, "Kaspar Bumke" <[email protected]> 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 <[email protected]> wrote: > > On 17 May 2013 22:08, Dick Hollenbeck <[email protected]> wrote: > >> > >> On 05/07/2013 08:01 AM, Brian Sidebotham wrote: > >> > On 7 May 2013 13:51, Dick Hollenbeck <[email protected] > >> > <mailto:[email protected]>> 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 : [email protected] > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
