Awesome Adam!!, It really sounds great, that was fast!, if you can, please send me a ssh pub-key from your server privately, and I will create and account at kicad-pcb.org to let you upload the releases to the right place with a simple/automated scp :-)
Cheers!! :) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 14/03/2013, at 16:52, Adam Wolf <[email protected]> wrote: > I've got the Mac version building after every commit internally. I hope to > add Linux tonight, and then as soon as the upstream patches for Windows > scripting builds get commited, I'll add that as well. Once I trust them a > bit more, I can push them out to wherever. > > I can definitely make the build server run through a set of scripts and fail > the build if any of them die. > > While I'm hesitant to open up the build server itself (it's on my home > network), I'm working on having it pull all the configuration data and build > scripts from a publically accessible repository. > > If anyone has publically accesible branches they want me to run through my > build server, let me know. > > Adam Wolf > Wayne and Layne, LLC > On Thu, Mar 14, 2013 at 10:45 AM, Miguel Angel Ajo Pelayo > <[email protected]> wrote: > First and important: Encapsultion must go first, I'm not against it but the > opposite. Read what follows for clarification: > > > My concern is about the scripts that build functionality on kicad objects, > scripts that people will build and > should be maintained separately to KiCad. Now it's not important at all > because the scripting base is tiny-0, > when it grows, and we make changes to scriptable object interfaces, we will > have to take care about this. > > So the earlier we encapsulate, the better. > > And in the future, if we change method names, we should (in the script side) > provide some fallback/translation > methods with deprecation warning. > > * Automated testing: > > , I think the scripting to-do should contain the making of a good bunch of > test cases that cover all possible > object operations that we are willing to support. I talked with Adam Wolf > about that, it could be great > to get them automatically checked on every commit, we can also extend this to > check internal KiCad behaviors > in an automated way :) > > > * About build dependencies & swig: > > > > Compilation must always work, at this moment, cmake isn't able to fetch > dependencies from .i files to .h files, > or at least, I wasn't able to set it up. > > In my case I just remove the pcbnew_wrapper.cpp and > scripting/pcbnew_wrapper.cxx and called > make again, so it compiled gracefully. > > Getting dependencies for that automatically would be highly desired, and must > be in my todo list at any point. > > > > > > > Miguel Angel Ajo > http://www.nbee.es > +34911407752 > skype: ajoajoajo > > On 14/03/2013, at 16:37, Wayne Stambaugh <[email protected]> wrote: > > > On 3/14/2013 11:07 AM, Miguel Angel Ajo Pelayo wrote: > >> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/revision/4001 > >> > >> Hehe, nice cleanup, it's something that must be done. > >> > >> Anyway, interface changes to core objects, should be tracked carefully > >> once we have scripting published, > >> a change like this could break scripts working on the field: > >> > >> 151 > >> > >> void SetPos( const wxPoint& aPoint ) { m_Pos = aPoint; } > >> 152 > >> > >> const wxPoint GetPos() const { return m_Pos; } > >> > >> 174 > >> void SetPosition( const wxPoint& aPoint ) { m_Pos = aPoint; } > >> > >> 175 > >> const wxPoint GetPosition() const { return m_Pos; } > >> > >> > >> My opinion is, these changes need to be done, the cleaner, the better, > >> but once scripting is widely deployed, > >> we must provide some (scripting side wrappers) for compatibility, for > >> example redirecting SetPos to SetPosition on scripting, > >> and sending an "deprecated" warning for some set of releases. > > > > Sorry about that. I forgot rebuild the Python scripting support to see > > if I broke anything. I'm still getting used to the idea that it is now > > part of KiCad. > > > > Doesn't this kind of code automatically get updated the next time the > > scripting code is reSWIGged or is this something that has to be hand > > tweaked every time? I am familiar with SWIG so if need be, I will fix > > the SWIG stuff from now on. I'm thinking the python scripting is going > > to have to closely track the compiled KiCad code for the foreseeable > > future. The will be a great of upheaval with the forthcoming footprint > > library table stuff. The last thing I want to do is stop the > > encapsulation work just to support Python scripting. > > > >> > >> > >> > >> > >> Miguel Angel Ajo > >> http://www.nbee.es > >> +34911407752 > >> skype: ajoajoajo > >> > > > > > _______________________________________________ > 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
