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 yo
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" wrote:
> On 03/11/2013 10:32 AM, Adam Wolf
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
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 th
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"
wrote:
> For me, 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 instal
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, becaus
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 librarie
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 y
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 se
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 prov
On 03/11/2013 08:25 AM, Adam Wolf wrote:
> Miguel,
>
> I only know about Blender/Python on Windows.
>
> I think site-packages (dist-packages on Debian/Ubuntu) might be the
> right way to do it. Put the python modules in a place that's
> already on the PYTHONPATH that package managers already expec
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 equiv
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
wrote:
> I also think, t
Miguel,
I only know about Blender/Python on Windows.
I think site-packages (dist-packages on Debian/Ubuntu) might be the right
way to do it. Put the python modules in a place that's already on the
PYTHONPATH that package managers already expect folks to put modules into.
The idea of having an en
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 your
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 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 wrote:
>
> On Mar 10, 2013 8:32 PM, "Miguel Angel Ajo Pelayo"
> wrote:
> >
> >
> > On 11/03/2013, at
On Mar 10, 2013 8:32 PM, "Miguel Angel Ajo Pelayo"
wrote:
>
>
> On 11/03/2013, at 03:25, Dick Hollenbeck wrote:
>
>>
>> On Mar 10, 2013 8:10 PM, "Adam Wolf"
wrote:
>> >
>> > Dick,
>> >
>> > We can do it either way. We can push binaries up to the PPA, or we
can continue to do the bzrbuilder reci
On 11/03/2013, at 03:25, Dick Hollenbeck wrote:
>
> On Mar 10, 2013 8:10 PM, "Adam Wolf" wrote:
> >
> > Dick,
> >
> > We can do it either way. We can push binaries up to the PPA, or we can
> > continue to do the bzrbuilder recipe->PPA. I would actually be doing the
> > bzrbuilder recipe on
On Mar 10, 2013 8:10 PM, "Adam Wolf" wrote:
>
> Dick,
>
> We can do it either way. We can push binaries up to the PPA, or we can
continue to do the bzrbuilder recipe->PPA. I would actually be doing the
bzrbuilder recipe on my local machine.
>
> I can always fix the current cmake issue and do the
Dick,
We can do it either way. We can push binaries up to the PPA, or we can
continue to do the bzrbuilder recipe->PPA. I would actually be doing the
bzrbuilder recipe on my local machine.
I can always fix the current cmake issue and do the Mac and eventually
Windows builds. I'd like to get Li
I agree on that, they are very useful to keep people updated on kicad over
ubuntu.
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo
On 11/03/2013, at 02:44, Dick Hollenbeck wrote:
>
> On Mar 10, 2013 6:50 PM, "Adam Wolf" wrote:
> >
> > Miguel,
> >
> > Wayne and Layne recent
On 11/03/2013, at 02:40, Adam Wolf 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 W&L property. I don't want to spread
> things out more than they have to be.
>
> While we're not big enough to pay either one of us
On Mar 10, 2013 6:50 PM, "Adam Wolf" 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 doing the same
with th
Nah, I think, if my releases are good enough, that I'd rather push them to
a central kicad thing, rather than to a W&L property. I don't want to
spread things out more than they have to be.
While we're not big enough to pay either one of us full time, all of our
designs are done with Kicad, and w
You're right, your recipes have always been open, :-)
Btw, in my opinion, if you will take care of mac osx builds, etc, and want
to keep them on your site,
to drive you some traffic to W&L, for me it looks right (as you would be paying
for electricity [at each build] + server + etc…),
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"
wrote:
> Adam, it sounds great, you're killing my excuse to buy a Mac Mini ;-),
> but
Adam, it sounds great, you're killing my excuse to buy a Mac Mini ;-), but
ok :D, will reinvest it wisely
on KiCad :)
I can provide you with an account to kicad-pcb.org to upload files as they
build, just let me know
if you need any help for the setup.
I think that's important tha
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
wrote:
> Awesome!!, thanks for testing Marti
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
On Mar 11, 2013, at 12:35 AM, Miguel Angel Ajo Pelayo
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`
> lrwxr-xr-x
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 manage
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 ->
../../.homebrew/Cell
Congratulations Miguel!
I just completed a build on a pristine Macbook Air.
Some (minor) comments:
You need "wget", "bzr" and "swig". I installed all of these with homebrew
without any problems. And you need cmake (not from homebrew, but cmake has
native OSX version).
Other prerequisites:
XCod
>> 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 <- th
On 10/03/2013, at 11:30, Martijn Kuipers wrote:
> Viva,
>
> On Mar 10, 2013, at 10:23 AM, Miguel Angel Ajo Pelayo
> 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 mountain lion and has not ppc sd
Viva,
On Mar 10, 2013, at 10:23 AM, Miguel Angel Ajo Pelayo
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 mountain lion and has not ppc sdk or
> rosseta anymore -the emulation layer-.)
>
Neither can m
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 mountain lion and has not ppc sdk or
rosseta anymore -the emulation layer-.)
Edit the wx patch in patches directory and look for a line that removes ppc (if
you want to try
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
40 matches
Mail list logo
