[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



couldn't resist this one...

On Sat, Dec 27, 2003 at 01:04:18PM -0500, Bill Cox wrote:
 
> The dependence on various packages, particularly guile and it's friends, 
> could easily doom this whole effort.  Imagine a random IT guy in a 
> medium sized company has been asked to install gEDA on 100 Linux 
> workstations.  What does he do?  So far as I've seen, a correct response 
> on this guy's part is to panic, and perhaps put together a resume.

well, my guess is its actually not too bad...  I'm not a linux user, but
I am a gEDA user.  On NetBSD, I either do
"pkg_add ftp://ftp.netbsd.org/pub/NetBSD/packages/1.6.1/alpha/All/gEDA";
to install a prebuilt package (with dependencies like guile and gtk being
added automatically), or if there isn't a pre-built package recent enough
for me or for my hardware platform (yes gEDA runs on many non-i386 sytems)
then I do "cd /usr/pkgsrc/cad/geda && make install".   Did I mention that
the NetBSD package system (pkgsrc) has been ported to quite a number of
other operating systems too?  On the solaris9 box (sparc) I have at home, I did
"cd /usr/cvs/NetBSD/pkgsrc/cad/geda && make install", went to lunch,
came back and cranked out a number of schematics which I promptly checked
into CVS since gEDA conveniently uses a well documented ASCII format...


> Frankly, I doubt companies will standardize gEDA software for internal 
> use so long as the porting problems persist.  Given the pace of guile 
> development, this could be years.  In that time, there is plenty of room 
> for some other open-source effort to take hold and prosper.

I've been using gEDA on solaris at work although for board level schematics
not IC schematics.  There I use it on sparc/solaris boxes.  Someone else
had built guile and gtk1.2 and added it to the software deployment system
used there.  Adding gEDA was really quite painless for me.

> -- guile

unfortunately this takes rewriting all the netlisters which have been 
written in guile.  Speaking as one who has written 3 different netlist
backends for gnetlist, I really couldn't ask for an easier environment
to do it in.  They just haven't been hard at all.  Of course I haven't
been targetting some of the more complex output types or dealing with
hierarchy.

 
> As for the GUI, I would not write most of the code directly to Gtk 1.2, 
> or Gtk 2.0, or any such thing.  Instead, I'd do what was done in several 
> other popular and portable packages like Mozilla, AbiWord, and 
> OpenOffice: write most of the GUI code to a portable interface layer 
> that hides the OS, and then write a lean custom wrapper for each OS. 
> This allows the tools to look like a Mac application on a Mac, and a 
> Gnome application in Linux, and just like an application Microsoft would 
> have written on a PC.

For what its worth, I can name several major CAD vendors who deal with
this in a considerably worse way than gEDA.  cadence doesn't even have
a consistent UI across its products which are supposed to work with each
other and they're just now starting to deal with other than 8 bit
displays.  Synplicity uses a lame windows emulation library which combines
turtle like speed with a crappy interface (all windows remain in the one
synplify window).  The mathworks seems to think java is a good idea...
So, in the grand scheme of things, running under GTK which works on most (all?)
major unix-like OS's as well as windows and soon (if not already) macos,
is a pretty good portability position to be in I think.  Besides, gtk and
guile are readily available in the various packaging systems in use by
different OS's.  

I also have to say that the number of bugs I've been bitten by in gEDA 
have been quite low compared to certain very expensive CAD tools and
some in house CAD tools (not from my current employer) I've used in the
past.  I've seen things in these commercial tools (not naming names here)
like netlists which don't match the schematics which generated them,
synthesis tools which ignore some of the constraints given, simulators
which forget to initialize themselves at the first time step, schematic
capture tools with no undo feature (no I'm not kidding), etc.  So I think
this all actually bodes quite well for gEDA.

-Dan

--