I have two applications and a static library used by both.
All three using CMake as build system.
I want to localize my applications.
I more or less understand how to localize applications but I'm not
sure how I should localize my static library.
If it would be a dynamic library I could install the compiled
translations alongside with the binary and access them.
But a static library is only relevant for the developer. There is no longer a
library in the final product. I would somehow need to transfer the compiled
translations of the library to the applications.
When calling make install for one of my applications the translatons of my
static library needs to be installed, too.
How can I achieve something like this using CMake?
Related
I am developing a static library, which is added to my main project that tests the static library's functions. The static library inside is using some 3rd party components, and this third party components needs to add some additional libraries (e.g.: libz.dylib, SystemConfiguration.Framework). It's fine, but when I try to build my main project that contains my static library, I got bunch of linker errors. I figured out, if I add the same frameworks and libraries to the main projects what I needed to add to my static library, the linker errors disappear and the project is built succesfully. The question is do I really need to add all of those resources to the main Project? I find it crazy that if I give my static library to someone else to use, I need to include a bunch of frameworks and libraries in the documentation that has to be added also in the integrator project? Or am I missing something important?
It's because a static library is not linked, unlike an executable or dynamic library.
A static library is just an archive of object files, and object files contain external references to symbols they use. Those references are not resolved until the executable/dynamic library is linked.
Therefore when you link-in a static library you are responsible for providing any dependant libraries to the linker, which can themselves be either static or dynamic.
With the use of a mild hack, it is possible to make static frameworks for iOS. Static frameworks are quite convenient to use: they can simply be dropped into new projects without extra steps (like adding them to the build and adding header search paths).
I've recently started doing OS X programming, and the first thing I noticed was that static frameworks don't seem to be available. Dynamic frameworks are obviously available and recommended, but as I want to make a little private framework intended for application use (not installation in /Library/Frameworks), using a dynamic framework in new application projects still requires a bunch of extra steps.
In my ideal world, I'd create a static framework (a framework which contains header files and a compiled .a file), drag & drop the framework onto a new project, and start coding. Is there any way to make such a static framework on OS X?
P.S. I already tried setting the Mach-O output type to "static library" in a normal framework project, but I just get the error Framework target has invalid MACH_O_TYPE value of 'staticlib'..
You can create a dynamic framework on Mac OS X. In your dynamic framework you can set the LD_DYLIB_INSTALL_NAME as #rpath/Foo.framework/Versions/A/Foo
If you have an app that wants to link with this framework then you make sure you run the
install_name_tool -add_rpath <rpath> <full-path-to-app-binary>
So if I had Foo.app
install_name_tool -add_rpath Foo.app/Contents/Library Foo.app/Contents/MacOS/Foo
Now if you just copy your Foo.framework into Contents/Library it should get loaded and everything should work.
I hope this helps.
Probably simpler would be to use a static library with public headers. When you build the static lib you can have Xcode copy the headers for you automatically. And in your target you can add the folder to your search path.
If you use a static library Xcode will strip away some dead code that your app doesn't really need but is compiled into the static lib.
Static frameworks aren't really supported on OS X. They're fairly brittle anyway, and solve a specific problem that exists on iOS but not on OS X.
If you're looking to make it easy for developers to use a library you create, you have a couple options:
Use Cocoapods. They have a tutorial for publishing your library on CocoaPods. This is probably the easiest way to distribute a library on OS X.
Package your library as a framework. If you set the install name correctly (to #rpath/<library name>), the downstream developer merely needs to copy the framework into their Xcode project and set the runtime search path of their application to #executable_path/../Frameworks).
I have a need to create a static library which will some of it's own code and it will also contain a number of other static libraries I have written.
So normally I have a main project A.xcodeproj which depends on B.xcodeproj which in turn depends on C, D, E etc.
My company has a requirement to distribute only a static library with a simple app, and for there to only be one library sent out, not a multitude of libC.a libD.a etc.
So I create A_static.xcodeproj which has simple application API calls and links to libB.a but everytime I try this libB.a only contains the symbols for B.xcodeproj, I can not get to it also contain libC.a libD.a etc.
Is there an easy way to do this in XCode that I'm missing?
Thanks
It sounds very much like you need to use frameworks. Allows you to bundle multiple libraries and files together into 1 bundle that other parties can include. I'm in the same boat where I work. I've used this guide on github to get our frameworks up and running. Worked great for me.
iOS Framework
There are appear to be methods of creating a fat static library ala "http://stackoverflow.com/questions/3520977/build-fat-static-library-device-simulator-using-xcode-and-sdk-4". Is this recommended? Any special steps (i.e., disabling thumb)
Also, if I do use the fat static library, will monotouch/xcode clear out any unused code in the final product?
You definitely need to turn Thumb code off so you can link properly against the library. As far as creating the fat static library goes, I can only say that anecdotally I've done this for a few third-party libraries that I've used and haven't run into issues.
I assume you already know that you need to create the bindings necessary to make calls to the objective-c library from your MonoTouch code and add extra gcc flags in the project properties to link in the static lib. If not, you can get that information on how to do that from the MonoTouch website.
I have an existing project created using C/C++ under a development environment.
Currently we want to facelift the existing form using a Window Forms application but the problem is the existing project is using Common Runtime Library = No /CLR and Runtime Library = /MTd.
But the a Windows Forms application is using Common Runtime Library = /CLR and Runtime Library = /MDd.
Please advise if it possible to use a Windows Forms application to create a form in the existing project?
Is there any tutorial regarding this?
The comment from MSDN was:-
Caution Do not mix static and
dynamic versions of the run-time
libraries. Having more than one copy
of the run-time libraries in a process
can cause problems, because static
data in one copy is not shared with
the other copy. The linker prevents
you from linking with both static and
dynamic versions within one .exe file,
but you can still end up with two (or
more) copies of the run-time
libraries. For example, a dynamic-link
library linked with the static
(non-DLL) versions of the run-time
libraries can cause problems when used
with an .exe file that was linked with
the dynamic (DLL) version of the
run-time libraries. (You should also
avoid mixing the debug and non-debug
versions of the libraries in one
process.)
http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.71).aspx..
The simple answer is no. A more accurate answer is kind of, but you probably wouldn't want to.
It is possible to use Windows Forms (i.e. managed code) for your user interface and something else (e.g. non .NET/unmanaged code) for your domain logic. However I'd guess that if you're asking this question then that is going to be a bit much for you to do at the moment.
I suggest that you create a user interface with Windows Forms and then have that user interface call a native C/C++ DLL. Google for PInvoke on how to call an unmanaged dll (C/C++) from managed (.NET) code.
If you did that then you would be much better positioned to answer this question.
My company software often has to have modules which mix managed and unmanaged code and user interfaces. What we do is to separate the modules into their own executables and expose the functionality as COM localserver objects. This way, the unmanaged code can have a user interface written in managed code.
However, you need to do alot of plumbing to get it to work. We do it this way because our applications have been deployed in the field for years and it will take years to give the entire program a makeover into .NET