kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/21/2014 09:18 AM, Lorenzo Marcantonio wrote:
> 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...)
> 


No, they are no where near the same:

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.

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.

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

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

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

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


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.