kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

eeschema and bitmap2component now build in the new Kiway branch.

Other apps do not yet.


http://bazaar.launchpad.net/~kicad-stable-committers/kicad/kiway/revision/4660?remember=4658

I only made two commits to this branch, the baseline, i.e. branching off point was 4658.


I got rid of the Return function prefixes, which seem obvious to me.  (I did not replace
them with a "Get" prefix, which I never got.  When you have a Set*(), you can have a
Get*(), otherwise I'm going lean.)

That accounted for probably at least 10,000 lines if you were to do a line count on a patch.


I started with bitmap2component, which was easiest, then eeschema since I would not trip
on scripting.

The KIWAY and KIFACE interface with one another.  KIFACE is the interface into a *.kiface
file, which is a first tier DSO.  Something has to reside above that, namely the process
or program link image itself.

That is where the KIWAY(s) live.  There is only one KIFACE for each DSO.  Not all DSOs are
KIFACEs because not all would be a first tier DSO.  2nd tier DSOs, at least one, will be
coming as part of this work, and will have nothing to do with the KIWAY alchemy.

Got that?


Now, this is revision specific information, and could change tomorrow:

As a development aid for running the debugger or for permanent construction, you can link
the KIFACE and other object files with the program launcher, collapsing the two link
images into one, e.g. a single *.EXE like before.  There is still a KIWAY in there, one or
more.

For milestone A) of the modular-kicad blueprint, there is to be a program launcher.  Its
name is single_top.c.  It gets compiled multiple times and takes compiler command line
#defines.  So in effect linking single_top to a kiface implementation gives you a way to
build a program which is not discussed in milestone A).  bitmap2component uses this
technique in this revision, i.e. single_top is linked directly to KIFACE implementation,
and everything else.

eeschema in this demo revision, is linked according to milestone A).  That means you have
a eeschema.exe and _eeschema.kiface.  I have not had a problem stepping through a debug
build of _eeschema.kiface on linux.  Just put a breakpoint at line 282 or so, the call to
KIFACE::CreateWindow().

eeschema probably has some minor problems still, library paths may still be screwed up.

Since a lot of stuff was being held in a wxApp derivative, and that entity lives in the
launcher not in the workhorse *.kiface link image, we had to migrate stuff out of there.
A lot of stuff.

That migration plus the Return removal makes the patch 14569 lines long, breaking my
personal record in 2007 of some > 4,000 lines.

I've pushed the branch into the ~kicad-stable-committers area so Jean-Pierre and Wayne can
help fix little stuff if they are so inclined.

I will glean these emails in the future and write some text documention files describing
all the new classes, and there are a lot.  Until then doxygen may help you get an
understanding.

Also the blueprint does not call for the KIWAY to be functional until about milestone B).
 Everything leading up to that is the KIFACE.

Dick