kicad-developers team mailing list archive

[Rick Walker <walker@xxxxxxxxxxxxxx>]

Hi Dick,

> it because I don't care if my old software does not load new
> footprints.  (I type $ make, and I can load the new footprints.) 

I know you are a code developer and have the highly idiosyncratic kicad
build process finely balanced at all times.  Typing "make" works for you. 

I've tried to build kicad three times now, at intervals several months
apart.  It has always locked up for various problems that involved
internal settings in other RPM packages that didn't match the Fedora
defaults.  This means that I would need to install source for several
other packages, hand configure them and build those packages from
scratch to get kicad to build. 

Now imagine that I'm trying to get kicad adopted as a useful tool at
work so that we could use some of our development effort to contribute
to the project. 

Kicad is currently a moving target.  The team doesn't provide "stable"
builds and the whole system is liable to blow up at any time.  It
is even worse if one uses the "cloud-based" libraries which are under
dynamic mutation.  

The fedora packagers can only guess at which snapshot is the least
broken and package it up.  If bugs are found, the answer given is
"rebuild it yourself".  Unfortunately, any version that we "rebuild
ourselves" is also likely full of new, different bugs.  The normal way
to fix this problem for code released by adults is to have a stable
version that gets a functionality freeze, but has bugs back patched from
the development tree.  It's a pain, but it makes the program useable for
real work.  Sometimes, being an adult is inconvenient.

I completely support the effort to make kicad more resistant to a
particular subset of future changes to the footprint definition file. 
Having a real tool catastrophically fail when encountering data files
should only occur very rarely and only at announced major revisions. 
It's not acceptable to just keep creeping the shared data files and have
an installed base break every few weeks.  Making the parser ignore
non-recognized fields makes it possible to add in certain classes of new
behaviors without affecting an installed base of real users doing real
work. 

You can do the make easily, because you are obviously a rare uber-guru,
but I can tell you that as a relatively skilled C-coder and linux admin,
it is not a trivial process and certainly not something to require an
average user to do on a regular basis under panic conditions. 

That is, not if you want kicad to be something relevant instead of just
a venue for playing around with fun code ideas. 

Although I was able to get our team to do several very complex designs
in Kicad, the team has now switched Allegro for reasons that I'd be
happy to go into at a future time if anyone is interested. 

kind regards,
--
Rick Walker