kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Apr 21, 2014 at 08:15:29AM -0500, Dick Hollenbeck wrote:
> If you still don't believe, then try and link them together yourself.  That process is in
> itself will be more difficult than what you might think, but it could be educational.
> 
> Also remember that my vision has python at the top.

Never said a 'blob' link. That couldn't be done before heavy reworking
(if it was me I had done that before merging them, but everyone has his
own priorities)

More something like

gcc -okicad main.o -lpcbnew -leeschema -lcvpcb

with pcbnew.so etc. maybe using the same kiface mechanism. In fact, with
dlopen you are invoking by hand the same exact load mechanism done
(automatically) by ld-linux.so.2. So the shared function stays shared,
globals stays globals (that was the only thing I wasn't sure of) and so
on. Even making 'common' shared *would* make a mess (for the internal
unit difference and maybe other). I suppose these are the issues you
mentioned.

So we actually have something like:
launcher
    - wx.so
    - loader/kiface runner
        - ldopen

eeschema
    - wx.so
    - stuff for eeschema
    - static common compiled for eeschema  

pcbnew
    - wx.so
    - stuff for pcbnew
    - static common compiled for pcbnew  

With a simple shared link we would have
kicad
    - wx.so
    - eeschema
        - wx.so
        - stuff for eeschema
        - static common compiled for eeschema  
    - pcbnew
        - wx.so
        - stuff for pcbnew
        - static common compiled for pcbnew  
    
i.e. the same exact final result, without involving dlopen. I'm not
criticizing the dlopen approach I was wondering if it was necessary.

As for the interfaces nobody forbid to use the same approach you're
using, simply using pointers from the linker instead that those from
dlopen. Also, wasn't there already something ready to use with all the
component models around?

That aside, the 'strict interface' is more of a tenant of the C++/Java
programming culture, and I (personally, I'm not suggesting to do
otherwise) regard it as lacking flexibility... in my experience you
almost always hit into fat or mismatched interfaces (like the via one
I just fixed); in functional circles there are no declared interfaces
and no information hiding either, still getting static type safety and
no duck typing. But OO is not message passing based either, so at the
end probably the interface is the best way to design for C++:P (OTOH the
CLOS multiple dispatch is *horribly* slow, and UI work is done only on
Java/C++, so...)

-- 
Lorenzo Marcantonio
Logos Srl