Hi Miguel- You probably figured it out already, but here's my super simple build script for the latest. Assuming you already have the bzr branch in this structure:
42 |- build_latest # build script, chmod a+x |- kicad.latest # as it says |- build.latest # this folder the script makes automatically -lajos ################################################################################ #/bin/zsh -f mkdir -p build.latest && cd build.latest cmake ../kicad.latest -DKICAD_STABLE_VERSION=ON -DCMAKE_BUILD_TYPE=Release \ -DUSE_PCBNEW_SEXPR_FILE_FORMAT=ON -DUSE_PCBNEW_NANOMETRES=ON \ -DCMAKE_INSTALL_PREFIX=/usr make ################################################################################ On Sun, Apr 8, 2012 at 3:25 PM, Miguel Angel Ajo Pelayo <miguelan...@nbee.es> wrote: > I must be doing something very silly.... > > just pulled from bzr, and then > mkdir building > cd building > cmake -i ../ > make > > and make says nothing at all, and exists.... :-? > I must re-read the compiling guide.... ':-) > > 2012/4/8 Dick Hollenbeck <d...@softplc.com> >> >> On 04/08/2012 11:38 AM, lajos kamocsay wrote: >> > Hi Wayne- >> > >> > >> > The new file format looks awesome. Very simple and readable. >> > >> > Would it be possible to standardize the transformation data? Currently >> > there seems to be a couple different formats, some examples: >> > >> > (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) >> > (width 0.127)) >> > >> > (size 1.016 1.651) >> > >> > (at -1.524 0) >> > >> > (at (xyz 0 0 0)) >> > (scale (xyz 0.17 0.16 0.16)) >> > (rotate (xyz 0 0 0)) >> > >> > I think having a standard format would be very helpful for external >> > utilities reading/writing kicad data, like: >> >> >> Without diminishing your point about standardization, I suggest that >> Miquel's scripting >> interface will soon be the recommended way to write "external tools". >> >> And as such, folks writing directly to the KiCad file formats will be >> missing the point of >> the scripting API, so they will not get any of my attention, at least. >> >> Back to the transformation data, we have both 3d and 2d transforms, and it >> would be >> sensible to allow them to be different. Also, the SWEET parser is already >> written, works >> on 2d transform data, and I assume Wayne took that into consideration. >> Changing the 2d >> SWEET stuff is something I would not embrace easily. >> >> I am not taking such a position on this new BOARD format yet however, but >> rather keeping >> an open mind. However, achieving some 2d transform similarly between >> SWEET and BOARD >> might have at least some value. >> >> >> Dick >> >> >> >> _______________________________________________ >> 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 > > > > > -- > > Miguel Angel Ajo Pelayo > http://www.nbee.es > +34 636 52 25 69 > 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