1 Answer
1

Packaging

You would probably want to play to the normal expectations for each platform involved.

For example, Linux software is usually distributed through package managers, or as a package (RPM file, DEB file), or in the most basic form, an archive like tar, or a compressed tar. In the Linux world, though, since every distribution has very different environments/library versions, people usually ship source and then build for that specific platform to ensure the best compatibility.

Mac OSX software is typically distributed as a DMG or mpkg.

Windows software is usually distributed as an installer (either MSI or custom-exe), which can be built with software like Inno Setup, Wix, Nullsoft Installer, or if your users are savvier/you want to provide a portable app, you can provide a zip or a 7-zip self-executable.

Keeping your source hidden

Ignoring the group of users who would reverse engineer/decompile your code, you can provide software to your customers with Python. CPython compiles code to intermediate python byte code files, with the extension .pyc, and you can ship those to your users.

On Windows, you can use py2exe to create an executable. If you also don't want to assume your Linux users have python installed (which most would, but they might have versions you are incompatible with), then you can also use freeze, which allows you to ship python apps that don't rely on a pre-installed python.

More than just command line apps

If you take that Python information above, you can still build GUI apps with Python. You could use pyqt4, for example, which is a Python wrapper around the Qt4 framework.

In general you're going to be able to build GUIs, or use wrappers around other GUI libraries, in any language you'd realistically use.

High productivity

Well, this one is more vague - you use python, and python is high level. If the freeze/py2exe/compiled-python files work for you, then you don't really need to switch.

You could use a Java-based language, and build with something like Maven to create a JAR file which you could release to users. There is an (outdated) implementation of Python on Java (jython), a well-maintained Ruby implementation (JRuby), as well as other languages like Scala, Clojure, and Groovy. You can use Swing, SWT, or something like Jambi (Qt4 for Java) to build the UI for apps.

Of course you can fall back on using C or C++, and then use a build system like cmake to build and package your software (it supports creating archives of builds, as well as external tools like Inno), but how productive you are in C++ really depends on your comfort in using it and libraries and such that you need.

I'll just throw in an interesting choice here, for fun. Haskell (specifically Glasgow Haskell) can be compiled to native code, and can use C libraries through the FFI (foreign function interface). If you're a functional language wizard, it's a productive language.

How I did it

In the one job where I built software that required end users to install it, I wrote code in C++, and the building and packaging were handled for Windows and Red Hat Enterprise 4 and Red Hat Enterprise 5. We did not officially support other Linux distributions aside from special contract agreements, because of the time investment and the fact that no one used anything else to run this software.

The build system used cmake to build all the code, and for Windows builds, it would then package by calling out to Inno, which we scripted to copy all the libraries and build files necessary to ship an installer that would install a working copy of the software.

For Linux builds, the system used cmake's built in packaging mechanism and a file telling it how to package, where to place files, and such was created. The build system would package all the necessary libraries that the target Linux would not have by default (stuff like boost, Qt4, etc. was packaged by us), and so even if they ran it on a basic install, the libraries needed to run the code (aside from basic stuff like libc and libstdc++) were installed by us.

@Hiett - there was a lot more I could say, but I'm not sure how much I could type before your eyes would glaze over. One thing I didn't mention, though, is static linking stuff in (if you're using a language like C and C++) which would allow you ship an app that had all the libraries it needed built into the executable, at the expense of binary size and not taking advantage of shared libraries (higher memory usage when running).
–
birryreeFeb 23 '12 at 21:39

i'm currently developing a C embedded type application, its taking forever due to the low-level, requirement in the future may be for a cross platform GUI app hence my OP - I'm keen to take advantage of another language to improve productivity. As an aside we also have some prolog apps which we would like to develop GUIs for but its such a niche language its hard to find binding s for decent modern GUI frameworks.
–
bphFeb 23 '12 at 21:52

@Hiett - I don't know what flavor of Prolog you use, but SWI Prolog has bindings with C++: swi-prolog.org/FAQ/CppBinding.html. You could do that and then write your stuff in C++. Funky for sure, but it works if you're trying to transition. Alternatively there are SWIG wrappers.
–
birryreeFeb 23 '12 at 22:00