[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: weird names in PCB part library
On Aug 20, 2004, at 12:57 PM, Stuart Brorson wrote:
M4 is "obscure" and TCL, Perl, and Python are not??
Perhaps back in the stone age, when PCB was written for the=20
Altair 8800^H^H^H^H^H^H^H^H^H^H Atari , generating symbols on the
from an M4 macro was a good idea in order to save space memory.=20
Seems to have totally misunderstood.
Well, perhaps I don't know exactly why M4 was used to generate symbols
when PCB was written over 20 years ago. But I *do* think I know a
thing or two about circuit design. And from the standpoint of a
circuit designer (i.e. our target audience for gEDA), M4 is
unnecessarily old, scary, nasty, and obscure. For PCB to make inroads
into the circuit design community, it needs to act and feel like a
contemporary PCB layout tool. M4 is unnecessary baggage. Footprint
files -- i.e. PCB's second lib -- are the way it's done these days.
Creating parameterized footprints using stand-alone TCL, Perl, or
Python scripts would be more attractive and more contemporary.
M4 has shipped with EVERY UNIX-like OS for the past 20+ years. By my
definition, that's called "ubiquitous", not "obscure".
Use a scripting language to process macros instead of a macro
processor, in other words.
Creating using M4 means that you can generate footprints in a=20
*parameterized* manner, which is 100 times better than the WYSIWYG=20
Generating footprints using an automated, parameterized method is a
good thing. I completely agree. Do it using TCL, Perl, or
PERL (you know, the Practical Extension and Reporting Language) is
not the right tool for this job.
If I have to install the bloated pig that is Perl in order to use
PCB, I will find another layout package.
The problem is that the maintenance of the M4 library is sketchy,
best. It really needs a full overhaul, to make it consistent and
parameterized, but that is another matter.
Well, it's sketchy because it is an obscure relic which nobody wants to
support. All the more reason to jettison it and use contemporary,
supported languages like Perl or Python utilities to generate symbols
Existing, perfectly functional, fast, builds-and-runs-on-EVERYTHING
tools are not an appropriate battleground for the PerlTribesmen to try
Dave McGuire "...it's a matter of how tightly
Cape Coral, FL you pull the zip-tie." -Nadine Miller