kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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