Re: gEDA-user: Life and death for gEDA: portability...

[Bill Cox <bill@viasic.com>]

EATON,JOHN (HP-Vancouver,ex1) wrote:

> <As for porting, guile has proven too hard to support for me... 
[snip]

> What sort of problems have you run into? There was some talk about packaging
> guile and all other needed libs in with gEDA so that there would be no
> issues
> with versions or locating libs in various distros. Would this help?
>  
Yes, this would be great.  Linux enthusiasts who carefully manage all 
the files on their machines will probably be against the duplication, 
but to support large numbers of users, it's a good idea.  In fact, if 
things were packaged up fully, and if I could get the gEDA stuff to 
compile on my machine (much easier with captive libraries), I might be 
able to build gnetman using nothing but the libraries that ship with 
gEDA.  In theory, this could mostly eliminate the porting problems, and 
make using guile easier.  I'd love to have  the whole thing install with 
one rpm -i command.  I'd love the whole thing to compile with a cvs 
checkout, configure, make, and make -install.

As a side issue, if we were to package up all the gEDA files in a nice 
package that had all it's own libraries built-in, there's still the 
issue of what guile API to use.  The old one (used by most gEDA tools) 
is quite different than the new one.  I tried to port gnetman to the new 
one, and found it difficult to do.  I hate to write new code to an 
obsolete interface.

> One of the nice things about OS software is that it tends to be rather
> modular
> so one could come up with a tcl_netlister in parallel with the current one. 
> I'd give it a shot but my IC design group is heavily into perl as the
> "One_True_
> Langauge".
>
> John Eaton
Perl is very popular among chip designers.  A little glue and packing 
tape, and you can make anything work...  Actually, I could very quickly 
put out a TCL (or guile) scriptable version of gnetman that would 
support writing netlisters.  However, I'd rather see a gnetman -> 
gnetlist path so we can use all the existing netlisters.  Also, gnetman 
is meant to enable IC sized projects, and an interpreted netlister may 
just be a bit too slow given how easy it is to write a fast compiled 
one.  I'd hate to have an interpreted netlister in my LVS flow,  for 
example.  I think custom C netlisters make sense for the larger files 
that get generated during IC verification: flattened post-optimized 
Verilog, VHDL (VITAL compliant), SDF, and SPICE.

Bill