gEDA-dev: footprint cleanup

[Dan McMahill]

Timmerman, Bert wrote:
> Hi Igor2 and Dan,
> 
> I agree, if it's not clear or suitable, the average user/newbie would
> start with the creation of a newlib footprint.
> 
> I once looked at an m4 file and decided it was not for me.
> 
> A footprint generator that can be invoked with pcb would also be handy
> (some kind of gui hid module/wrapper around m4).

Then why not provide a more generic "run this command and load the 
element that the command spits out" action instead of having pcb needing 
to know about m4 calls?

> BTW, on a higher level (pcb file): another problem in footprint
> cleanup/creation and audition/correction lies in the fact that once
> embedded footprints (as in older designs) are never updated when a bug
> is corrected in a footprint.
> 
> This is in contrast with gschem, where one has to embed a symbol on
> purpose (explicit), and a modified (not embedded) symbol will be loaded
> with the schematic.
> 
> Wether this is a bug or a feature of pcb is not for me to decide.

A little bit of both.  By having the footprint embedded, you can send 
someone the .pcb file and they have everything.  Here are some notes I 
put together on my thoughts about how we might address the updating problem.

http://pcb.cvs.sourceforge.net/pcb/pcb/doc/ideas/database.txt?revision=1.1&view=markup&pathrev=MAIN

I'll note that this problem is made considerably more difficult if you 
don't store the footprints in files since you have to now run the 
various generators to see if a 'new' footprint is available.

> I also like the idea that we don't have 10000 megabytes of footprint
> files
> which differ only in 2 bits from one another. Maybe because I don't have
> 160 GB disks :)

the result of the full conversion of all m4 footprints to newlib is 3Mb. 
  Thats for a few thousand footprints.

> Maybe the best would be to have a HID or other _simple_ C api to
> separate
> the footprint loading and have the newlib and the m4 code in different
> directories, like the HIDs in hid/. This also would allow one to expand
> the footprint side easier (databases and whatevers).

but what I'm wanting to change _only_ affects the way pcb loads the 
footprints.  It does not change the users ability to use or abuse the m4 
macros outside of pcb.  From within a running pcb, there will be no 
visible difference (other than a slight reorg).

There is still no reason you couldn't run m4 from outside of pcb just 
like you can today.

Again, what I'm talking about is how pcb loads the libraries.

-Dan