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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
