Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 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 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 Linux builds happening locally for Fedora users anyway. Anyway, I'm going to fix the cmake pythonpath thing, and get osx autobuilds working first, and we can revisit the others when those are tested and working. Speaking of pyhonpath, we need to rethink where we are going to put python modules, even for the case when we are not installing to a staging dir for purposes of packaging. Installing things that may need to be edited, into a read only (root writable) dir is not a practice that we have to continue. If we allow for setting env vars, then pythonpath can be modified to point additionally to a place that is convenient for kicad python module editor people. So I am not content with current. Cmakelists.txt strategy regarding over usage of system dirs. My concern remains, as stated above. Think well beyond the current situation to many more modules. And to the day when pcbnew is primatily a dso/dll. So no, I am not on board with your suggestion. Just lets find a place where modules can go that is a writable dir. After all don't we want people writing them? If you want to move into the future you have to be willing to challenge the past. How does blender do it? There, may be it makes sense to make a second package for KICAD_SCRIPTING_MODULES, as it's just a module to python, it could be the case that somebody wanted to install the pcbnew module in a server, without installing kicad itself, for example. That should go to site-packages of python. For kicad itself, the modules don't need to be installed anywhere, they are linked together into pcbnew itself to allow introspection, so may be for making the normal kicad ppa build, KICAD_SCRIPTING_MODULES should be disabled, and then a second build that only makes the KICAD_SCRIPTING_MODULES, that needs some cmake scripts rework. Does it make sense? Adam Wolf Wayne and Layne, LLC On Mar 10, 2013 8:45 PM, Dick Hollenbeck d...@softplc.com wrote: 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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? The PPA concept is a familiar and trusted one in ubuntu circles, would not want to lose that trust factor among new users of the daily testing builds. Note I said users. These binaries are for usage first, testing is a secondary issue, which is in proportion to numbers of users actually using it. Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 managed to do same thing for Windows users, I can provide a windows VM for that somewhere, or try to setup a cross compiling from linux once all the python+mingw+wxython mess gets working (and Dick + Brian + Wayne are working hard on this). Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:35, 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
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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() OUTPUT_VARIABLE PYTHON_SITE_PACKAGES OUTPUT_STRIP_TRAILING_WHITESPACE) Alternatively, there's a FindPythonLibrary.cmake here: https://github.com/lyricat/Hotot/tree/master/cmake/modules (source: http://stackoverflow.com/questions/1242904/finding-python-site-packages-directory-with-cmake ) On Mon, Mar 11, 2013 at 8:14 AM, Adam Wolf adamw...@feelslikeburning.comwrote: 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.comwrote: 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 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 Linux builds happening locally for Fedora users anyway. Anyway, I'm going to fix the cmake pythonpath thing, and get osx autobuilds working first, and we can revisit the others when those are tested and working. Speaking of pyhonpath, we need to rethink where we are going to put python modules, even for the case when we are not installing to a staging dir for purposes of packaging. Installing things that may need to be edited, into a read only (root writable) dir is not a practice that we have to continue. If we allow for setting env vars, then pythonpath can be modified to point additionally to a place that is convenient for kicad python module editor people. So I am not content with current. Cmakelists.txt strategy regarding over usage of system dirs. My concern remains, as stated above. Think well beyond the current situation to many more modules. And to the day when pcbnew is primatily a dso/dll. So no, I am not on board with your suggestion. Just lets find a place where modules can go that is a writable dir. After all don't we want people writing them? If you want to move into the future you have to be willing to challenge the past. How does blender do it? There, may be it makes sense to make a second package for KICAD_SCRIPTING_MODULES, as it's just a module to python, it could be the case that somebody wanted to install the pcbnew module in a server, without installing kicad itself, for example. That should go to site-packages of python. For kicad itself, the modules don't need to be installed anywhere, they are linked together into pcbnew itself to allow introspection, so may be for making the normal kicad ppa build, KICAD_SCRIPTING_MODULES should be disabled, and then a second build that only makes the KICAD_SCRIPTING_MODULES, that needs some cmake scripts rework. Does it make sense? Adam Wolf Wayne and Layne, LLC On Mar 10, 2013 8:45 PM, Dick Hollenbeck d...@softplc.com wrote: 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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? The PPA concept is a familiar and trusted one in ubuntu circles, would not want to lose that trust factor among new users of the daily testing builds. Note I said users. These binaries are for usage first, testing is a secondary issue, which is in proportion to numbers of users actually using it. Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 own python in linux you stop getting access to all the libraries available systemwide, that's important too, where possible (win32 is a different story) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 14:14, Adam Wolf adamw...@feelslikeburning.com wrote: 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 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 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 Linux builds happening locally for Fedora users anyway. Anyway, I'm going to fix the cmake pythonpath thing, and get osx autobuilds working first, and we can revisit the others when those are tested and working. Speaking of pyhonpath, we need to rethink where we are going to put python modules, even for the case when we are not installing to a staging dir for purposes of packaging. Installing things that may need to be edited, into a read only (root writable) dir is not a practice that we have to continue. If we allow for setting env vars, then pythonpath can be modified to point additionally to a place that is convenient for kicad python module editor people. So I am not content with current. Cmakelists.txt strategy regarding over usage of system dirs. My concern remains, as stated above. Think well beyond the current situation to many more modules. And to the day when pcbnew is primatily a dso/dll. So no, I am not on board with your suggestion. Just lets find a place where modules can go that is a writable dir. After all don't we want people writing them? If you want to move into the future you have to be willing to challenge the past. How does blender do it? There, may be it makes sense to make a second package for KICAD_SCRIPTING_MODULES, as it's just a module to python, it could be the case that somebody wanted to install the pcbnew module in a server, without installing kicad itself, for example. That should go to site-packages of python. For kicad itself, the modules don't need to be installed anywhere, they are linked together into pcbnew itself to allow introspection, so may be for making the normal kicad ppa build, KICAD_SCRIPTING_MODULES should be disabled, and then a second build that only makes the KICAD_SCRIPTING_MODULES, that needs some cmake scripts rework. Does it make sense? Adam Wolf Wayne and Layne, LLC On Mar 10, 2013 8:45 PM, Dick Hollenbeck d...@softplc.com wrote: 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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? The PPA concept is a familiar and trusted one in ubuntu circles, would not want to lose that trust factor among new users of the daily testing builds. Note I said users. These binaries are for usage first, testing is a secondary issue, which is in proportion to numbers of users actually using it. Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 wrote: 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 own python in linux you stop getting access to all the libraries available systemwide, that's important too, where possible (win32 is a different story) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 14:14, Adam Wolf adamw...@feelslikeburning.com wrote: 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 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 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 Linux builds happening locally for Fedora users anyway. Anyway, I'm going to fix the cmake pythonpath thing, and get osx autobuilds working first, and we can revisit the others when those are tested and working. Speaking of pyhonpath, we need to rethink where we are going to put python modules, even for the case when we are not installing to a staging dir for purposes of packaging. Installing things that may need to be edited, into a read only (root writable) dir is not a practice that we have to continue. If we allow for setting env vars, then pythonpath can be modified to point additionally to a place that is convenient for kicad python module editor people. So I am not content with current. Cmakelists.txt strategy regarding over usage of system dirs. My concern remains, as stated above. Think well beyond the current situation to many more modules. And to the day when pcbnew is primatily a dso/dll. So no, I am not on board with your suggestion. Just lets find a place where modules can go that is a writable dir. After all don't we want people writing them? If you want to move into the future you have to be willing to challenge the past. How does blender do it? There, may be it makes sense to make a second package for KICAD_SCRIPTING_MODULES, as it's just a module to python, it could be the case that somebody wanted to install the pcbnew module in a server, without installing kicad itself, for example. That should go to site-packages of python. For kicad itself, the modules don't need to be installed anywhere, they are linked together into pcbnew itself to allow introspection, so may be for making the normal kicad ppa build, KICAD_SCRIPTING_MODULES should be disabled, and then a second build that only makes the KICAD_SCRIPTING_MODULES, that needs some cmake scripts rework. Does it make sense? Adam Wolf Wayne and Layne, LLC On Mar 10, 2013 8:45 PM, Dick Hollenbeck d...@softplc.com wrote: 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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? The PPA concept is a familiar and trusted one in ubuntu circles, would not want to lose that trust factor among new users of the daily testing builds. Note I said users. These binaries are for usage first, testing is a secondary issue, which is in proportion to numbers of users actually using it. Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 equivalent) would be able to do it with their standard tools. Sorry about the threadsitting--but I'll be heading out in a moment anyway. Adam Wolf Wayne and Layne, LLC On Mon, Mar 11, 2013 at 8:25 AM, Edwin van den Oetelaar oetelaar.automatiser...@gmail.com wrote: 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 wrote: 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 own python in linux you stop getting access to all the libraries available systemwide, that's important too, where possible (win32 is a different story) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 14:14, Adam Wolf adamw...@feelslikeburning.com wrote: 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 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 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 Linux builds happening locally for Fedora users anyway. Anyway, I'm going to fix the cmake pythonpath thing, and get osx autobuilds working first, and we can revisit the others when those are tested and working. Speaking of pyhonpath, we need to rethink where we are going to put python modules, even for the case when we are not installing to a staging dir for purposes of packaging. Installing things that may need to be edited, into a read only (root writable) dir is not a practice that we have to continue. If we allow for setting env vars, then pythonpath can be modified to point additionally to a place that is convenient for kicad python module editor people. So I am not content with current. Cmakelists.txt strategy regarding over usage of system dirs. My concern remains, as stated above. Think well beyond the current situation to many more modules. And to the day when pcbnew is primatily a dso/dll. So no, I am not on board with your suggestion. Just lets find a place where modules can go that is a writable dir. After all don't we want people writing them? If you want to move into the future you have to be willing to challenge the past. How does blender do it? There, may be it makes sense to make a second package for KICAD_SCRIPTING_MODULES, as it's just a module to python, it could be the case that somebody wanted to install the pcbnew module in a server, without installing kicad itself, for example. That should go to site-packages of python. For kicad itself, the modules don't need to be installed anywhere, they are linked together into pcbnew itself to allow introspection, so may be for making the normal kicad ppa build, KICAD_SCRIPTING_MODULES should be disabled, and then a second build that only makes the KICAD_SCRIPTING_MODULES, that needs some cmake scripts rework. Does it make sense? Adam Wolf Wayne and Layne, LLC On Mar 10, 2013 8:45 PM, Dick Hollenbeck d...@softplc.com wrote: 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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 provide our modules to them. Anyway, if you're talking about pcbnew.py, for example, that should not be modified by humans, as it's auto generated swig mess (nice and useful mess by the way) that get's rebuilt / overwritten by new compilation. Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 15:06, Dick Hollenbeck d...@softplc.com wrote: 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 expect folks to put modules into. The idea of having an environment variable to tell CMake another place to put it is great, but I think site-packages is a sane default. I know of no python programmers named root. No thanks. My name is also not root. So on my system, this would be considered extremely inconvenient. I'd like to actually be able to edit the scripts. If the intention is to make them not editable, then we should write them in C++ and compile them. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 seen more projects where they put the default modules in dist/site-packages, than ones where they do not--however, the audience for kicad doesn't necessarily match the audience for these other projects. I believe the standard response for I want to modify these files that are part of the package is to copy them into another directory, like your ~/.kicad directory, put it higher on your PYTHONPATH than site-/dist-packages, and then modify away. For things that are purely python modules, and don't tie into apps, the status quo is putting it in Pypi and letting users install it however they want--these days, probably virtualenv and pip. From a python point of view, this might be the right answer, but I believe there was pushback on this when Miguel suggested something similar. I think it's also important we make the distinction between python pieces. We have some SWIGgy stuff, as well as human-readable and -modifiable things like the footprint wizard. If you want them to start out in a user-writable directory, what's the next step? Adam Wolf Wayne and Layne, LLC On Mon, Mar 11, 2013 at 9:06 AM, Dick Hollenbeck d...@softplc.com wrote: 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 expect folks to put modules into. The idea of having an environment variable to tell CMake another place to put it is great, but I think site-packages is a sane default. I know of no python programmers named root. No thanks. My name is also not root. So on my system, this would be considered extremely inconvenient. I'd like to actually be able to edit the scripts. If the intention is to make them not editable, then we should write them in C++ and compile them. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 PYTHONPATH or modify it for the user. I have seen more projects where they put the default modules in dist/site-packages, than ones where they do not--however, the audience for kicad doesn't necessarily match the audience for these other projects. I believe the standard response for I want to modify these files that are part of the package is to copy them into another directory, like your ~/.kicad directory, put it higher on your PYTHONPATH than site-/dist-packages, and then modify away. For things that are purely python modules, and don't tie into apps, the status quo is putting it in Pypi and letting users install it however they want--these days, probably virtualenv and pip. From a python point of view, this might be the right answer, but I believe there was pushback on this when Miguel suggested something similar. I think it's also important we make the distinction between python pieces. We have some SWIGgy stuff, as well as human-readable and -modifiable things like the footprint wizard. If you want them to start out in a user-writable directory, 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. what's the next step? Adam Wolf Wayne and Layne, LLC On Mon, Mar 11, 2013 at 9:06 AM, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com wrote: 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 expect folks to put modules into. The idea of having an environment variable to tell CMake another place to put it is great, but I think site-packages is a sane default. I know of no python programmers named root. No thanks. My name is also not root. So on my system, this would be considered extremely inconvenient. I'd like to actually be able to edit the scripts. If the intention is to make them not editable, then we should write them in C++ and compile them. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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
+34911407752
skype: ajoajoajo
On 11/03/2013, at 15:33, Dick Hollenbeck d...@softplc.com 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.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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
skype: ajoajoajo
On 11/03/2013, at 16:20, Adam Wolf adamw...@feelslikeburning.com 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 miguelan...@nbee.es
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
+34911407752
skype: ajoajoajo
On 11/03/2013, at 15:33, Dick Hollenbeck d...@softplc.com 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.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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
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
skype: ajoajoajo
On 11/03/2013, at 16:20, Adam Wolf adamw...@feelslikeburning.com 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 miguelan...@nbee.es
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
+34911407752
skype: ajoajoajo
On 11/03/2013, at 15:33, Dick Hollenbeck d...@softplc.com 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.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 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
Lets start by solving the big problem first. (Then fine tune over
time. The package maintainers always have an option to trump what we
do in CMakeLists.txt for their distro.)
CMAKE_INSTALL_PREFIX is nice. But it is only one variable, and this
forces the assumption that everything must be relative to one tree
root. Sometimes that is inadequate.
I would suggest that, on MY linux computer, I would like my kicad data
(projects, work, and personal libraries) all to go under ~/kicad/*
And that ALL the kicad python modules are best placed into
~/kicad/python/*. Maybe a subtree in there is appropriate, or flat.
Broadly speaking, I consider python scripts to be mostly like *data*
files, just as much as my schematics and boards. Mostly because I
want to be able to edit them easily.
KICAD_DATA_DIR could be a cache variable, and its default could be
~/kicad/
KICAD_PYTHON could be a cache variable, and its default could be
${KICAD_DATA_DIR}/python
For a linux computer shared by more than one user, the installer could
route the python modules to something like /home/kicad/python by
overriding the KICAD_PYTHON setting, then give rights to /home/kicad
to more than one user, some read only, but those that edit python
scripts, write permissions.
BTW, Python can now read *.py files out of a zip file, just like Java
and *.class files.
If someone wants to they can zip up *.py files and put them on the
PYTHONPATH, that would be an option for CMakeLists.txt's install
strategy, pertaining to the swig *.py files. But again, this is
1/20th as important to me as being able to edit what we are
optimistically calling scripts. To me a script is something I edit
every 20 seconds until I get it right. And of course getting it
right is where it gets personal.
On Mar 11, 2013 9:39 AM, Miguel Angel Ajo Pelayo
miguelan...@nbee.es mailto:miguelan...@nbee.es 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
+34911407752 tel:%2B34911407752
skype: ajoajoajo
On 11/03/2013, at 15:33, Dick Hollenbeck d...@softplc.com
mailto:d...@softplc.com 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.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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
miguelan...@nbee.es mailto:miguelan...@nbee.es 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
adamw...@feelslikeburning.com
mailto:adamw...@feelslikeburning.com 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
miguelan...@nbee.es mailto:miguelan...@nbee.es 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 d...@softplc.com
mailto:d...@softplc.com 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.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 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
miguelan...@nbee.es mailto:miguelan...@nbee.es 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
adamw...@feelslikeburning.com
mailto:adamw...@feelslikeburning.com 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
miguelan...@nbee.es mailto:miguelan...@nbee.es 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 d...@softplc.com
mailto:d...@softplc.com 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.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 is portable. Thanks also to your wife ;-) /Martijn On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 system and libraries inside kicad.app, and it's supposed to be accessible from all the other apps. I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a dependency to system's python2.7). If there is any adventurous out there, please try, and tell me how does it work (or doesn't). PS: The codename for the release is wife, as my wife has been taking care all saturday of our little Margarita, so she's a time donor to kicad now too ;) My build packaging script is temporarily here, for just in case anyone wants to compile himself.. https://github.com/mangelajo/KicadOSXBuilder Cheers!! ;) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 mountain lion and has not ppc sdk
or rosseta anymore -the emulation layer-.)
Neither can mine. I usually build single versions, because otherwise you are
basically downloading the program twice (or thrice when also including ppc).
Hehehe, yes, I talked with Marco about that, and he told me that nobody asked
for ppc version yet, and his binaries are i386+x64 so probably we shouldn't
spent time on that as long as we provide the means to build.
Edit the wx patch in patches directory and look for a line that removes ppc
(if you want to try with ppc) :)
Also only Mountain Lion (so happy to not have Rosetta around).
I send your thanks to my wife :)
Sent them to her, :D, she smiled ;)
I'm also thinking of a new structure to keep the demos system libs out of
the app bundle but in the app directory, as some other apps do
like
Applications/kicad/kicad.app (with the libs,etc)
Applications/kicad/pcbnew.app
Applications/kicad/*.app
Applications/kicad/shared/{libs,modules,templates,plugins…}
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 the libs
/Applications/kicad/libraries - footprints, components, etc.
/Applications/kicad/scripts - python user scripts
/Applications/kicad/doc - documentation and demos
?
Look to the patches/loader.sh on github, at this moment, all the libraries
*.dylib and files go inside kicad.app/Frameworks/ and the other apps use them
from there (../../../kicad.app/Frameworks) , wx and python-site mainly.
Also there are the demos+modules+etc in kicad.app/Resources/ or something like
that that's what I was planning to pull out of kicad.app again and yet leave
it findable for all the apps.
Kind regards,
Martijn
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo
On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote:
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 is
portable.
Thanks also to your wife ;-)
/Martijn
On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es
wrote:
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 system and libraries inside kicad.app,
and it's supposed to be accessible from all the other apps.
I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a
dependency to system's python2.7).
If there is any adventurous out there, please try, and tell me how does it
work (or doesn't).
PS:
The codename for the release is wife, as my wife has been taking care
all saturday of our little Margarita, so she's a time donor to kicad now
too ;)
My build packaging script is temporarily here, for just in case anyone
wants to compile himself..
https://github.com/mangelajo/KicadOSXBuilder
Cheers!! ;)
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 the libs /Applications/kicad/libraries - footprints, components, etc. /Applications/kicad/scripts - python user scripts /Applications/kicad/doc - documentation and demos ? Look to the patches/loader.sh on github, at this moment, all the libraries *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them from there (../../../kicad.app/Frameworks) , wx and python-site mainly. Also there are the demos+modules+etc in kicad.app/Resources/ or something like that that's what I was planning to pull out of kicad.app again and yet leave it findable for all the apps. https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f This is the change, I also re-uploaded kicad-scripting-osx-3992.zip :-) I think it's better like this, people can go into the data directory and change/fetch whatever they like :) Kind regards, Martijn Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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 is portable. Thanks also to your wife ;-) /Martijn On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 system and libraries inside kicad.app, and it's supposed to be accessible from all the other apps. I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a dependency to system's python2.7). If there is any adventurous out there, please try, and tell me how does it work (or doesn't). PS: The codename for the release is wife, as my wife has been taking care all saturday of our little Margarita, so she's a time donor to kicad now too ;) My build packaging script is temporarily here, for just in case anyone wants to compile himself.. https://github.com/mangelajo/KicadOSXBuilder Cheers!! ;) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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/Cellar/cmake/2.8.10.2/bin/cmake So we should document how to install brew, and cmake + wget + bzr + swig Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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: XCode and Xcode command line tools (obviously), which you can get from Apple. Then be patient and just watch the screens scroll by, but the result is really nice :-) The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, which is around 350MB unpacked. Um abraço, Martijn On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 the libs /Applications/kicad/libraries - footprints, components, etc. /Applications/kicad/scripts - python user scripts /Applications/kicad/doc - documentation and demos ? Look to the patches/loader.sh on github, at this moment, all the libraries *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them from there (../../../kicad.app/Frameworks) , wx and python-site mainly. Also there are the demos+modules+etc in kicad.app/Resources/ or something like that that's what I was planning to pull out of kicad.app again and yet leave it findable for all the apps. https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f This is the change, I also re-uploaded kicad-scripting-osx-3992.zip :-) I think it's better like this, people can go into the data directory and change/fetch whatever they like :) Kind regards, Martijn Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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 is portable. Thanks also to your wife ;-) /Martijn On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 system and libraries inside kicad.app, and it's supposed to be accessible from all the other apps. I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a dependency to system's python2.7). If there is any adventurous out there, please try, and tell me how does it work (or doesn't). PS: The codename for the release is wife, as my wife has been taking care all saturday of our little Margarita, so she's a time donor to kicad now too ;) My build packaging script is temporarily here, for just in case anyone wants to compile himself.. https://github.com/mangelajo/KicadOSXBuilder Cheers!! ;) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 managed to do same thing for Windows users, I can provide a windows VM for that somewhere, or try to setup a cross compiling from linux once all the python+mingw+wxython mess gets working (and Dick + Brian + Wayne are working hard on this). Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:35, 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` lrwxr-xr-x 1 ajo staff 47 2 mar 00:24 /Users/ajo/.rvm/bin/cmake - ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake So we should document how to install brew, and cmake + wget + bzr + swig Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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: XCode and Xcode command line tools (obviously), which you can get from Apple. Then be patient and just watch the screens scroll by, but the result is really nice :-) The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, which is around 350MB unpacked. Um abraço, Martijn On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 the libs /Applications/kicad/libraries - footprints, components, etc. /Applications/kicad/scripts - python user scripts /Applications/kicad/doc - documentation and demos ? Look to the patches/loader.sh on github, at this moment, all the libraries *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them from there (../../../kicad.app/Frameworks) , wx and python-site mainly. Also there are the demos+modules+etc in kicad.app/Resources/ or something like that that's what I was planning to pull out of kicad.app again and yet leave it findable for all the apps. https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f This is the change, I also re-uploaded kicad-scripting-osx-3992.zip :-) I think it's better like this, people can go into the data directory and change/fetch whatever they like :) Kind regards, Martijn Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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 is portable. Thanks also to your wife ;-) /Martijn On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 system and libraries inside kicad.app, and it's supposed to be accessible from all the other apps. I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a dependency to system's python2.7). If there is any adventurous out there, please try, and tell me how does it work (or doesn't). PS: The codename for the release is wife, as my wife has been taking care all saturday of our little Margarita, so she's a time donor to kicad now too ;) My build packaging script is temporarily here, for just in case anyone wants to compile himself.. https://github.com/mangelajo/KicadOSXBuilder Cheers!! ;) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo ___ Mailing list:
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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` lrwxr-xr-x 1 ajo staff 47 2 mar 00:24 /Users/ajo/.rvm/bin/cmake - ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake At my machine using cmake from home-brew threw an error (sorry, did not catch it). So we should document how to install brew, and cmake + wget + bzr + swig - XCode (from app store) and Command Line Tools for Xcode from (http://connect.apple.com) - Homebrew (http://mxcl.github.com/homebrew/) - wget, bzr and swig via homebrew: brew install wget bzr swig - cmake (http://www.cmake.org/cmake/resources/software.html) Easy as 1-2-3 ... Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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: XCode and Xcode command line tools (obviously), which you can get from Apple. Then be patient and just watch the screens scroll by, but the result is really nice :-) The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, which is around 350MB unpacked. Um abraço, Martijn On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 the libs /Applications/kicad/libraries - footprints, components, etc. /Applications/kicad/scripts - python user scripts /Applications/kicad/doc - documentation and demos ? Look to the patches/loader.sh on github, at this moment, all the libraries *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them from there (../../../kicad.app/Frameworks) , wx and python-site mainly. Also there are the demos+modules+etc in kicad.app/Resources/ or something like that that's what I was planning to pull out of kicad.app again and yet leave it findable for all the apps. https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f This is the change, I also re-uploaded kicad-scripting-osx-3992.zip :-) I think it's better like this, people can go into the data directory and change/fetch whatever they like :) Kind regards, Martijn Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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 is portable. Thanks also to your wife ;-) /Martijn On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 system and libraries inside kicad.app, and it's supposed to be accessible from all the other apps. I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a dependency to system's python2.7). If there is any adventurous out there, please try, and tell me how does it work (or doesn't). PS: The codename for the release is wife, as my wife has been taking care all saturday of our little Margarita, so she's a time donor to kicad now too ;) My build packaging script is temporarily here, for just in case anyone wants to compile himself.. https://github.com/mangelajo/KicadOSXBuilder Cheers!! ;) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 managed to do same thing for Windows users, I can provide a windows VM for that somewhere, or try to setup a cross compiling from linux once all the python+mingw+wxython mess gets working (and Dick + Brian + Wayne are working hard on this). Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:35, 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` lrwxr-xr-x 1 ajo staff 47 2 mar 00:24 /Users/ajo/.rvm/bin/cmake - ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake So we should document how to install brew, and cmake + wget + bzr + swig Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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: XCode and Xcode command line tools (obviously), which you can get from Apple. Then be patient and just watch the screens scroll by, but the result is really nice :-) The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, which is around 350MB unpacked. Um abraço, Martijn On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 the libs /Applications/kicad/libraries - footprints, components, etc. /Applications/kicad/scripts - python user scripts /Applications/kicad/doc - documentation and demos ? Look to the patches/loader.sh on github, at this moment, all the libraries *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them from there (../../../kicad.app/Frameworks) , wx and python-site mainly. Also there are the demos+modules+etc in kicad.app/Resources/ or something like that that's what I was planning to pull out of kicad.app again and yet leave it findable for all the apps. https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f This is the change, I also re-uploaded kicad-scripting-osx-3992.ziphttp://dev.kicad-pcb.org/pkgs/macosx/kicad-scripting-osx-3992.zip :-) I think it's better like this, people can go into the data directory and change/fetch whatever they like :) Kind regards, Martijn Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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 is portable. Thanks also to your wife ;-) /Martijn On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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.ziphttp://dev.kicad-pcb.org/pkgs/macosx/kicad-scripting-osx-latest.zip It has all the new kicad templates system and libraries inside kicad.app, and
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 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/Cellar/cmake/2.8.10.2/bin/cmake So we should document how to install brew, and cmake + wget + bzr + swig Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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: XCode and Xcode command line tools (obviously), which you can get from Apple. Then be patient and just watch the screens scroll by, but the result is really nice :-) The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, which is around 350MB unpacked. Um abraço, Martijn On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 the libs /Applications/kicad/libraries - footprints, components, etc. /Applications/kicad/scripts - python user scripts /Applications/kicad/doc - documentation and demos ? Look to the patches/loader.sh on github, at this moment, all the libraries *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them from there (../../../kicad.app/Frameworks) , wx and python-site mainly. Also there are the demos+modules+etc in kicad.app/Resources/ or something like that that's what I was planning to pull out of kicad.app again and yet leave it findable for all the apps. https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f This is the change, I also re-uploaded kicad-scripting-osx-3992.zip :-) I think it's better like this, people can go into the data directory and change/fetch whatever they like :) Kind regards, Martijn Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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 is portable. Thanks also to your wife ;-) /Martijn On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 system and libraries inside kicad.app, and it's supposed to be accessible from all the other apps. I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a dependency to system's python2.7). If there is any adventurous out there, please try, and tell me how does it work (or doesn't). PS: The codename for the release is wife, as my wife has been taking care all saturday of our little Margarita, so she's a time donor to kicad now too ;) My build packaging script is temporarily here, for just in case anyone wants to compile himself.. https://github.com/mangelajo/KicadOSXBuilder Cheers!! ;) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help :
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 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 that we keep the building recipe and enhancements fully open, so anybody can rebuild it easily, even if we're caught by a bus (thing I don't expect or want) :D In fact, many parts (like packaging, loading or linking tweaks) would be better integrated into KiCad cmake scripts, and pulled out of the build.sh. PS: I'm remembering that Jean Pierre asked me so long ago about a download area, and I totally forgotten, may be soon will be the time for downloads.kicad-pcb.org or equivalent place. Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:50, 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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 managed to do same thing for Windows users, I can provide a windows VM for that somewhere, or try to setup a cross compiling from linux once all the python+mingw+wxython mess gets working (and Dick + Brian + Wayne are working hard on this). Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:35, 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` lrwxr-xr-x 1 ajo staff 47 2 mar 00:24 /Users/ajo/.rvm/bin/cmake - ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake So we should document how to install brew, and cmake + wget + bzr + swig Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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: XCode and Xcode command line tools (obviously), which you can get from Apple. Then be patient and just watch the screens scroll by, but the result is really nice :-) The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, which is around 350MB unpacked. Um abraço, Martijn On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 the libs /Applications/kicad/libraries - footprints, components, etc. /Applications/kicad/scripts - python user scripts /Applications/kicad/doc - documentation and demos ? Look to the patches/loader.sh on github, at this moment, all the libraries *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them from there (../../../kicad.app/Frameworks) , wx and python-site mainly. Also there are the demos+modules+etc in kicad.app/Resources/ or something like that that's what I was planning to pull out of kicad.app again and yet leave it findable for all the apps. https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f This is the change, I also re-uploaded
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? The PPA concept is a familiar and trusted one in ubuntu circles, would not want to lose that trust factor among new users of the daily testing builds. Note I said users. These binaries are for usage first, testing is a secondary issue, which is in proportion to numbers of users actually using it. Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 managed to do same thing for Windows users, I can provide a windows VM for that somewhere, or try to setup a cross compiling from linux once all the python+mingw+wxython mess gets working (and Dick + Brian + Wayne are working hard on this). Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:35, 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` lrwxr-xr-x 1 ajo staff 47 2 mar 00:24 /Users/ajo/.rvm/bin/cmake - ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake So we should document how to install brew, and cmake + wget + bzr + swig Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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: XCode and Xcode command line tools (obviously), which you can get from Apple. Then be patient and just watch the screens scroll by, but the result is really nice :-) The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, which is around 350MB unpacked. Um abraço, Martijn On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 the libs /Applications/kicad/libraries - footprints, components, etc. /Applications/kicad/scripts - python user scripts /Applications/kicad/doc - documentation and demos ? Look to the patches/loader.sh on github, at this moment, all the libraries *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them from there (../../../kicad.app/Frameworks) , wx and python-site mainly. Also there are the demos+modules+etc in kicad.app/Resources/ or something like that that's what I was planning to pull out of kicad.app again and yet leave it findable for all the apps. https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f This is the change, I also re-uploaded kicad-scripting-osx-3992.zip :-) I think it's better like this, people can go into the data directory and change/fetch whatever they like :) Kind regards, Martijn Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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 is portable. Thanks also to your wife ;-) /Martijn On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: Hi, I've been working on the release of Kicad with scripting for MacOSX, also tried to package it all together with
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 to pay either one of us full time, all of our designs are done with Kicad, and we didn't pay a dime for that. We're glad to do what we can. It's more ore less our spirit here, but, anyway, many people use kicad extensively and don't contribute, in my opinion (not sure how others feel about it), it's not bad to get contributions paid back / credited somehow, whenever it sounds reasonable. Thanks for your efforts, really! :) Adam Wolf Wayne and Layne, LLC On Mar 10, 2013 8:21 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 WL, for me it looks right (as you would be paying for electricity [at each build] + server + etc…), but anyway if we keep a bunch of releases/log and a mirror on the kicad site itself, it's yet better ;) Cheers, Mike Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 02:14, Adam Wolf adamw...@feelslikeburning.com wrote: 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 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 that we keep the building recipe and enhancements fully open, so anybody can rebuild it easily, even if we're caught by a bus (thing I don't expect or want) :D In fact, many parts (like packaging, loading or linking tweaks) would be better integrated into KiCad cmake scripts, and pulled out of the build.sh. PS: I'm remembering that Jean Pierre asked me so long ago about a download area, and I totally forgotten, may be soon will be the time for downloads.kicad-pcb.org or equivalent place. Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:50, 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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 managed to do same thing for Windows users, I can provide a windows VM for that somewhere, or try to setup a cross compiling from linux once all the python+mingw+wxython mess gets working (and Dick + Brian + Wayne are working hard on this). Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:35, 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` lrwxr-xr-x 1 ajo staff 47 2 mar 00:24 /Users/ajo/.rvm/bin/cmake - ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake So we should document how to install brew, and cmake + wget + bzr + swig Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote: 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
Re: [Kicad-developers] Mac OSX build, with scripting, codename wife
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 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 Linux builds happening locally for Fedora users anyway. Anyway, I'm going to fix the cmake pythonpath thing, and get osx autobuilds working first, and we can revisit the others when those are tested and working. Speaking of pyhonpath, we need to rethink where we are going to put python modules, even for the case when we are not installing to a staging dir for purposes of packaging. Installing things that may need to be edited, into a read only (root writable) dir is not a practice that we have to continue. If we allow for setting env vars, then pythonpath can be modified to point additionally to a place that is convenient for kicad python module editor people. So I am not content with current. Cmakelists.txt strategy regarding over usage of system dirs. My concern remains, as stated above. Think well beyond the current situation to many more modules. And to the day when pcbnew is primatily a dso/dll. So no, I am not on board with your suggestion. Just lets find a place where modules can go that is a writable dir. After all don't we want people writing them? If you want to move into the future you have to be willing to challenge the past. How does blender do it? There, may be it makes sense to make a second package for KICAD_SCRIPTING_MODULES, as it's just a module to python, it could be the case that somebody wanted to install the pcbnew module in a server, without installing kicad itself, for example. That should go to site-packages of python. For kicad itself, the modules don't need to be installed anywhere, they are linked together into pcbnew itself to allow introspection, so may be for making the normal kicad ppa build, KICAD_SCRIPTING_MODULES should be disabled, and then a second build that only makes the KICAD_SCRIPTING_MODULES, that needs some cmake scripts rework. Does it make sense? Adam Wolf Wayne and Layne, LLC On Mar 10, 2013 8:45 PM, Dick Hollenbeck d...@softplc.com wrote: 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 doing the same with the Linux builds. While I like the PPA autobuilder, the build environment isn't like what the devs use, so the PPA breaks on a regular basis--and then it's hard to see why, because my box isn't emulating the PPA environment exactly. This is currently the case with the cmake thing. I can even push my built packages back up to my PPA, so the transition could be seamless to end users. What do you guys think? The PPA concept is a familiar and trusted one in ubuntu circles, would not want to lose that trust factor among new users of the daily testing builds. Note I said users. These binaries are for usage first, testing is a secondary issue, which is in proportion to numbers of users actually using it. Adam Wolf Wayne and Layne, LLC On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: 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 managed to do same thing for Windows users, I can provide a windows VM for that somewhere, or try to setup a cross compiling from linux once all the python+mingw+wxython mess gets working (and Dick + Brian + Wayne are working hard on this). Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:35, 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` lrwxr-xr-x 1 ajo staff 47 2 mar 00:24 /Users/ajo/.rvm/bin/cmake - ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake So we should document how to install brew, and cmake + wget + bzr + swig Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 01:29, Martijn Kuipers
