I understand that plug-ins are components that are tasked with a specific function and loaded for use by an application.
Shared object libraries (.so) in linux and .dlls in windows are libraries that are loaded at run-time by an application.
I want to understand what if .dll / .so are always plug-ins. Are all plug-ins .dll / .sos?
Actually, .dll's and .so's are dynamic libraries. There are also other type libraries named static libraries. In Linux, their extension is .a.
Programmers tend to use libraries for maintaining their code easily. Also, if the library will be shared more than one application, shared library is chosen because of main memory usage.
You can apply this logic for a structure which contains plug-ins. If the code piece will be used only by your application's single process, you can use static library as your plug-in. However, if the code will be shared by multiple processes, you should use shared libraries, even if these process are instances of the same application.
When you use shared libraries as plug-ins, you must not include library as known methods and you must not link your executable directly to the library. Instead you must use libdl. Have a look at here and look for the dynamic loading.
Related
I have program that is reading and writing mat files using the Matlab API.
Therefore my only dependency ist on libmat.dll
Can i ship libmat.dll only (instead of requiring ~600mb MCR) or is that prohibited by a license?
As long as you write MAT files out your code, you can...
Here are the terms from Matlab's license.txt (located in Matlab installation folder) under which you can deploy and share your libmat.dll linked application.
Excerpt from "Deployment Addendum" license section:
OTHER SOURCE CODE AND SHARED OBJECT CODE LIBRARIES.
6.1. Programs may include selected Source Code and shared Object Code
library files that implement various documented application
programming interface capabilities of the Programs for which the
Source Code or shared library file is part.
6.1.1. Licensed User may use and modify the selected Source Code files
solely for creation of Licensee's own Applications. Licensee may
copy and distribute Object Code compiled from this Source Code,
but only as either standalone Object Code file (regardless
whether a Derivative Form) or Object Code Linked to the
Application, and only for use with and deployment of Licensee's
own Application.
6.1.2. Licensee may use, copy and distribute shared Object Code library
files (regardless whether a Derivative Form) for deployment of
Licensee's own Application, but only if a header file exists in
the Program for the shared library file. Licensee may not copy or
distribute header files themselves.
6.1.3. Licensee may not transfer Source Code, development rights, or
development capabilities for any Source Code or Object Code to
any Third Party.
6.2. MAT-files. Licensed User may create and distribute Applications that
read MAT-files using the MAT-file API, however, if such Applications
are distributed to Third Parties, they must also implement MAT-file
write capability.
Be aware that libmat.dll has its own further MATLAB library dependencies - so you'll need to ship also other Matlab DLLs in order to use libmat.dll.
Considering that I am developing an end-user software program (as an uberjar) I am wondering what my options are to make it possible for the user to download a plugin and load that during runtime.
The plugin(s) should come compiled and without source code, so sth. like load is not an option.
What existing libraries (or ways of Java...?) exist to build this on?
EDIT: If you are not sure I would also be satisfied with a way that costs a reboot/-start of the main-program. However, what is important is that the source-code won't be included in any JAR file (neither main application nor plugin-jars, see :omit-source of Leiningen documentation).
To add a jar during runtime, use pomegranate which lets you add a .jar file to the classpath. Plugins of your software should be regular Clojure libs that follow certain conventions that you need to establish:
Make them provide (e. g. in an edn) a symbol to an object implementing a constructor/destructor mechanism such as the Lifecycle protocol in Stuart Sierras component library. In runtime, require and resolve that symbol, start the resulting object and hand it over to rest your programs plugin coordination facilities.
Provide a public API in your program that allows the plugins to interact with it in ways that you coordinate asynchronously e. g. with clojure.core.async (don't let one plugin block the entire program).
Make sure that the plugins have a coordinated way to expose their functionality to each other only if they desire so to enable a high degree of modularity among your plugins. Make sure that your plugin loader is capable of detecting dependencies among plugins and is capable of loading and unloading them in the right order.
I've not tried it myself, but you should in theory be able to get OSGi to work with Clojure.
There's a Clojure / OSGi integration library here:
https://github.com/aav/clojure.osgi
If I were to attempt to role my own solution, I would try using tools.namespace to load and unload plugins. I'm not entirely sure it will work, but it's certainly in the right direction. I think one key piece is that the plugin jars will have to be "installed" in a location that's already on the classpath.
Again, this is only the start of one possible solution. I haven't tried doing this.
Has anyone had any success in finding a reliable, generalised solution for managing dependencies for iPhone projects? I'm looking to split my iPhone applications up into reusable components and then pull them into projects that require them. I guess I'm looking for a Maven-esque workflow but for Xcode/iPhone projects. I've tried a number of things so far such as:
I've created a Maven plugin for iPhone applications which automates the building and signing of the applications but I constantly feel like I'm fighting against Maven to get this to work and it is altogether pretty messy. I'd rather not use this unless there are no other options.
I have also tried using static libraries to package the code up to re use but the problem with this is that I'd also like to include reusable XIBs and images in my projects and these cannot be included in the static library for redistribution. They are great for code but I'd like to have one system that does everything rather than different dependency management systems for different types of dependency.
At the moment I've settled on using the version control system to do my dependencies for me. In this case I'm using SVN externals to load the dependencies into the workspace when I checkout the project.
Does anyone have any ideas as to what I could do?
Update
I'm now using CocoaPods to perform this task.
The way I've done it in the past is as follows:
Static Library for shared code
Bundle for Images / Data Files / Etc (Non Code)
By doing this, you only ever have to worry about updating the project that manages your static library / bundle and not the applications that use them.
The key thing to creating a bundle, is that Bundles are not listed under iOS when adding a new target to a project. Instead they are listed under Mac OS X. Don't worry, it works great.
Once you've created your Bundle and Static Library targets, you'll need to get those into your application:
Add the Static Library under Link Binary With Libraries (Xcode 4)
Add the Bundle under Copy Bundle Resources (Xcode 4)
The final thing to keep in mind is that when you want to load resources from the newly created bundle you need to do something like the following if you were going to load an image:
UIImage *myImage = [UIImage imageNamed:#"YourBundle.bundle/MyImage.png"];
With Static Libraries, you can distribute the XIB's/Images/Strings in a Bundle Folder which can be imported easily. It is the easiest approach I've found for distributing dependencies short of distributing the actual Code/Xcode Project
Each C/C++ library has some amount of headers that should be used with that library. And if you're use more than 1-2 libraries, custom header paths is kind of headache.
So I thought: is there a way to compile C libraries as frameworks. Static library + headers + versioning.
I found in XCode template for Cocoa framework but nothing about iPhone framework building. This simple step could allow developers to build and share between each other frameworks with some interesting code.
Also it would be great to use libpng, libjpeg and other libraries packaged as frameworks.
I won't use dynamic libraries in those frameworks. Only static version will be present.
I combined techniques I found here and here into my open source library here (NOTE - I have since removed the relevant scripts from this project. I have updated the link to point to the last revision that included these techniques.). Think that's basically the solution you're looking for.
Basically, it has a target that will build a fat static library (lipo builds for arm6, arm7 and i386). It has another target that takes that library and builds it into a framework.
There's no reason you can't use the same techniques for a C project. In fact I've started work on porting C the VTD XML parser to an Objective C framework using the same techniques.
Frameworks are basically just bundles of dynamic/shared libraries. Since this is not allowed in the App Store, you have to build static libraries and link them with your App's executable at compile time.
However, to ease the pain a little, you can have a Xcode project for each library and compile each library into a static lib. Another way would be to put all required source files into the main Xcode project and configure it appropriately so it all builds at once (I did this with small libraries like Minizip, for instance).
Hope that helps.
the problem you are trying to make already exists - it's called DLL hell
Best way is to stick with plain old static libraries when making small apps and organizing source/headers structure
I have created a static library in XCode that requires several dynamic libraries (e.g. libsqlite3.0.dylib). I can create an application that is dependent upon my static library using cross-project references in XCode, but it seems that I have to manually add all of the required dynamic libraries to each of my application projects to get them to link.
Is there any way to configure a static library project in XCode so that dependent applications will automatically link against whatever dynamic libraries it requires?
I tried adding the dynamic libraries to the list of Frameworks in my static library project, but this seemed to have no effect.
Yes -- you will need to add the libraries to the applications. A static library -- a .a -- is just an archive of .o files with a minimal bit of internal symbol resolution. The full symbol resolution doesn't happen until you link it into an application (or framework).
(Are you using sqlite3 directly? If so, why not use Core Data? There are reasons, but not nearly as often as people thing...)