kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

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 <adamwolf@xxxxxxxxxxxxxxxxxxxx> 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 <miguelangel@xxxxxxx> 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 <stambaughw@xxxxxxxxxxx> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>