Jeff VR wrote:
Stuart Brorson wrote:
I'm looking for some help in debugging this problem. Is there an
intermediate step I can run to try and figure out if the problem is
with the footprint or my schematic? What triggers the m4 library to
kick in?
I see a long discussion thread about your particular problem, so I
won't interfere there. However, to see what libraries are searched
for footprints, you can run gsch2pcb in double verbose mode:
gsch2pcb -v -v project
It will print out a detailed itinery of what it is doing while
processing your board. THis is very useful for debug purposes like
the one you have at hand.
Stuart
_______________________________________________
geda-user mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Thanks for contributing. I've been trying do debug this problem for
quite some time and as a newbie it been quite challenging to figure this
one out. Familiar with some common command line switches I looked for
the -v option a couple of weeks ago and found it be helpful. I also
found the comments about checking for schematic errors using gnetlist -g
... to be helpful as well. The frustrating thing is that the error
information is the same. I tried the double -v switch on the test.sch
we created to try and figure out this problem and didn't seem to give me
any more clues.
Jeff
Hi Jeff,
Could you send the -v -v output here?
I have an idea as to whats going on but need to do a bit more homework
before I suggest too many crazy ideas.
I think the underlying problem is that gsch2pcb feeds a single instance
of m4 lots of PKG_* macros. However the m4 libraries weren't designed
to work this way. They were designed for 1 call to m4 for 1 footprint.
When multiple footprints are fed through 1 m4, you can get all sorts
of name collisions when one footprint macro defines an internal macro
but that then conflicts with some names used by a different footprint
macro. I suspect this is whats going on here.
If you find your gnet-gsch2pcb.scm (part of the gnetlist install) file,
whats the version? Or actually, whats the geda version you're using?
I'll see about sending you a hacked up version of this file that will
save out an intermediate file that we can use to get to the bottom of this.
Longer term, I'm wondering if maybe the right way to go is to generate a
pcb actions file and let pcb pull in footprints rather than trying to
much with what are really internals of pcb.
-Dan
_______________________________________________
geda-user mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
