kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I had to relearn what I forgot about why the kifaces are installed along
side the executables.  The reason is kiface is short for KICad interFACE
files.  They are the face of KiCad and are program files that happen to
be in a form that is loadable from start up.  The allows kicad to
operate in both the integrated and stand alone modes without linking the
interFACE part in both modes.  The kiface changes frequently and is not
a great candidate for a typical shared object.

The original goal was to split libcommon (and possibly more granular
libpcbcommon and libschcommon) to actual shared objects in the
traditional fashion because this code does not change frequently like
the interFACE part of kiface does.  I don't know if the libcommon
objects are sufficiently decoupled from the kiface objects yet to build
a libcommon shared object.  If they are, I would be more than happy
accommodate that patch.  For now, I would prefer to keep things the way
they are in the vein of "if it ain't broke don't fix it".

Cheers,

Wayne

On 2/13/2017 4:54 PM, Cirilo Bernardo wrote:
> If my memory's not too bad, these objects are loaded using hard-coded paths.
> They are not objects which are automatically resolved and loaded by the
> linker-loader. This makes any versioning trivial - so long as we *do*
> provide some
> version numbers so that the files have different names, kicad can still load the
> correct blobs. The closest example of related code in kicad would be the 3D
> plugins - in that case the plugin loader searches a number of given paths and
> loads whatever files it can. In the case of the kiface blobs we can
> have a similar
> flow of searching paths, though the actual file names of the blobs to be loaded
> may be set at compile time. Actually, the 3D plugin system does require an
> auto-loaded library; that library does not currently have a version number in
> its name although internally there are in fact version checks.
> 
> - Cirilo
> 
> 
> On Tue, Feb 14, 2017 at 1:45 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
>> rpath? Load by absolute path based on compile prefix? Relative
>> (../lib/foo based on the current exe path)? Seems to me standard library
>> versioning isn't the right way to handle this anyway, since these aren't
>> *libraries* per se but just object bundles.
>>
>> On Mon, Feb 13, 2017 at 09:35:59AM -0500, Wayne Stambaugh wrote:
>>> When multiple versions of kicad are installed in different install
>>> paths, library versioning has to be correct or it's possible that the
>>> wrong kiface gets linked.  I'm thinking more of users or developers who
>>> build and install from source rather than packaged installs.  On linux,
>>> I could install the stable version of kicad in /usr and my dev build in
>>> /usr/local or /home.  If _pcbnew.so (kiface) exists in multiple ldconfig
>>> paths with no or identical version information, how does ld know which
>>> _pcbnew.so to use?
>>>
>>> On 2/13/2017 9:30 AM, Chris Pavlina wrote:
>>>> Can you explain why you think installing them as .so to /usr/lib changes
>>>> in any way our responsibility for library versioning vs installing them
>>>> as .kiface to /usr/bin? They still get installed with the whole package,
>>>> reinstalled on upgrade, uninstalled on package removal, etc...
>>>>
>>>> On Mon, Feb 13, 2017 at 09:21:26AM -0500, Wayne Stambaugh wrote:
>>>>> I'm not opposed to this but once we head down this path, we will forever
>>>>> be responsible for library versioning and any implications it has with
>>>>> regard to multiple installed versions of kicad.  I'm not sure we are
>>>>> ready to open that can of worms just yet.  Keep in mind that .kifaces
>>>>> are not generic libraries, they can only be linked to a specific kicad
>>>>> app.  Link to the wrong .kiface and your sure to have issues.
>>>>>
>>>>> On 2/12/2017 2:01 PM, Chris Pavlina wrote:
>>>>>> Please!!:
>>>>>>
>>>>>> - Move .kiface into $PREFIX/lib on linux, and the equivalent place on
>>>>>>   other systems
>>>>>>
>>>>>> - Rename them from _foo.kiface to foo.so on linux and osx and foo.dll on
>>>>>>   windows
>>>>>>
>>>>>> - Stop installing them with the executable bit set on linux! Presumably
>>>>>>   osx too. It's totally unnecessary for shared libs, and ESPECIALLY bad
>>>>>>   if they're in $PREFIX/bin.
>>>>>>
>>>>>> On Mon, Feb 13, 2017 at 07:49:36AM +1300, Simon Wells wrote:
>>>>>>> As the kifaces are just shared objects/libraries is there any reason
>>>>>>> they must be named .kiface instead of .so (or other name used on
>>>>>>> system for dynamic libs), It seems to just be making things more
>>>>>>> difficult and confusing when people see .kiface and have no ideaa what
>>>>>>> it means.
>>>>>>>
>>>>>>> These should really not be place in bin/ on linux systems either as
>>>>>>> its really not designed for that sort of thing
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp