Re: gEDA-dev: Re: Gschem and Cairo graphics library

[Dan McMahill <dan-at-NOSPAMmcmahill_dot_net>]

Mike Jarabek wrote:
> Hi,
> 
>     To interject my $0.02 CDN.
> 
> Stephen Williams wrote:
> 
>>Levente wrote:
>>
>>  
>>
>>>I think the "dependency hell" is provided by your OS, not by the human nor gEDA. If someone can't figure out the dependencies, (s)he can't use gEDA, and I think no other EDA toolset.
>>>
>>>    
>>>
>>
>>Nonsense. There are plenty of (expensive) software packages that
>>do *not* impose on a user this dependency hell. So it's possible.
>>This hell is very much of our own making.
>>
> 
> After having installed some of those commercial EDA tools on both Linux 
> and Solaris  I have to comment that they way they have solved the 
> dependancy problem is to:
> 
>     a) Limit support to certain distributions of Linux, or in the case 
> of Solaris, certain releases.
>     b) Ship pre-compiled binary images of _EVERYTHING_ needed to make 
> the tool go and/or provide statically linked binaries
>     c) Add setup environment scripts that get customized as part of the 
> installation process.
> 
> Let me address the points one at a time.
> 
>     Point a,  while this works for the big companies to whom you are 
> shelling out the big bucks, it is clear from the recent, and indeed not 
> so recent discussions on this topic, that we wish to support as many 
> different distributions as possible.  The only solution for that is 
> apparent to me is to follow the model in point 'b'.  Where volunteers 
> are needed to do the build on their distribution.
> 
>     Point b,  this leads to multi-disk images for most of the software. 
>  Your typical Cadence tool release takes on the order of 1Gig of hard 
> drive space to install.  The Xilinx tools for Linux are about the same, 
> once you install all the ancilliary stuff like documentation and device 
> libraries.  The bloat here comes from the philosophy that everything 
> needs to be included.  That is, both the Cadence and Xilinx tool install 
> a copy of perl and automatically link all thier scripts up to it.  They 
> don't rely on the operating system supplied utilities to work, or be 
> installed correctly.  As an example for us, for PCB, this would mean 
> shipping a copy of GNU M4 along for the ride.  This is also somewhat 
> contrary to the philosophy that I have been hearing about lately on the 
> list. (w.r.t. the inclusion of a PDF in a distribution file.)  The 
> effect of the inclusion of everything in one package swamps the effect. 
>  There was some discussion of a chrooted distribution on the list the 
> other day, and this approaches, and goes furhter than indeed,  the model 
> that the `big guys' use.

And part of the reason for point a is point b.  My experience has been 
that any time some package includes sources for a bunch of extra libs in 
its own distribution and expects them to build cleanly it ends up being 
a pain.

As a more concrete example, scilab includes its own distribution of pvm. 
  As one who has maintained the NetBSD pkgsrc package for scilab it is 
always a major pain because their copy of pvm doesn't have proper 
definitions for all the various NetBSD architectures.  Unfortunately it 
is often times the newest and highest performing architectures which are 
left out (x86_64, sparc64, etc).  So now I either get to hack on the 
scilab build system to force it to use the pvm which is already in 
pkgsrc which is more up to date and also has patches to make it work on 
all NetBSD platforms or I get to maintain Yet Another set of patches for 
scilab's copy of pvm.

With regards to a), many commercial EDA vendors don't just limit support 
  to particular linux distribution, they limit it to a particular 
release of it and often times that release is _old_.

-Dan




_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev