> hid plugins can be built without the whole source tree. We can already do that. Heck, it's been done, too - Igor added an interpreter engine much like what swig does, which supports writing interpreted HIDs.
> The real point of the patch was that I want to create swig bindings > for pcb and libgeda in support of another geda subproject I'm working > on. To do that I really need a library to build the bindings against. Except that PCB is an application, not a library. If swig assumes the target is a library (I don't think it does), perhaps that means that swig is a bad choice? Or perhaps you could change the way you're trying to use it? As soon as we split out a library, we have to start worrying about compatibility across releases, which is a pain. > Admittedly, there is more work that needs to be done to properly > separate the pcb executable from the libpcb library and provide some > more API coherency. > > I'm willing to do that, Doing it right is a lot of work, and if we're putting that much work into the core design of pcb, I'd rather shoot for a bigger prize than just "support swig". For example, I'd like to redo how drawing tools and board objects are handled internally so we can extend those with plugins as well. We've also gotten many requests for enhancements to the board layout, which would require design changes. Formalizing an API would make it more difficult to make those changes, if only because people would complain when you change the API. Plus, you'd still have to convince us that we need a "libpcb". _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
