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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user