kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

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