1. what is gsch2pcb-rnd It's an old tool to assist forward annotation from gschem (lepton) to pcb-rnd (geda/pcb). It's obsolete and there are multiple better alternatives already, so if you haven't used it yet, don't start using it. If you are stil using it, you should really really really consider switching to a different method. 2. what to use instead If you are using sch-rnd, you can't use gsch2pcb-rnd at all. Just use import sch from pcb-rnd with the sch-rnd method or if you prefer Makefiles export a tedax netlist using "sch-rnd -x tedax" command line then run a pcb-rnd command line to import that netlist. If you are using gschem or lepton: best use pcb-rnd's import schematics with the gnetlist or lepton method (_not_ the gEDA method, that's the old gEDA netlist file format). If you prefer to do more steps and less automation: "recent" versions of gschem/lepton can export tedax netlists, so you can also export tedax netlist using gnetlist or lepton-netlist and then import it in pcb-rnd. Either loading the tedax file as a netlist, or setting up the import schematics feature with the tEDAx method on the exported netlist file. Notes: - you can use the import schematics feature both from GUI _and_ CLI. This means if you prefer shell scripts and Makefiles, you can use import schematics from there too. It's really just running pcb-rnd with a few commands instead of a command with gsch2pcb-rnd. Tutorial on import schematics from Makefiles: http://repo.hu/cgi-bin/pool.cgi?project=pcb-rnd&cmd=show&node=make_import - the terminology is broken; a netlist is normally only a list of connections, which is not enough for a forward annotation. You'll need footprints and preferrably some other metadata (attributes) as well. The original geda/pcb netlist format doesn't have those extras, tEDAx netlist does have all metadata. - the difference between "import netlist" and "import schematics" in pcb-rnd is exactly that: the former imports netnames and connections only, the latter imports netnames, connections, footprints and attributes - the gsch2pcb* vs. import-sch debate is not about makefiles vs. gui, because import-sch works for both. It's really about "using a workflow with broken design _and_ then having to execute 2..4 steps manually after each forward annotation" (gsch2pcb*) vs. single click/single command annotation that does everything automatically (import-sch). 3. why gsch2pcb* is bad There are many design issues with the original gsch2pcb, basically the whole design is just a bad idea: sitting between two large projects, depending on and trying to understand too much of the internals of both. Since it's not really belonging to any project, many project tends to have a fork of it, pcb-rnd included (in lepton I think they are rewriting it in scheme). Because of the broken design, it has to do a lot on both sch and pcb side, but it can't really understand the config of both sides. The -rnd variant fully understands pcb-rnd conf at least, but it won't understand gschem/lepton conf. The non-rnd variants of gsch2pcb are even worse: they typically try to parse geda/pcb footprints/boards to figure missing footprints. The -rnd variant fixed this long ago, so at least the relation between gsch2pcb-rnd and pcb-rnd is acceptable. 4. what's the good approach Take a step back. The whole problem was that people wanted to do forward annotation from sch to pcb, but the netlist format did not contain enough information (footprint and metadata/attributes). Instead of fixing that, someone wrote a tool, gsch2pcb, to work this around. The proper solution, obviously, is to have a file format that contains all information necessary for a proper forward annotation and get all tools talk that format. The format is tEDAx netlist, and it is supported by: - pcb-rnd - sch-rnd - xschem - gschem - lepton The only notable software missing from this list is geda/pcb - which is pretty much unusable with anything else than gschem/lepton. So if you use a gschem/lepton-to-geda/pcb workflow, you have to use one fork of gsch2pcb (but you are probably not reading this anyway). In any other case, using tEDAx netlists in one way or another is a much cleaner solution. Why is it cleaner: because this lets us separate our tools with a clean API in between them, the UNIX way. These are all the possible solutions: A. sch side smart export: sch editor or netlister knows pcb-rnd (or geda/pcb) action script language so it can export all the actions to get the pcb editor to load the footprints and create the connections. Bad, because sch tries to know too much of the specific pcb software B. pcb-rnd (or geda/pcb) trying to extract the metadata from the sch sheets. Bad, because pcb tries to know too much of the sch side C. a tool in between, like gsch2pcb*, so we can keep pcb side and sch side separate. Bad, because in return we have a hardto maintain tool that depends on the itnernals of two other large projects D. have a simple API (file format) in between sch and pcb that delivers all info necessary for an fwd annotation. Good, because each tool needs to know only its own internals and no 3rd tool is needed for the annotation.