We have our application developed in Qt 5.4 which is shipped as an SDK (dylib) for integration with other applications. All the dependent libs are shipped along with the SDK(Qt 5.4.x binaries).
However we bumped into an issue when the customer tried to integrate our SDK in his application. That application is making use of a component which has a Qt 5.3.x dependency. Our SDK has not worked with the application. The issue is due to the fact the "libqcocoa" in platforms is shared, which is leading to a crash.
Can an application be able to load two different Qt binaries(with/without namespace) ? If yes, how this can safely taken care ? (application is in Mac)
I also need to address the point that, the components which are using different Qt versions can be updated independently. What are the best practices generally followed ? Please suggest.
Your use of Qt is usually an implementation detail. Hide it by using private frameworks or linking Qt statically.
Alternatively, if you need to interoperate with the user's Qt, add a small open-source interface that forwards relevant Qt APIs to your code. You'll be surprised at how little Qt most code uses. The interface is likely going to be a couple thousand lines at most and you can machine-generate it.
Related
I'm working on a C++ Linux application that uses wxWidgets, and needs to be distributed as a compiled binary application. The project lead has specified that we are to include all dependencies for the application so that the end user does not need to install anything to run the application, provided they have standard system components installed already (libc, etc). I think this requirement is something that the end user asked for. I know that this is not what you might consider to be a "normal" distribution process for Linux applications.
For simple libraries that don't have many dependencies themselves, this is not an issue. But for wxWidgets I'm running into issues with webkitgtk which is required for the WebView class (which is used in the application). webkitgtk has a number of dependencies itself, which may have their own dependencies, and so on. Basically, it looks like I'd be opening a real can of worms by trying to include everything in the application, and the more senior developer on the project seems to agree.
So I'm wondering, what are my options for distributing such an application? I've tried searching for information about this, and the prevailing opinion seems to be to have the end user install wxWidgets. These are the options that I've come across:
Compile all dependencies as shared libraries as the project lead wants. The downside to this is that there are many libraries to worry about and this will lead to significant bloat.
Require that the end user install wxWidgets (on top of GTK and webkitgtk). The downside here is that the user would have to install multiple dependencies, and if they aren't on a distribution with appropriate versions of the above in their package manager, this could be a real hassle for them. It also means we couldn't provide something that was specifically asked for.
Require that the end user have GTK and webkitgtk installed, but not wxWidgets. Same downsides as above, but with fewer dependencies. An additional downside is that there may be version compatibility issues if different versions of the dependencies are installed than were used to build the packaged wxWidgets library.
Am I correct in my assessment of the pros and cons of these various options? Are there any options that I'm missing?
Thanks!
David,
The best possible solution is probably to ask user to install X11, GTK+{2,3} and WebKit-GTK.
wxWidgets can be statically linked with the application.
You can ask you user to have a WebKit-GTK to be at least version X.Y.Z and that should satisfy the requirements. Integrating WebKit-GTK with all its dependencies, especially since there is a dependency on GTK+ itself will be very hard. So if you go this route you will be screwed.
As linux user i vote for manual dependencies installation via package manager. It's not that hard and could even be done automatically if you provide package (Not just binary). Carrying runtime may cause problems (E.g. Steam on Debian). Another option is to provide two flavors: all inclusive and dependency requiring.
I have written a portable C++ application using Qt libraries. This means that I cannot use the MT flag for compiling without risking memory issues.
This leaves me with two options:
1) Deploy the portable application with an installer.
2) Package the C++ dependencies within the same folder or use private assemblies.
Both 1 and 2 defeat the idea of portable software, so I was thinking of a third option:
3) Use IExpress to drop the C++ dependencies before launching the application. On exit, delete the C++ dependencies.
Unfortunately, option 3 has received some flak from some stackoverflow members. They even dislike option 2 which leaves me with only option 1. I can see option 1 as doable if I use a portable installer.
Is there such thing as a portable installer? Essentially, I want the installer to check to see if the needed dependencies are installed before running my application (just like a regular installer would) and if they are, then just continue running my application. Otherwise, give a message box to the user that they could download it providing a link to the URL. I am aware I can write my own installer that can do this in C++ but I was wondering if there are any installers that already offer this specific functionality.
http://qt-project.org/doc/qt-4.8/deployment.html
The dlls for Qt in windows are so small, that deploying them with the application isn't an issue in my opinion.
There aren't any programs out there that I know of that place the Qt dlls on windows in some place that another program later would find (like c:/Windows/system32).
I think the only place where you could expect reuse of the libraries is in Linux or a mobile device that has a lot of Qt apps. But even then you have make sure that the versions of the libraries are high enough to support all the functionality that you are using.
Hope that helps.
I have a project of which I want to develop (and build/release to internal nuget) on Windows. There are multiple versions of my assembly (NET40, NET20, etc) that are created as part of my build process.
I have a new project that wishes to use my libraries on Mono and MonoTouch. Is it possible to build libraries on Windows that are ready to run on MonoTouch/MAC? Note that I do not wish to program against any MonoTouch.dll or Apple/iOS specific libraries. My assemblies are strictly .NET libraries.
Is changing my target framework to .NET 4.0 "Client Profile" sufficient to get support on Mono platforms (including MonoTouch/iOS)?
You can use portable class library's to do this. there is a great article on how to get this set up.
It is quite easy to get set up thanks to the great write up by #slodge on twitter.
I've always been developing simple(console) apps. And even then most problems I had was with starting/porting/CMaking/ libraries to work.
I need to find a gui which is added/used by adding #include "somelibrary.h" to EXISTING c++ project. I've downloaded QT, but it seems I have to create a new QTproject,... and thought alone of including all CUDA,OpenCV,others is making me sick.
I've been experimenting with windows forms (.net?) but there is this managed/unmanaged border with its creepy bugs.
So I'd like to add GUI to existing project (where forms can be designed in completely separate designer).
Do you know any?
Or maybe You'd suggest me different approach?
I suggest you to use CMake and Qt. CMake is better than qmake to manage projects and use additional libraries. Currently Qt is the best multi-platform GUI API.
QT and winforms can be added on to an existing project but it's harder that taking a gui application and adding your project to it. Event driven code is organized differently than procedural code.
You don't need CUDA or OpenCV for a GUI.
I'm going to create a utility with GUI that will run on Windows operating systems.
It should require minimum (or zero!) amount of additional libraries, files or DLLs to run because it will be executed from an installer. Because of this, i don't want to use .NET for it will require user to install .NET Framework. I know today, most of Windows installed system come with .NET Framework but in my case i cannot be sure.
The utility will...
send some data to a web site and
parse the returning data,
collect some hardware info, like MAC address,
CPU type and make, hard-disk serial
number
I suppose native Win32 API could be used for all of those above, but instead of hassling with Win32, i'd prefer using a more developer friendly API, or SDK.
Thanks in advance.
Win32 API is the only way, and of course there are standard API - for sending data over the internet, you could use WinInet.lib/dll, to obtain information about the MAC, you could use the GetAdaptersInfo by using Iphlpapi.lib/dll,(here's a link on how to use it) for the Hard disk serial number you could use GetVolumeInformation by using kernel32.lib/dll. For the CPU Id, you might look into GetSystemInfomation
Edit: There's a C++ code, but you can easily derive a wrapper from this site Unfortunately, with WinAPI is not easy, no such thing as RAD with WinAPI but what you gain out of it is lightweight code instead of relying on SDK's, frameworks and dragging buggy dll's around with your application.
Hope this helps,
Best regards,
Tom.
You can statically link most C++ GUI libraries - even MFC. Personally, I recommend WTL, wihich is very light and header-only.
If what you want is minimum dependency with external files or DLLs you could statically compile all the required DLLs with the tool exe. Then you could use something like Visual C++ to develop such tool.
WTL is perfect for this sort of application and I am surprised more people aren't recommending it. You can also statically link with the CRT and hey presto - no dependencies and a very small EXE.
Delphi (now by Embarcadero) would do the job, creating a .exe file with no dependencies, and it is much easier to work with than the raw Win32 API.
If you don't like Object Pascal, you could try C++ Builder instead.
For the GUI you can either build your application with MFC (statically linked) or use a HTML based dialog that you can interact with using COM. (It is even possible to interact with javascript present in the page displayed by the dialog).
For the specific requirement that you do have, I feel Win32 API is the only way out.
Use MFC and statically link to it. No runtime dependancies need to be installed.