Felix: ... > Thanks for your interest. There are plugins for geda schematics [1], but > with some problems.
> [1] http://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/log/?h=geda That repo is a little strange, I get this: $ git clone git://git.savannah.gnu.org/gnucap/gnucap-plugins.git Cloning into 'gnucap-plugins'... remote: Counting objects: 4666, done. remote: Compressing objects: 100% (1567/1567), done. remote: Total 4666 (delta 3020), reused 4666 (delta 3020) Receiving objects: 100% (4666/4666), 1.87 MiB | 1.59 MiB/s, done. Resolving deltas: 100% (3020/3020), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. $ cd gnucap-plugins/ $ git co geda Branch 'geda' set up to track remote branch 'geda' from 'origin' by rebasing. Switched to a new branch 'geda' $ It seems it consists of a few non-connected branches. > Connections in gEDA schematics are implicit, and port positions are > needed to infer them. For this, the symbol database is required. The gEDA > library has been used to look up the symbols. Don't you get the connections from the netlist ? > When I try to configure gnucap-geda, I get > [..] > checking for libgeda >= 20100214... no > configure: error: gEDA package not found ./bootstrap works fine here, but ./configure gives: checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate ./configure: 16616: GC_CPPFLAGS+= -I/usr/local/include/gnucap: not found ./configure: 16618: CPPFLAGS+= : not found checking l_dispatcher.h usability... no so something is strange. $ ls -l /usr/local/include/gnucap/l_dispatcher.h -rw-r--r-- 1 karl users 3877 Feb 3 18:29 /usr/local/include/gnucap/l_dispatcher.h > Unfortunately, installing libgeda-dev does no longer work (for me). > > The following packages have unmet dependencies: > libgeda-dev : Depends: guile-2.0-dev but it is not installable > libgeda42 : Depends: guile-2.0-libs but it is not installable > Depends: libgc1c2 (>= 1:7.2d) but it is not installable I think something is not good enough with guile-2.0, and that the libgeda package should be updated for a newer guile version. Bug your distro about that. > I don't know what it takes to fix it. Ideally the dependency on libgeda > should be avoided, as it makes things more complicated than necessary. > (Any workaround/hack will improve things!). Wouldn't it be best if geda/lepton supported gnucap instead of the other way around ? The guile 1.8 to 2.x step was a bit painful in general. My guess is that geda with its xorn need some time to evolve out of the guile dependancy and strange things happens there, at least for me. So currently I'm mostly working with lepton. so... my gueass is that geda/lepton changes faster than gnucap, and that is why they should support gnucap and not the other way around. > Next steps are more technical, and I am happy to talk about it. Now > there is a translator "Qucs schematics" <=> "Verilog schematics", and I > can think of a way to do gEDA schematics properly... Yes ? Regards, /Karl Hammar
