On 02/27/2012 01:48 AM, Miguel Angel Ajo Pelayo wrote: > I've been doing some experiments about that during the weekend, with python > as a first > target, and using SWIG (which should be highly desired, as it's something > easier to > mantain). > > And by now, what I found is that swig is quite mature, but mainly ready for > this: > > Python--->[extension]/extension_wrap.o ---->library.so > > This is one of our intended usages, but, for usage inside kicad: > > Kicad<--->Python-->extension--->Kicad
I think to accomplish all our goals, we will have to split PCBNEW and EESCHEMA into at least two parts each, perhaps three. (Third part might be the graphics functions.) This means you keep a main() part, and have one or two DLL/DSO's beneath that main process entry point. This is my vision even *before* SWIG enters into it. This lets you then have a replaceable main() part, that is a number of alternative implementations of the top level process entry point. EESCHEMA and PCNBEW core document functions are held in what is essentially shared libraries. I foresee at least 3 such alternative top main() parts: a) simple command line processing main() without a scripting language. b) scripting language main(), for any SWIG favorite language(s). c) normal UI main() where the wxFrame and Dialogs reside. For the final use case, which is normal UI but also with scripting: Once you have this split (or these split_s_, if you consider a second DLL/DSO for drawing functions), then like mortar in between two stacked bricks, there is a place to put a shim in there, that is inject something below c) to handle the case where you want the normal UI but also want scripting. > > It may require some hacking. Your word, not mine. I don't ever remember having hacked any code. :) > They had an embed.i that can be a start point. The problem is that SWIG build > wrapper > modules that are ready to be loaded from python, but they include all the > swig logic. So > then, if we linked kicad + python lib + wrapper_kicad.cxx + > wrapper_eeschema.cxx + > wrapper_pcbnew.cxx then the swig code would be x3 times. I mention all this so that you understand what we have been talking about, and don't forget the BOARD_ACTION class, which is also still missing. This is a way of pulling non-UI verb type code down into the DLL/DSO layer without distancing it so far that it cannot still be part of the c) wxFrames above. I talked about using multiple inheritance to bring BOARD_ACTION back into the frame. Doing this across a DLL/DSO chasm will be a trick, but it might be possible. If it cannot be made to work, we can fall back to separate link images, where you simply have identical code in a number places. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
