This page is intended to help users to chose between sch-rnd and gEDA by providing an objective comparison on various properties (as of 2023).

Major features

property sch-rnd gEDA/gschem lepton-eda
explicit abstract model yes no no
views (different plugin filters for output, results visible on screen; e.g. slotting, devmap, portmap) yes no no
portmap (attribute based solution to the transistor problem) yes no no
devmap (library based solution to the transistor problem) yes no no
arbitrary object groups yes no no
recursive object groups (group-in-group) yes no no
query language for listing/accessing objects yes no no
back annotation from pcb-rnd yes, full:
understands items, tracks what's done, helps navigation, auto-fix
partial:
presents items
no
embedded scripting 12+ different turing complete languages (including: awk, lua, python, perl, multiple lisp variants) scheme (guile) and python only scheme only (guile)
development active inactive active
distro packaging support official debian, mageia, unofficial/user: arch gschem: phasing out lepton: in major distros
loads symbol formats native lihata, gschem sym (more to come) only native gschem only native gschem sym
loads sheet formats native lihata, gschem's, tinycad's (more to come) only native gschem sch only native gschem sch
parametric symbols yes no no
GUI support gtk4, gtk2+gl, gtk2+gdk, lesstif - runtime selectable, dynamic loadable plugins gtk2 gtk2 or gtk3, compile time selection
portability Linux, BSD, any UNIX system with motif (C89, no GNU dependency) Linux, BSD, modern UNIX systems (C99+ and C++, requires glib, guile and may depend on GNU), windows Linux, BSD, modern UNIX systems (C99+, requires glib, guile and may depend on GNU), windows
license GPL2+ GPL2+ GPL2+

Minor features

property sch-rnd gEDA/gschem lepton-eda
translations English only multiple languages
documentation user manual: html (pdf);
auxiliary/contributed: knowledge pool
user manual: texi (html, pdf);
auxiliary/contributed: wiki
configuration system scconfig (./configure && make && make install is always enough; dependency: C89) autotools (./configure && make && make install; may require autogen.sh, libtool; dependency: auto*, m4)
native file format lihata (tree structured text, named fields) custom text format, positional parameters, missing tree representation
runtime configuration unified tree structure, key/value/type; mechanism for dealing with system, user, project, file and session level configs, including list merges scheme based (executable!) scheme based (executable!) and ini-like

Explanation and comments

explicit abstract model

The abstract model is what the schematics capture software (or netlister) thinks the sheets of a project mean. For example there are different ways of connecting a pin to a network (graphical, by drawing wires; or using data: attributes). And there are different ways the pin number emerges (e.g. hardwired vs. slots). These are just little differences in the representation of the same final intention, which is a connection between the given pin to the given network.

In sch-rnd these conclusions (final pin numbers, network names, connections, etc). are called the abstract model, while user input (the sheets) are called concrete model. There is a common, file format independent infrastructure that calculates (compiles) the abstract model from the concrete model. This has several advantages:

In gEDA the abstract model and compilation are hidden. Some parts of them are implemented in a way that the GUI is aware of it (e.g. slotting). These are usually hard to change or override. Other parts are delegated to netlist backends, which is more flexible but also forces backends to implement their own idea and otherwise generic concepts become backend-specific. The result of whatever the netlist backend does is never fed back to the GUI, so the only way to know the final network names or connections is to look at a netlist. If anything went wrong, tracing back why the central code or the format specific backend code made the decision, what sources has been used in that specific piece of output is hard.

Views

The flexible part of compilation is a configurable ordered list of plugins that should be executed during compilation. If there are different alternatives to slotting or pinouts, this configured list tells sch-rnd which one to use.

Such a configuration is called a 'view'. There can be multiple views configured and it is easy to switch between them on the GUI and in exports. For example a PCB view would do slotting and display physical package pin numbers on the sheet. A spice view would not do slotting but change "refdes" of symbols to make slots unique, and would display (the equivalent of) "pinseq". Selecting the right view will keep the relevant info shown, the info as used in the current workflow.

In gEDA there is no explicit abstract model so:

Portmap

The transistor problem is that with gEDA you can't have both:

It is because the fundamentally same npn transistor comes with different pinout (e.g. "base is pin 1" vs. "base is pin 3") per package per vendor. So you have to hardwire the pinout either in your symbol or in your footprint, which means you will need to have a set of per-pinout (or per-model) symbols or per-pinout footprints.

Or you have to, as many users do, have a 3rd tool somewhere between sch and PCB that loads the pinout from a 3rd party "database" and edits the sch or the netlist or the pcb to apply the pinout. However, in this case, you usually won't be able to see the final pin numbers on the sheet, which doesn't help debugging the board.

sch-rnd solves this problem by a flexible compilation setup where plugins can make transformations. An optional plugin, provided with sch-rnd, runs the standard portmap feature, which allows specifying the pinout in a symbol attribute. This way:

Devmap

A standard (but optional and replaceable) plugin provides the devmap feature in sch-rnd. Devmap depends on a devmap library, which is similar to a symbol or footprint library, but instead of graphical data, it stores information about "how to edit attributes of a generic light symbol to make it model-specific". It can set any attribute, typically footprint and portmap. Together with the standard portmap mechanism, this allows the user to:

gEDA doesn't have an equivalent method.

Scripting

Gschem and lepton depend on guile. Gschem also depends on python. You can't run gEDA without these dependencies even if you don't plan to write scripts and don't plan to use 3rd party scripts. However, if you do want to script the tools (to add new functionality) you have to use scheme (and/or python in case of gschem). If you prefer tcl or lua or awk, you are out of luck.

sch-rnd is written in C and does not run or depend on scripting for standard functionality. However, if you do want to extend sch-rnd with user script, you can choose from more than a dozen different scripting languages! But they are all only optional dependencies.

sch-rnd exposes a lot to scripting, for example user scripts can:

Parametric symbols

Besides static file symbols, sch-rnd can generate symbols by executing external processes. This way we do not have to generate 100 different connector symbols that differ only in the number of pins (just to find the user needs a 101th), but we can provide a connector() symbol where the number of pins is just a parameter that can be any integer.

Since the symbol is generated by an external process, it can be written in any programming language, compiled or interpreted, sch-rnd doesn't care.

Parametric symbols fully integrate in the symbol library, including the GUI library window, including having a preview.

(A similar feature, parametric footprints, is available in pcb-rnd.)