My company is thinking of dumping InstallShield and move to something else, mainly because of the poor experience it had with it, mostly on Linux.
Our product is a C++ application (binaries, shared libraries) targeted at Windows and Linux (Red Hat).
The installer itself isn't required to do anything special, just dump some binaries and shared libraries and sometime execute an external process. Things like version upgrading through the installer isn't necessary, this is handled after the installer finishes.
I thought of suggesting using NSIS on Windows and RPM on Linux.
What are the recommended installer systems to use when deploying to Windows/Linux? Something that is cross platform to prevent maintaining two installers is a definite plus.
For Windows I would definitively use NSIS. It's very lightweight, easy to code and very simple to understand. Using msis would just be a killer - it generates guid for every file so you can get upgrades for free and stuff but truth being said, you never end up using any of these.
Regarding Linux I would go for RPM and Deb. They're probably the two biggest packaging system so you'll be targeting most of the Linux users. I've never tried RPM but creating a Deb package is fairly straightforward.
See also:
What to use for creating a quick and light setup file?
Packaging to use to deploy cross-platform?
And even:
Creating installers for complex cross-platform programs
There's a tool called BitRock Installer which can create installers for Windows, Linux and OS X.
However, I think that if you target RedHat it would be better to provide native packages for that platform (that is .rpm).
For C++ projects, I'd go with cmake/cpack, if you are also willing to change your build system. Great support, strongly cross-platform. cpack has various generators, NSIS is one..
Take a look at InstallJammer. It will handle both platforms from the same build project, and you can have the installer register the package with the RPM database as well if that's your requirement.
You may want to consider our tool BitRock InstallBuilder , it can generate installers for Windows and Linux from a single project file and also RPMs. Is your application based on Qt? Our clients include the makers of Qt, Nokia (previously Trolltech) and they use it to package their Qt Creator product. We encourage to give InstallBuilder a try and contact our support with any questions or suggestions you may have.
Related
I am trying to embed Google's V8 in my game engine. I'm targeting 3 operating systems: Windows, Linux and OS X.
I haven't had any problems with building for Windows - I used NuGet packages. But I'm trying to build V8 for Linux and the problem is - I'm doing this on Windows (Windows 10 if it matters).
Google doesn't exactly say how to compile V8 for Linux using Windows and now I'm really confused, as I have no idea. So far I have depot_tools, properly fetched v8 (using fetch command), Python and MinGW.
I've tried with v8gen.py, but it seems that it generates build files only for Visual Studio. As I said, I don't need VS files.
My question is: What should I do?
This is not possible out-of-the-box with the current build tools and configurations that V8 provides. As suggested in the comments, using a VM might be the quickest way to get this working for you.
If it is very important for you long-term, or for other developers as well, you could look at submitting patches to V8 to make this possible, but I don't have a good sense of how much work that would be.
Am new in Qt Programming and i would like to develop a program which i want to run in Windows, Linux(ubuntu), and Mac.
I heard that Qt support mutli-platform application development,
but my Question is that,
would any Qt library need to run these appilication in Ubuntu after i deployed or compiled?
If you deploy on Ubuntu, and therefore use a .deb package, then your job is easy since you just have to require qt as a dependency and apt will automatically install it as needed.
Windows and Mac however do not have any "good" software management layer, so you have no choice but include the required Qt DLLs with your binary or compile a static one. On Windows you just have to make sure the DLLs are in the same directory as your program. Mac however requires some relinking to be done. This is a big pain, but fortunately Qt comes with a tool named macdeployqt which does this for you.
So according to my experience, Linux is the easiest platform to deploy to, followed by Windows, and Mac is a good last.
The link to the Qt deployment doc given above is a good starting point. If you need an example, I have written a couple of scripts to build the Windows binaries of a program of mine. You can have a look at these to get started.
Windows installer:
http://gitorious.org/tagaini-jisho/tagaini-jisho/blobs/master/pack/win32-cross/buildwin32releases.sh
http://gitorious.org/tagaini-jisho/tagaini-jisho/blobs/master/pack/win32-cross/tagainijisho.nsi
Talking for the Linux side here, if you distribute your application as packages (deb, rpm) then you can use the package dependencies rules. If you define these rules correctly, then the package manager will install the Qt libraries you need when installing your application.
I am looking for a program that can take the program I made in Visual C++ 2008 and distribute it in a mature installer for Windows. I want an application that is FREE (or trial).
The setup and deployment folder is not there when a select File-->Add-->New Project
You can try NSIS (Nullsoft Scriptable Install System), which is free, but can be confusing because it's lots of scripts. That said, it can do anything you might want to do.
Install Creator from ClickTeam is very simple to use and is my preferred application but it does cost money.
WiX has a fairly steep learning curve, but it gives you full access to all features of Windows Installer, with no limitations. It's originally an Microsoft project, and is what Microsoft uses internally for many of its products. It's free and open source under the Common Public License (which permits its use in closed-source products without requiring you to license your own code under it).
For a setup .exe I like Inno Setup, which will let you do desktop icons, amongst other things. Basically you create an Inno Setup installer file which you can pass into the setup compiler which means you can also build it from the command-line. They provide both a GUI and a command-line compiler. The bundled documentation is also very complete.
For MSI you can try the Windows Installer XML (WiX) toolset., which is similar to Inno Setup in that you can compile from the command-line, but a certain amount of Windows Installer / MSI knowledge is expected.
Use setup project in Visual Studio
Check the following programs:
Inno Setup
NSIS
Don't forget to include Microsoft Visual C++ Redistributable Package
Take a look at InstallJammer. Free, open source and easy enough to make a simple installer in minutes while also supporting complex, scripted installers if you find you need them.
I'm involved in C++ project targeted for Windows and Linux (RHEL) platforms. Till now the development was purely done on Visual Studio 2008. For Linux compilation we used 3rd party Visual Studio plugin, which read VS solution/perojects files and remotely compiled on Linux machine.
Recently the decision was to abandon the 3rd party plugin.
Now my big concern is a build system. I was looking around for cross platform build tools. This way I don't need to maintain two set of build files (e.g. vcproj/solution for Windows and make files for Linux).
I found the following candidates:
a. Scons
b. cmake
What do you think about the tools for cross-platfrom development?
Yet another point that bothers me is that Visual Studio (+ Visual Assist) will loose a lot functionality without vcproj files - how you handle the issue with the tools?
Thanks
Dima
PS 1: Something that I like about Scons is that it
(a) uses python and hence it's flexible, while cmake uses propriety language (I understand that it's not a winner feature for a build-system) (b) self contained (no need to generate makefiles on Linux as with cmake).
So why not Scons? Why in your projects the decision was to use cmake?
CMake will allow you to still use Visual Studio solutions and project files. Cmake doesn't build the source code itself, rather it generated build-files for you. For Linux this can be Code::Blocks, KDevelop or plain makefiles or still other more esoteric choices . For Windows it can be among others Visual Studio project files and still others for MacOS.
So Visual Studio solutions and projects are created from your CMakeLists.txt. This works for big projects just fine. E.g. current Ogre3d uses CMake for all platforms (Windows, Linux, MacOS and IPhone) and it works really well.
I don't know much about scons in that regard though, I only used to build one library and only in Linux. So I can't compare these two on fair ground. But for our multi-platform projects CMake is strong enough.
I haven't used Scons before, so can't say how that works, but CMake works pretty well.
It works by producing the build files needed for the platform you're targeting.
When used to target VC++, it produces solution and project files so from VS, it appears as if they were native VS projects. The only difference is, of course, that if you edit the project or solution directly through VS, the changes will be erased the next time you run CMake, as it overwrites your project/solution files.
So any changes have to be made to the CMake files instead.
We have a big number of core libraries and applications based on those libraries. We maintain a Makefile based build system on Linux and on Windows using the Visual Studio solution for each project or library.
We find it works well for our needs, each library or app is developed either on linux or windows with cross compilation in mind (e.g. don't use platform specific api's). We use boost for stuff like file paths, threads and so on. In specific cases we use templates/#defines to select platform specific solution (for example events). When is ready we move to the other system (linux or windows), recompile, fix warnings/errors and test.
Instead of spending time figuring out tools that can cross compile on both platforms we use system that is best for each platform and spend time fixing specific issues and making the software better.
We have GUI apps only on Windows atm. so there's no GUI to cross compile. Most of our development that is shared between Windows and Linux is server side networking (sockets, TCP/IP, UDP ...) and then client side tools on Linux and GUI apps on Windows.
Using with perforce for source code version management we find in quite many cases that the Linux Makefile system is much more flexible for what we need then Windows VS. Especially for using multiple workspaces (views of source code versions) where we need to point to common directories and so on. On Linux this can be done automatically running a script to update environment variables, on Visual Studio referencing environment variables is very inflexible because it's hard to update automatically between views/branches.
Re sync question:
I assume you are asking how to make sure that the two build systems get synchronized between linux and windows. We are actually using Hudson on Linux and CruiseControl on Windows (we had windows first with cruise control, when I went to setup linux version I figured Hudson is better so now we have mixed environment). Our systems are running all the time. When something is updated it is tested and released (either windows or linux version) so you would know right away if it does not work. During testing we make sure all the latest features are there and fully functional. I guess that's it, no dark magic involved.
Oh you mean build scripts ... Each application has it's own solution, in solution you setup up dependencies. On Linux side I have a makefile for each project and a build script in project directory that takes care of all dependencies, this mostly means build core libraries and couple of specific frameworks required for given app. As you can see this is different for each platform, it is easy to add line to build script that changes to directory and makes required project.
It helps to have projects setup in consistent way.
On Windows you open project and add dependency project. Again no magic involved. I see this kind of tasks as development related, for example you added new functionality to a project and have to link in the frameworks and headers. So from my point of view there is no reason to automate these - as they are part of what developers do when they implement features.
Another options is premake. It's like cmake in that it generates solutions from definition files. It's open source and the latest version is very highly customizable using Lua scripting. We were able to add custom platform support without too much trouble. For your situation it has support for both Visual Studio and GNU makefiles standard.
See Premake 4.0 Homepage
CruiseControl is a good choice for continuous integration. We have it running on Linux using Mono with success.
Here is an article about the decision made by KDE developers to choose CMake over SCons. However I've to point that this article is almost three years old, so scons should have improved.
Here is comparison of SCons with other building tools.
Had to do this a lot in the past. What we did is use gnu make for virtually everything including windows at times.
You can use the project files under windows if you prefer and use gnu make for Linux.
There isn't really a nice way to write cross platform makefiles because the target file will
be different among other things (and pathname issues, \ vs / etc). In general, you'll probably be tweaking the code across the various platforms to take subtle differences into account, so a tweak to a make file and checking on the other platforms would have to happen
anyway.
Many OS projects maintain Makefiles for different platforms such as zlib where they are named like Makefile.win, Makefile.linux etc. You could follow their lead.
How do Window's programmers profile their native C++ code?
On Unix/Linux you have gprof [thanks Evan] & valgrind (I personally used this one, although it's not a real profiler), and recently I'm on Mac and Solaris, which means I moved to dTrace. Now when I've had the need to profile on Windows in the past, like at my previous job, I used Intel's vtune, which is great, however it's commercial, and I don't have a license for private use, so I'm left wondering what's the standard (free is better) tool windows programmers commonly use?
Thanks in advance
You should give Xperf a try - it's a new system wide performance tool that can drill down to a particular application and what exactly it's doing inside itself as well as what's it's asking of the OS.
It's freely available on the Windows SDK for Windows Server 2008 and .NET Framework 3.5 ISO:
Install the SDK by downloading the ISO image, or using the Web based
installer.
Find the xperf MSI in the SDK's "bin" directory. It will be named
xperf_x86.msi, xperf_x64.msi, or
xperf_ia64.msi, depending on the
architecture for which you install the
SDK.
You can then install the xperf tools from the MSI directly, or copy
the xperf MSI file to another location
and install it from there. For
example, you could keep the MSI files
on a USB key.
Source: Pigs Can Fly blog on MSDN.com
Just verified that the xperf msi will not install except on windows Vista or Windows 2007.
-Adam
I got AMD Code Analyst. It's free, and you don't need an AMD CPU ;)
It's a little basic compared to something like Intel's VTune, but the price is right.
This link talks about Linux, but I use the same technique in MSVC and in C#.