If you have an application which relies on another app being installed, you ideally want your installer to find that dependency path automatically. On Windows you can use the registry but what about Mac/Linux? In this particular case it's a C++ application, if that makes a difference.
If you try to distribute your application through any of the common package managers on Linux (apt, yum) you can add the application as a dependency.
If you down the route of custom install scripts you need to resort to some kind of hackery. Either find out which package manager is in use on the system and try to query with it (which can fail, if the other application was installed without the package manager) or try something like which required_app.
Go for the first, if you want to do it right.
In Mac OS X, if you're looking for an application that's bundled in a typical .app bundle, you can use Spotlight to find it from its bundle ID using the command line utility mdfind(1). For example, to find out if Firefox is installed (and where), run this command:
mdfind 'kMDItemCFBundleIdentifier == org.mozilla.firefox'
Generally, on UNIX systems you can expect all programs to reside in $PATH instead of being distributed in a hodge-podge collection of stupidly named and partially localized directories. So, essentially you don't need to find any dependency path - you just call the other "app" (program) via execvp, and the libc takes care of walking through the entries of $PATH and finding the executable.
In the classic UNIX model, you don't check anything in an installer, but just check at runtime whether an executable is available (with which, for example) or not.
The equivalent of a Windows Installer is the Linux Package Manager. The Package Manager handles dependencies and installs it (if it is not already present on the system). The dependency information for an application is stored within the package file. Each distribution has its own Package Manager, though the concept is the same.
There are plenty of resources online for specifics about a Package Manager. However, if you would like to get an overview in comparison with a Windows Installer, check out application management in GNU/Linux for Windows users.
Related
I'm creating a Qt gui application using a library which searches the PATH environment variable for certain executables, namely compilers, make and cmake.
The problem is that std::getenv("PATH") returns something different in the gui and certain executables are missed. I've tried to use the QProcessEnvironment class to the set the PATH, however, the same problem arises. I can set it to specific paths in my machine but it would be great if it could get the PATH of any machine the application is deployed to.
Strangely if I start the gui using the command-line, everything works out fine! Although I find it unreasonable to ask users to open the gui using the command line.
Any help would be greatly appreciated.
This problem has nothing to do with Qt. You've set the PATH using shell initialization scripts and such, in your own user folder. It'd be a terribly bad idea for the graphical shell to use that path, as a mistake in your shell profile would potentially make the entire desktop non-functional. Of course it works from the command line, since your shell profiles take effect then.
You could, as a user configuration option, extract the shell PATH by running the equivalent of user's $SHELL -c 'echo $PATH', and processing the result.
Otherwise, you'll have to defer to what's customary on the platform, and consult package managers if needed. Different package systems tend to install these tools in different directories, but there is just a few common ones. I presume it'd be enough to cover Ubuntu, RedHat, macports and homebrew, and make sure that you check in "pure" FHS (Filesystem Hierarchy Standard) locations as well.
How do I deal with this situation where the user's machine may not have dll like msvcp100.dll, msvcp100.dll? I don't want to my software not install on user's machine because this kind of error. I've been thinking in either find a tool and copy every single needed dll to the executable file run or try build a static version of Qt (may have sort of same result, in the end). I've seen applications that doesn't provide those dlls and it's up to user to get them, install etc. It may be a issue for those users, finding the right dll matching version and all. I'd like to avoid it.
How is this usually solved in a real world application?
You redistribute them in your installer.
Deployment of Qt apps is an uneasy issue. One should understand that you need to redistribute a compiler's dlls, as well as Qt dlls. For the msvc 2010 compiler you may just put the msvcp100.dll and msvcr100.dll files near your executable file.
As for Qt, the easiest way for windows deployment is to use the windeployqt command prompt util.
Update. How is this usually solved in real applications?
There is no fully automatic tools, which could determine all the dependencies, because the deployment of applications is a complex task. For example, you application can depend on many things such as libraries dlls, compiler's dlls, registry keys, drivers, environment variables, computer reboot requirement, ActiveX/COM components, other installed applications, etc...
But there are tools that can help you in this matter. They can be configured once for target project and then work all the time. This is called Build Automation, another similar concept is a Continuous Integration. As for the creation installation packages for end users, there is a lot of tools such as Nullsoft Scriptable Install System, Inno Setup, Qt Installer Framework, WiX, etc...List of installation software.
the installer script, put a command to download the dll that the application needs to run, and in the application source code, put it to use the dll's ONLY in the folder where it is running
If you are using the NSI installer, use this example
I developed a Qt application in MacBook (El-Capitan 10.11.2) and it is ready now to be released.
What i want now, is to create the standalone executable file for both Mac and Windows OS.
But I don't know how !
I found this link but I am unable to follow it is guidance, it looks different from what my system is showing me.
If you have any idea, please help me.
Thank you
Well, to compile an application for windows, you will need a windows machine (or at least a virtual machine). You can't compile for windows on mac.
Regarding the "standalone": The easy way is to deploy your application together with all the required dlls/frameworks and ship them as one "package". To to this, there are the tools windeployqt and macdeployqt. However, those will not be "single file" applications, but rather a collection of files.
If you want to have one single file, you will have to build Qt statically! You can to this, but you will have to do it on your own. And if you do, please notice that the LGPL-license (the one for the free version of Qt) requires you to make the source-code of your program public! That's not the case if you just link to the dynamic libraries.
EDIT:
Deployment
Deployment can be really hard, because you have to do it differently for each platform. Most times you will have 3 steps
Dependency resolving: In this step, you collect all the exectuables/lirabries/translations/... your application requires and collect them somewhere they can find each other. For windows and mac, this can be done using the tools I mentioned above.
Installation: Here you will have to create some kind of "installer". The easiest way is to create a zip-file that contains everyhing you need. But if you want to have a "nice" installation, you will have to create proper "installers" for each platform. (One of many possibilities is the Qt Installer Framework. Best thing about it: It's cross platform.)
Distribution: Distribution is how to get your program to the user. On Mac, you will have the App-Store, for windows you don't. Best way is to provide the download on a website created for this (like sourceforge, github, ...)
I can help you with the first step, but for the second step you will have to research the possibilities and decide for a way to do it.
Dependencies
Resolving the dependencies can be done by either building Qt statically (this way you will have only one single file, but gain additional work because you will have to compile Qt) or using the dynamic build. For the dynamic build, Qt will help you to resolve the dependencies:
macdeployqt is rather easy to use. Compile your app in release mode and call <qt_install_dir>/bin/macdeployqt <path_to_your_bundle>/<bundle>.app. After thats done, all Qt libraries are stored inside the <bundle>.app folder.
For windeployqt is basically the same: <qt_install_dir>\bin\windeployqt --release <path_to_your_build>\<application>.exe. All dependencies will be inside the build folder. (Hint: copy the <application>.exe in an empty directoy and run windeployqt on that path instead. This way you get rid of all the build-files).
Regarding the static build: Just google it, you will find hundreds of explanations for any platform. But unless you have no other choice but to use one single file (for whatever reason) it would recommend you to use dynamic builds. And regarding the user experience: On mac, they won't notice a difference, since in both cases everything will be hidden inside the app bundle. On windows, it's normal to have multiple files, so no one will bother. (And if you create an installer for windows, just make sure to add a desktop shortcut. This way the user will to have "a single file" to click.)
I am currently working on a Windows desktop application that uses JNI to call methods located inside a jar file.
I need to know the best way to package my application so that it can link to jvm.dll. I am not sure if I should package all the binaries found inside the JDK's bin directory into my setup file (not sure if I am allowed to do so)?
The problem is all examples found online links directly the jvm.dll found in the JDK installation path. And since my application is a commercial one, I cannot rely or ask that every user should install the JDK along side my app because that would be ridiculous.
Please can someone clarify the best method to package such application?
Regards
jvm.dll is also installed with the normal java runtime (bin/client subdirectory). By checking some registry values, you can find the path to it, load it from there and check whether the correct version is installed. If you have already linked jvm.lib, you'll then need to add jvm.dll to the list of delay loaded dlls, so you can load it at runtime.
See my recent answer to another question for details:
https://stackoverflow.com/a/14434203/93652
Can a Windows Installer perform logic like a normal application?
For example: I am creating an installer that installs plugin files to a 3rd Party Application's directory on the C drive. But the destination directory will be different if the user has an old version of the 3rd Party Application.
So the installer needs to determine what version of the 3rd Party Application is on the C drive. If its the new version I install the plugin files to C://Program Files//3rdPartyApplication// and if its the old I install to C://3rdPartyApplication//
So can a windows installer perform logic and if not can it run batch files that can do this?
An "installer" is just a regular application designed to unpack its contents onto a persons hard drive, and possibly perform actions like registry modifications.
If you use a installer like install shield for example you will have to look at that installer documentation to see what it can do. Most installer applications have some sort of area to create custom scripts.
You could also build your own, it is really not very hard.
Yes, installer can perform logic just like regular application. From this point of view, an installer is a regular application.
How you program installer logic depends on which installer suite you use. For detecting whether an application exists in C:\Program Files\3rdPartyApplication or in C:\3rdPartyApplication, you can use FileSearch element of WiX Toolset, look through Windows Installer documentation: Searching for Existing Applications, Files, Registry Entries or .ini File Entries.
More sophisticated logic can be implemented by custom actions. [Custom Actions}(http://msdn.microsoft.com/en-us/library/aa368066.aspx) can be written in JScript, VBScript, C/C++ (DLL or EXE; yet the EXE can't communicate to the Windows Installer session).
I'd like to give a different perspective. Windows Installer is a declarative domain specific programming language. It is not a Turing complete general purpose programming language. It is not intended to be just like any other application. It can be extended with custom actions written in general purpose programming languages such as C++/C# but it should stil follow the same declarative approach where you seperate the "how" to do something from the "what" to do.
Now to answer the second part of your question. Windows Installer has built in searching capabilities. Read the MSDN topics on the AppSearch standard action and related tables (AppSearch, Signature, DrLocator, CompLocator, RegLocator ) You can also put conditions on components and you can set directory destinations dynamically so yes, there are ways of doing what you want to do.
It would require much more information to explain exactly how to do it.
Yes, Windows Installer can perform logic like a normal application.
You can use the WiX Toolset, as suggested by Alexey to get the job done.
You can use the FileSearch element ( http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) to check for the existence of files or the RegistrySearch element ( http://wix.sourceforge.net/manual-wix2/wix_xsd_registrysearch.htm) in case you want to check using a registry key.
Alternatively, if the search isn't as simple as checking for a file or a registry, a Custom Action would let you write managed or unmanaged code (according to your preference) to check which version of the 3rd party application is installed.
On the basis of the result of your search, you can, at run-time, change your install directory. A Type 35 Custom Action would let you change the install directory:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368093%28v=vs.85%29.aspx