kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

Yes, thanks Dick, windows users are important too, it makes Kicad community bigger, and 
design freedom wider for all of us.



I forgot to mention, when I released this build script, that wx patches are Marco Serantoni work, 
they make wx widgets overlay work (something necessary for OSX when you move, drag, redraw anything).

Thanks Marco!! ;)




Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 18:27, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:

> Thanks for your work getting Python scripting on Windows.
> 
> What's the next step here, to make it match what you need for development?  Make a cmake directive to direct where the python modules go?
> 
> Adam Wolf
> W&L
> 
> On Mar 11, 2013 11:37 AM, "Dick Hollenbeck" <dick@xxxxxxxxxxx> wrote:
> On 03/11/2013 10:32 AM, Adam Wolf wrote:
> >
> > Would it be bad for us to put the swiggy autogenerated stuff in a
> > readonly, central location, because it's not going to be modified
> > without doing a new cmake?  Then we put all the scripts that will be
> > modified in a homedir?
> >
> 
> It gets bad when you guess wrong.
> 
> At this point I am resigning from the conversation.
> 
> I worked until 3:30 AM last night on this shit, and in the last month
> I worked 3 weekends on providing python a-mingw-us.
> 
> The first time I stuggle to edit a python script, who the hell knows
> what will happen.
> 
> Let the package maintainers figure it out, make it easy for me please.
> 
> 
> 
> 
> 
> > On Mar 11, 2013 10:25 AM, "Miguel Angel Ajo Pelayo"
> > <miguelangel@xxxxxxx <mailto:miguelangel@xxxxxxx>> wrote:
> >
> >     For me, the most reasonable solution sounds like providing both
> >     options,
> >     being able to enforce a user-local destination for python
> >     modules/libraries,
> >     or a system wide standard one.
> >
> >     In development, or single user installations, first is better,
> >     for apt-get install
> >     or equivalent system-wide installations, the second sounds correct.
> >
> >     Miguel Angel Ajo
> >     http://www.nbee.es
> >     +34911407752 <tel:%2B34911407752>
> >     skype: ajoajoajo
> >
> >     On 11/03/2013, at 16:20, Adam Wolf
> >     <adamwolf@xxxxxxxxxxxxxxxxxxxx
> >     <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>> wrote:
> >
> >>     If we store all the python modules in a user's home directory,
> >>     how do they get there?  Does kicad put them there, or does the
> >>     installer?
> >>
> >>     While we should provide the python modules like
> >>     footprint_wizard.py for download, we cannot easily provide the
> >>     swiggy modules like pcbnew.py for download, because they depend
> >>     upon both the kicad source and state on the user's system.
> >>
> >>     If the installer is putting them there, I hope we don't have a
> >>     situation where the dll-like swiggy python modules are only in
> >>     one home directory.  This could create issues if you delete
> >>     your dotfiles or another user wants to use Python support.
> >>
> >>     Adam Wolf
> >>
> >>     On Mar 11, 2013 9:39 AM, "Miguel Angel Ajo Pelayo"
> >>     <miguelangel@xxxxxxx <mailto:miguelangel@xxxxxxx>> wrote:
> >>
> >>
> >>         That looks quite much to the wrapping I had to do in MacOX
> >>         to avoid static linking,
> >>         where it's uncommon for normal users to put new libraries
> >>         in the system paths:
> >>
> >>         I rename pcbnew to pcbnew.bin and put the loader as
> >>         "pcbnew", same for all the other apps,
> >>         it just builds a pointer to the libraries, the python path,
> >>         and kicad stock libraries, and then
> >>         boots the app itself.
> >>
> >>         #!/bin/sh
> >>         # this is script wraps the original binary application,
> >>
> >>
> >>         # and sets the library paths just before launching
> >>         DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
> >>
> >>
> >>         export KICAD_APP=$DIR/../../../kicad.app
> >>
> >>
> >>         export KICAD_DATA=$DIR/../../../data
> >>
> >>
> >>         # let the apps find the libraries at startup
> >>
> >>
> >>         export
> >>         DYLD_LIBRARY_PATH=$KICAD_APP/Contents/Frameworks:$DYLD_LIBRARY_PATH
> >>
> >>
> >>         # let python scripting find our modules
> >>
> >>
> >>         export
> >>         PYTHONPATH=$KICAD_APP/Contents/Frameworks/python2.7/site-packages/:$PYTHONPATH
> >>
> >>
> >>         export KICAD=$KICAD_DATA
> >>
> >>
> >>         $DIR/`basename $0`.bin $*
> >>
> >>
> >>
> >>
> >>         Miguel Angel Ajo
> >>         http://www.nbee.es <http://www.nbee.es/>
> >>         +34911407752 <tel:%2B34911407752>
> >>         skype: ajoajoajo
> >>
> >>         On 11/03/2013, at 15:33, Dick Hollenbeck <dick@xxxxxxxxxxx
> >>         <mailto:dick@xxxxxxxxxxx>> wrote:
> >>
> >>>         For the 4th time, yes.  And it would not bother me at all
> >>>         to be
> >>>         different from a decade of other python users, but like
> >>>         blender users.
> >>>
> >>>         I am happy to be different, when I know I am helping myself.
> >>>
> >>>         Maintaining a distinction between two categories of kicad
> >>>         python
> >>>         modules is a low priority to me.
> >>>
> >>>         For linux users, the installer can set PYTHONPATH on the
> >>>         commandline,
> >>>         and this can be done in a desktop launcher (icon or menu):
> >>>
> >>>
> >>>         $ PYTHONPATH=<writeable-convenient-dir>:$PATHONPATH  pcbnew
> >>>
> >>>         $ PYTHONPATH=<writeable-convenient-dir>:$PATHONPATH  kicad
> >>>
> >>>
> >>>         I believe these settings would last as long as the program
> >>>         is running,
> >>>         only.  Which is about what we want.
> >>>
> >>>         Might need to to put sh in front of that.
> >>
> >
>