One of the joys of free software is that people feel passioniately about it!
Please allow me to reiterate my point, respond to your posting, and then I will disappear. If I were to re-write PCB (a task which is probably beyond me), I'd make it have one footprint library. That footprint library would be ASCII text based, and each symbol would live in its own file. Each footprint file would hold a graphical representation of the footprint -- something like (but not necessarily) a .svg file. You would create/edit the footprint using one of: -- PCB's graphical footprint editor -- Another graphical footprint editor or drawing program (perhaps yet to be written). -- A stand-alone script written in the language of your choice. (Even M4 if you are a masochist). -- Emacs or some other text editor. This is similar to how symbols are treated in gschem, and "it just makes sense" (TM). > M4 is "obscure" and TCL, Perl, and Python are not?? Yes. :-) > M4 has shipped with EVERY UNIX-like OS for the past 20+ years. By my > definition, that's called "ubiquitous", not "obscure". Lots of chip designers use TCL & Perl for automated design tasks. I have never seen M4 used anywhere except as part of the GNU make system. Except for PCB, of course. Can you name another place where M4 is used on a modern unix machine besides deep inside the automake system? Can you name a place where non-software engineers use M4 for routine scripting jobs? Can you name a place where software engineers use M4 for routine jobs? > > Generating footprints using an automated, parameterized method is a > > good thing. I completely agree. Do it using TCL, Perl, or > > Python. > > Use a scripting language to process macros instead of a macro > processor, in other words. Two points: 1. Your standard PCB designer has no idea what a macro is. He just wants to place some footprints. Requiring him to understand what M4 is doing is a turn-off for PCB's acceptance in the general design community. 2. Why do we need "on the fly" footprint generation anyway? What's wrong with graphical descriptions of the footprints living in files, like all other layout tools use, and PCB uses for its second lib? My opinion: Having two libs, one of which requires understanding M4, is confusing to most PCB designers. Since its confusing, it's an unnecessary turn-off, and it limits the update of PCB in the general community, which is bad for all of us gEDA hackers! > PERL (you know, the Practical Extension and Reporting Language) is > not the right tool for this job. Fine. Use your favorite scripting language to create stand-alone utilities which generate parametrized symbols. > If I have to install the bloated pig that is Perl in order to use > PCB, I will find another layout package. Heh -- I'm glad you feel so passionately about PCB. I am not advocating grafting the bloated pig of Perl into PCB. I *am* advocating that we exorcise the ghost of Unix past -- M4. I think that PCB should only have one lib, and that lib should hold graphical representations of the footprints, not macros written in an obscure language. > Existing, perfectly functional, fast, builds-and-runs-on-EVERYTHING > tools are not an appropriate battleground for the PerlTribesmen to try > to infect. LOL -- I like the image of being a Perl tribesman -- even though I am not trying to stick Perl into PCB! Ummmm . . . . as for "builds-and-runs-on-EVERYTHING", here's what the PCB FAQ says on Sourceforge: <sourceforge quote> Although a native windows port of PCB does not exist, PCB has been compiled successfully under cygwin. You will need Xfree86 to be installed as well as gcc, make, m4, and tcl/tk. Please note that cygwin is not the typical platform of PCB developers and support for this port may be lacking. </sourceforge quote> That's my point; I couldn't say it more eloquently. For PCB to be accepted amongst the general PCB layout designer community, it has to become more "typical" of a PCB layout tool. This means one library with ASCII files holding graphical descriptions of the footprints. No M4. Stuart
