On Mon, 2008-04-21 at 10:22 +0200, fricker wrote: > On 21 avr. 08, at 02:53, Peter Clifton wrote: [...]
> Reading you it seems to me that the gschem file format changes less > often than a potential API in libgeda. I should therefore keep such > parser/writer completely independent from libgeda and base it only on > the file format. I.e. I went down the right path so far... Thanks! > > BTW: Parse:RecDescent provides the extra benefit of error handling, > it flags quite nicely if the file has errors and where, in a top-down > fashion. I didn't write any parsing code, just its grammar. [...] > It's just the way Data:Dumper outputs an internal data structure of > arrays [] of hashes {} containing string elements and other arrays, > containing hashes, etc. I can just access things like this then to > change the sheet number on every sheet of a design: > > $data[$file_idx]->{objects}->[$object_idx]->{Attributes}->[$attr_idx]- > >{value} = $sheets++; > > > What sort of processing are you needing to automate in this way? > > Here is a short list: > - update/create sheet to sheet net cross references (with ~200 > sheets, this is a must have!) That is a lot of sheets! So far, my power converters sit at ~ 20 sheets, for 5 small(ish) boards. How big boards are you working with? > - update current sheet number and total sheet numbers > > - replicate similar subsections of schematics (a given schematic page > used multiple times where you need to update refdes and netnames). > Some might want to use hierarchical designs instead, but I stay away > from such approach for board design! I use a Makefile, and a modified version of refdes_renum, but my solution is far from optimal. A perl module to read / write the schematic to/from a data structure (like you did), would probably be a nicer way of scripting those changes. > - update component attributes based on an "Approved Device > List" (output from a PLM database), i.e. add/update device=<part > number> on passives based on value, tolerance and ratings attributes > and verify the other active components > > - design-wide component updates (with correct handling of attributes > and symbol version changes) > > - design-wide cleanup and checks (text size, alignment, location, not > connected nets, etc., mostly to enforce drawing guidelines) > > - generate multiple versions of a given root schematic based on a > configuration file: simulation vs. prototype vs. production bom > alternatives, each one having its own set of pdf, etc. I use a > bom=1,2,... attribute to tag such alternatives in the root design, > then change it to bom=NOSTUFF in the specific versions, this way the > folks debugging the board don't have to look-up the bom options in a > table. I then generate actual boms using gnetlist out of these > derived schematic files. I also replace the CVS tags such that they > look neat when printed. > - generate tagged pdf, with sheet to sheet net links and attributes > pop-ups. That would be very neat to see. > And all of this has to be controllable through Makefiles, this way > the generation process is inherently documented for your coworkers or > newbies. > > I used to use Makefiles and sed s/.../.../ a lot but file-wide regex > are dangerous since it isn't so easy to control what the s/.../.../ > is really going to change. Indeed, and it needs something more complex (awk?) to pick out context such as "s/.../.../" for attribute "foobar=..." on a device with "refdes=R10[0-9]" > And I would not want this to be integrated in the gschem gui! gschem > is - and IMHO should remain - just a drawing tool. It is far more > powerful and convenient to control the above with perl scripts and > Makefiles, including and especially bom handling stuff. I can't imagine how you could integrate all that, even if someone wanted to. > What I need to achieve all of this is a Perl module that offers: > - readFiles([EMAIL PROTECTED]) that returns a reference to an array of hashes > > (file names are pushed into the data structure) > - writeFiles([EMAIL PROTECTED]) that writes the data structure back into the > files (file names are within the data structure already) > > I could package what I have and share it if anyone is interested. I think a lot of people would appreciate that, I'd certainly be interested. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user