I believe Blender has a Python environment of its own embedded inside of
it, and doesn't reuse a system Python.
Adam Wolf
Wayne and Layne, LLC
On Sun, Mar 10, 2013 at 10:21 PM, Dick Hollenbeck d...@softplc.com wrote:
On Mar 10, 2013 8:32 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es
In general, system-wide python modules go into site-packages. If this is
the route we want to go, I think we can do something like this in our CMake
to find the site-packages directory.
execute_process ( COMMAND python -c from distutils.sysconfig import
get_python_lib; print get_python_lib()
I also think, that it's important to provide a way for users to have access to
our modules from outside kicad,
that can be easily fixed letting them set (or appending to) PYTHONPATH, as I'm
doing now for MacOSX,
In linux are you sure they do like that?, in windows for sure.
If you bundle
Maybe worth to look at :
http://virtualenvwrapper.readthedocs.org/en/latest/command_ref.html
That is what I use for environments that have multiple configurations
(and libraries).
Keep going !
Edwin van den Oetelaar
On Mon, Mar 11, 2013 at 2:19 PM, Miguel Angel Ajo Pelayo
miguelan...@nbee.es
Yeah, virtualenv or something equivalent is a must for most Python
development, but I don't think it necessarily applies here.
If we had the python modules for Kicad completely separate, we could throw
them into pypi (think perl's CPAN) and then folks who want to use
virtualenv (or something
I think I understand what you mean Dick, we need to provide a default way
to compile and install python modules to a prefix,
and also the set of default scripts module libraries, wizards, it's that
what you mean?
But anyway, when somebody installs a package system wide, we must
Hi Dick,
The modules just have to be in a place on the PYTHONPATH (afaik). We can
either put them in a location that is already on the PYTHONPATH, or put
them in a location that isn't on the PYTHONPATH and provide instructions on
how to modify your PYTHONPATH or modify it for the user.
I have
On 03/11/2013 09:23 AM, Adam Wolf wrote:
Hi Dick,
The modules just have to be in a place on the PYTHONPATH (afaik).
We can either put them in a location that is already on the
PYTHONPATH, or put them in a location that isn't on the PYTHONPATH
and provide instructions on how to modify your
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
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
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?
On Mar 11, 2013 10:25 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es
On 03/11/2013 10:20 AM, Adam Wolf 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
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
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
WL
On Mar 11, 2013 11:37 AM, Dick Hollenbeck d...@softplc.com wrote:
On 03/11/2013 10:32
Hi Miguel,
Downloading as we speak. On the github page you call it a universal OSX binary,
but that would mean it supports both PowerPC and Intel based MACS, whereas is
this email announcement you call it i386 +x64 build.
I'm looking forward in compiling it myself, just to see if your solution
On 10/03/2013, at 11:30, Martijn Kuipers martijn.kuip...@gmail.com wrote:
Viva,
On Mar 10, 2013, at 10:23 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es
wrote:
Hehe, yes, you're right, universal is ppc+x86+x64, x86+x64 is only multi
binary.
My system cannot compile for ppc (it's a
I was always hoping to see the libraries (DLLs) to go into /Library/Kicad,
so we can keep the memory footprint down of the separate Kicad components.
But it is not a trivial task, so it seems.
I am not following what you want to do. Is it like:
/Applications/kicad/kicad.app - the app with
Awesome!!, thanks for testing Martijn, :-)
I think I used cmake from homebrew:
MacBook-Air-de-Miguel:src ajo$ which cmake
/Users/ajo/.rvm/bin/cmake
MacBook-Air-de-Miguel:src ajo$ ls -la `which cmake`
lrwxr-xr-x 1 ajo staff 47 2 mar 00:24 /Users/ajo/.rvm/bin/cmake -
This tuesday I must decide if I keep renewing our *ltium license, or if we
won't.
I'm thinking about donating 1/2 - 2/3 of it's cost to buy one of those mac
minis to
provide continuous integration/building of kicad binaries for OSX on every bzr
release.
It would be wonderful also if we
On Mar 11, 2013, at 12:35 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es
wrote:
Awesome!!, thanks for testing Martijn, :-)
I think I used cmake from homebrew:
MacBook-Air-de-Miguel:src ajo$ which cmake
/Users/ajo/.rvm/bin/cmake
MacBook-Air-de-Miguel:src ajo$ ls -la `which cmake`
Miguel,
Wayne and Layne recently purchased a Mac Mini for Kicad builds. We have a
spare Windows license too, so I can host a Windows and Linux VM on it as
well.
I can set this up on a Jenkins instance. I'm considering doing the same
with the Linux builds. While I like the PPA autobuilder, the
I just build a pure x64 binary for OSX.
Packed: 82MB
Unpacked: 300MB
Honoustly, I expected the difference with a 386/x64 build to be bigger
Packed: 82 vs 100MB
Unpacked: 300 vs 350MB
/Martijn
On Mar 11, 2013, at 12:35 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es
wrote:
Awesome!!, thanks
I like to put the actual commands used in the build server in a source tree
somewhere, so there's no magic behind the scenes.
Adam Wolf
Wayne and Layne LLC
On Mar 10, 2013 8:04 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es
wrote:
Adam, it sounds great, you're killing my excuse to buy a
On Mar 10, 2013 6:50 PM, Adam Wolf adamw...@feelslikeburning.com wrote:
Miguel,
Wayne and Layne recently purchased a Mac Mini for Kicad builds. We have
a spare Windows license too, so I can host a Windows and Linux VM on it as
well.
I can set this up on a Jenkins instance. I'm considering
On 11/03/2013, at 02:40, Adam Wolf adamw...@feelslikeburning.com wrote:
Nah, I think, if my releases are good enough, that I'd rather push them to a
central kicad thing, rather than to a WL property. I don't want to spread
things out more than they have to be.
While we're not big enough
On Mar 10, 2013 8:32 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es
wrote:
On 11/03/2013, at 03:25, Dick Hollenbeck d...@softplc.com wrote:
On Mar 10, 2013 8:10 PM, Adam Wolf adamw...@feelslikeburning.com
wrote:
Dick,
We can do it either way. We can push binaries up to the PPA, or
Hi,
I've been working on the release of Kicad with scripting for MacOSX, also tried
to package it all together with
all kicad libs, and the templates.
It's supposed to be a i386 + x64 binary build, with scripting support.
kicad-scripting-osx-latest.zip
It has all the new kicad templates
27 matches
Mail list logo
