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 <[email protected]> > > 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 : [email protected] > >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>> Post to : [email protected] > >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>> Post to : [email protected] > >>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>> More help : https://help.launchpad.net/ListHelp > >> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~kicad-developers > >> Post to : [email protected] > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
