Re: gEDA-user: vexing problem: m4:stdin:7: bad expression in eval

[Dan McMahill <dan@xxxxxxxxxxxx>]

Traylor Roger wrote:
> Dan,
> 
> As you requested......


> nbuster_3.sch:footprint=TSSOP-65P-640L1-14N

This is the culprit

> As you can see, many of the footprints have a "-" but these are
> from John Luciani's footprint library.  These have not caused 
> any problems up to this point.

With older versions of gsch2pcb, what happens is each of the footprints 
gets turned into a like like:

PKG_TSSOP-65P-640L1-14N(foo, bar, baz)

now the whole thing is fed to m4.  Some of the footprints will expand to 
valid footprints, some will be left as PKG_<name>(arg1, arg2, arg3), and 
some like the TSSOP one will be partially expanded.

Then gsch2pcb looks for file elements for the unexpanded footprints and 
optionally replaces the m4 generated ones with file ones.

Unfortunately, this is an abuse[1] of a *private* part of pcb so it is 
really no wonder that it causes problems from time to time.

Newer versions of gsch2pcb (can't recall exactly when "newer" was) have 
a option that prevents ever running m4.

In this particular case, PKG_TSSOP is an internal macro that expects 
several arguments and produces a TSSOP footprint.  When you feed 
PKG_TSSOP-65P-640L1-14N(foo, bar, baz) to m4, it tries to expand only 
the PKG_TSSOP part but there are no arguments.  Now the internal code 
there flakes out.

-Dan

[1] Nothing external to pcb is ever supposed to invoke m4.  The way the 
m4 libraries have historically been implemented in pcb, there are 
controls against garbage in like this.  The pcblib.contents file 
constrains what is ever passed to m4 *and* m4 is only fed 1 package 
macro at a time.  Contrast this to gsch2pcb which freely feeds any sort 
of input to m4 and it feeds many at once.  Note that pcb has *never* 
claimed that the m4 stuff should be directly called by some external 
program.  Even pcb doesn't call it directly like that.

In fact in the last couple of pcb releases, m4 doesn't need to be called 
at runtime by pcb.  It is used at build time to generate all of the 
footprints which are defined via m4 macros.  Before anyone says 
otherwise though, the m4 libraries are not deprecated though.  All of 
the footprints build and many (but not all) are fairly decent.  For 
example, that's where to go if you want 3-tier footprints based on IPC 
recommendations for things like surface mount R's and C's.

So, how to fix the situation?  Someone needs to endow pcb with an action 
that instantiates a footprint.  Then gsch2pcb should generate an action 
file for pcb to execute to do the instantiations.  pcb should provide 
this as a documented public interface and gsch2pcb should stop abusing a 
private interface.  At a minimum, gsch2pcb should simply stop trying to 
ever call m4.





_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user