kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

I think most applications just (ab)use private frameworks for plugin
dev, aka convert the 3dsg.dylib into a framework, as the framework
will then contain the headers and it will be distributed as part of
the application bundle, and one can add the "private" framework to
their projects.


Simon

On Sat, Apr 9, 2016 at 6:28 AM, Bernhard Stegmaier
<stegmaier@xxxxxxxxxxxxx> wrote:
> Hi,
>
> to be honest, I don’t know yet how it is done best on OSX.
>
> Putting everything in $CMAKE_INSTALL_PREFIX is definitely not wrong as a first step.
> The interesting part is how to package those include/lib folders into the application bundle.
> Remember: $CMAKE_INSTALL_PREFIX is not the final place for OS X.
>
> Of course, we could just put everything (headers and libs) somewhere inside the application bundle.
> I don’t know if it is intended to be like that, since normal users normally shouldn’t have to look into the bundle.
>
> The other option I can imagine would be to separate it.
> So, there would the Kicad application dmg as now, and maybe some Kicad-Dev dmg containing everything needed to compile my own plugin (the include/lib folder I guess).
> If I want to make my own plugin, I could just put that contents anywhere I like, link my plugin against it, and put the final plugin library into the Kicad plugin folder.
>
> One IMHO problematic thing remains with both options:
> User plugins will work fine and portable as long as the link everything from Kicad itself static.
> This way the user plugin is self contained.
> If somebody wants to link dynamically against Kicad stuff, I guess it will break portability… if you move/rename/etc the Kicad application bundle then the plugin in user folder won’t work any longer without recompiling.
> As far as I can remember, the currently existing two 3d plugins link dynamically against the plugin library…
>
> Where would you put that stuff in Windows?
> Just into the application directory and user plugins just link against this C:\Program FIles\Kicad\… folder?
> Will probably cause the similar problems as with the OS X application bundle.
> At least, if plugins should be distributed in binary fashion (and not being statically linked / self contained).
>
>
> Regards,
> Bernhard
>
>> On 08 Apr 2016, at 16:09, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>> 1) Header files should be installed in
>> $CMAKE_INSTALL_PREFIX/include/kicad/plugins or possibly
>> $CMAKE_INSTALL_PREFIX/include/kicad/3d-plugins.  A some point we may
>> want to expose the APIs of the kicad libraries (kifaces) so I would
>> prefer the plugin headers be in a descriptive path for clarity.  I'm not
>> sure what the correct header install path is on OSX should be.  Any of
>> our OSX devs know where they should be installed.
>>
>> 2) The lib link files should be installed in $CMAKE_INSTALL_PREFIX/lib.
>> Again, OSX may have it's own preferred path.
>>
>> 3) There is a good example in the "Mastering CMake" book on how to
>> generate <Package>Config.cmake files.  There is an example on the CMake
>> wiki as well:
>> https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file.
>> These are built automatically when you compile the KiCad 3D plugin and
>> includes all of the necessary information for compiling and linking
>> against the plugin library.  I'm sure there are some examples on how to
>> do this out there.  The other alternative is to write a generic
>> Find<Package>.cmake file however this is not as powerful as the first
>> option.  I've never used the first option but it appears to be CMake
>> specific way to support building against custom libraries.  It's more
>> like pc-config than the typical Find<Package>.cmake stuff in that it
>> includes compiler and link flags used to build the library and other
>> useful settings.  There are also default locations where CMake will look
>> for the <Package>Config.cmake files so you will need to figure out where
>> they are and install the config files there.
>>
>> On 4/5/2016 10:17 PM, Cirilo Bernardo wrote:
>>> With the recent merge of the 3D plugin work we must now address
>>> some new issues which have come about due to the introduction
>>> of plugins and a shared library (kicad_3dsg). In particular, users
>>> who wish to create out-of-tree plugins will now need to find the vital
>>> kicad headers and necessary shared libraries (at the moment only
>>> kicad_3dsg).
>>>
>>> For the 3D plugins and kicad_3dsg all of the necessary header files
>>> have been placed in the include/plugins directory. At the moment
>>> there are no CMake instructions to install header files since I wanted
>>> some feedback on the options and their effects of in-tree source code.
>>>
>>> I think the best place to install the headers would be within
>>> ${SOME_SYSTEM_PATH}/include/kicad and subdirectories
>>> within (at the moment only plugins/ and its subdirs). We will need to
>>> provide a FindKicad.cmake file or an appropriate CMake package
>>> file to discover these headers and the associated libraries.
>>>
>>> What I am not so certain of is the expected behavior of the
>>> find script:
>>>
>>> Option1: Kicad_INCLUDE_DIR is set to:
>>> ${SOME_SYSTEM_PATH}/include/kicad
>>> This would require no changes to the kicad source since
>>> the kicad headers use the form "plugins/whatever" to include
>>> headers related to the plugin system. However, some people
>>> might argue that it's not clear that we're thinking of kicad
>>> plugins and might prefer:
>>>
>>> Option2: Kicad_INCLUDE_DIR is set to:
>>> ${SOME_SYSTEM_PATH}/include
>>> This would require the following changes to headers and
>>> directory structure:
>>> a. headers change from using #include "plugins/whatever" to
>>> #include "kicad/plugins/whatever"
>>> b. move the directory include/plugins to include/kicad/plugins
>>> -- however I'm not so comfortable having a 'kicad' directory
>>> within the main branch's "include" dir.
>>>
>>> Some thought has to go into what KiCad may be like in the
>>> future - will we have more shared libraries, will we have only
>>> plugin-related shared libs and headers or is it possible we
>>> will have others. For example if we were certain that we
>>> will only have plugin headers then we can install headers to
>>> ${SOME_SYSTEM_PATH}/include/kicad-plugins and
>>> the include/plugins directory can simply be changed to
>>> include/kicad-plugins and appropriate changes made to
>>> existing headers and in-tree code.
>>>
>>> Any comments/suggestions?
>>>
>>> PS: Some tutorial code is largely written but is awkward
>>> because of this situation where kicad does not (yet) install
>>> headers. I plan to clean it up and push to the documentation
>>> repository as soon as these last issues are addressed.
>>>
>>> - Cirilo
>>>
>>>
>>> _______________________________________________
>>> 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