kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Apr 21, 2014 at 11:26:53AM -0500, Dick Hollenbeck wrote:
> 1) I can decide where I expect to find the KIFACEs, your strategy relies on the OS to tell
> the loader.  This is a user PITA issue, and reliability of the install.

In the same way it finds the wx libraries, in /usr/lib[64] or whatever.

> 2) I can set the LD_ENV_VAR environment variable programmitically in my program which
> tells where the libs that the KIFACEs need are.  People do not know how to do this on
> their own.

LD_LIBRARY_PATH, the same

> 3) Your way, the program won't load at all if ALL the DSOs are not found immediately.  And
> all dependencies they may have.

Same for the wx modules if not monolithic. Also AFAIK there is no plan
of a 'partial' kicad installation. If you want to do 'eeschema without
pcb', then your approach would be the only one working.

> 4) It will load slower, and load some KIFACEs not of interest to someone just wanting to
> work in schematic.

Partially true, but it only needs to relocate, since executable paging
is on demand, but many people prelink these days. Also the UNO model in
openoffice actually slowed it down a lot, when it was introduced (but
maybe loading was not the issue there).

> 5) You will have possible name collisions in the link process of the top *.exe.

*This* would be a good thing, since these collision would happen at
runtime (probably undetected). Had many crashes from dynamically loading
a library using a different libjpeg version:P The global issue we talked
about before. In fact this is my primary reason for preferring a link instead
of a load. One process core => one symbol namespace

> 6) It is not as flexible moving forward, the above arguments only get more pronounced as
> should you add additional KIFACEs.

*If* you want to cater to 'arbitrary' interfaces (like the mozilla
plugin loader) then I agree your design is better. For the current and
near future I don't see an improvement.

> So no, I do not agree, again.   File a bug report if you have problems.
> 
> Or take it up with the core development team, which is now lead by Wayne.
> 
> They have conversations among themselves, and have chosen people in that group in part by
> how easy they are to work with.  I noticed you are not in the group.

I'm just discussing the design, not forcing opinion on how to do things.
It's called 'reviewing' and 'suggesting'. If the core team don't want to
discuss the best way to do thing too bad for them. I'd have preferred
keeping different processes with a better IPC (M0Q, corba, soap, xmlrpc,
dcerpc, whatever) but I agree that the portability issues were serious
in that case.

Potential problems I have on mind about the current implementation:

- One 'window' crashes, everything go down, obviously :P of course
  crashing is undesired anyway, so it's not an issue :D (even windows
  explorer has the 'open window in another process' for that, but see
  below for the reason)

- SIGINT (or xkill) to eeschema pull down the associated pcbnew (or
  viceversa if pcbnew gets an open schematic button), if I got this
  correctly... this is not very nice (I agree it's a minor issue).  In
  fact I *never* use the open pcb button in eeschema or the kicad
  project manager because wx messes up the process group management
  creating a similar issue.

  Sadly many modern programs don't follow the 'one toplevel window for
  process' guideline, too bad. I'd actually have split the
  module/library viewers/editors in different processes... but then
  process creation in Windows is a *very* heavy operation, while a fork
  itself is lighter than opening a file. So a compromise is needed.

- What if I open the schematic in one instance and the board in another
  one? Do I lose cross probing? 

- Somewhat related to the above: what if I have two different boards
  implemented for the same schematic? We do this regularly for the same
  circuit for different clients... so i use circuit.sch,
  circuit-c1.kicad_brd and circuit-c2.kicad_brd; if the 'open board' can't be
  customized in some way (instead of always opening circuit.kicad_brd)
  it would be difficult to handle. Possible workaround: a file open from
  the pcbnew windows would keep the connection?

-- 
Lorenzo Marcantonio
Logos Srl