kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

On Thu, Feb 16, 2017 at 09:18:10AM -0500, Wayne Stambaugh wrote:
> 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.

As reasons for installing them in /usr/bin go, this is "I can count to
potato" levels of silly.

THAT'S NOT WHERE SHARED OBJECTS GO, typical or atypical. /usr/bin is
ONLY for executables with a valid entry point.

> 
> 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
> 
> _______________________________________________
> 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