Mail Archives: geda-user/2013/01/14/17:38:02
Ben Gamari wrote:
> This weekend I took some time to distill a skeleton gEDA project from
> one of my recent designs. The resulting tree can now be found on
> Github[1] and includes,
>
> * a script to automate the initial configuration of the project
Very nice!
I like the way, you can see in github, what the result will look like.
My take on the same subject can be found on gedasymbols.org :
http://www.gedasymbols.org/user/kai_martin_knaak/new_geda_project.sh
This is a script I actually use to start geda projects. So it provides a
skeleton with a few more bones:
* an empty schematic file with a project name, date and developer filled
out in the title block.
* an empty layout file with my preferred layer stack.
* a doc directory with a lyx document that contains a number of standard
sections for documentation
* a print directory for rendered PDFs and print scripts. The print
scripts may be modified to match the needs of the specific project.
* a gerber directory for gerbers with a script that prepares the gerbers
from the layout file.
* a bom directory for the bill of materials and whatever additional
information the assembler needs.
* a directory for files related to the enclosing. 3D CAD drawings, etc.
* a directory for old versions of the project
In addition, my script optionally prepares a bare git repo to push to.
Looking at your skeleton-project I realize a major ommission in my
approach: I don't arrange for symbols and footprints in local directories.
This is in part, because I tend to embed symbols if a project is "ready"
for the archive. That way, *.sch and *.pcb are the only master files,
from which everything else can be derived.
> * a Makefile for performing some common tasks (e.g. generating
> tragesym symbols, updating the pcb layout, and exporting gerbers)
I found, Makefiles add to the barriers perceived by newbies. Even simple
Makefiles like yours look like incomprehensible magic spells to the
uninitiated. So I stick with the less elegant bash scripts.
> * further discussion to clarify a few common questions about the
> toolchain
Yes, documentation is a (very) weak spot in most of geda.
> Having used the toolchain for
> some time now, it is frustrating to see that so many open hardware
> projects continue to be designed in Eagle and the like.
+1
Is there any high profile open hardware project that endorses geda?
---<)kaimartin(>---
- Raw text -