I've completed a simple numbers-version of the game "Towers of Hanoi" using xcode's command line tool in C++. Being accustomed to PC compilers like borland's and visual-c, I've attempted to "share" the game with others via e-mail by simply attaching the executable product built by xcode. However, the recipients can't run the program as it shows up in a different format - usually machine code, it sounds like.
After a bit of extensive searching, I'm realizing the complexity of building projects within xcode's IDE and the variations on the build settings/ targets, etc.
Anyone know how to build a self-contained c++ executable to be universally run? I don't go outside the STL library for this game. I'd greatly appreciate any help.
thanks
OS X is based on Unix, which uses plain binary files (i.e. no filename extension) as executables. If they have a certain "executable permission," they can be double-clicked to be run as executables, or run from the command line. However, this permission can't be sent over email - it's metadata within the file system itself, and this makes sense from a security standpoint (you wouldn't want spammers sending you executable viruses over email right?). So when the recipient receives the binary, they'll need to run the following command line command on it, assuming "hanoi" is the name of the binary file:
chmod +x /path/to/hanoi
If you really want to package it as an instantly double-clickable application, you'll need to give it a native UI and package it as a .app, then put that .app (which is actually a folder with the .app extension) in an archive to distribute. Sorry if that's more work than you were hoping for. Hope this helps!
Sharing applications across dot releases of the same OS can be notoriously difficult on the Mac (at least, as far as personal experience goes).
In order to be able to share your application with the least amount of effort, you will need to figure out:
What project type is this? Are you using any resources like images etc?
What version of the OS your friends are using? If they are not on the Mac, you're out of luck (or you'll have to recompile for their OS-es).
If they run Mac, check out that you have the same OS versions, if you have developed on Leopard and someone's running on SnowLeopard your application might simply fail. (I also ran into issues between Mac OS 10.5.4 and 10.5.3 so keep your fingers crossed.)
Check out what sort of hardware you are running. Are you building for your hardware (say, MacIntel) only or are you creating an Universal Binary?
Make sure that all resources are packaged into your application bundle. Make sure your application uses only relative paths.
Check if you are not writing to special folders (i.e. use only temp and/or word-writable locations, if you need to).
I wish I could give a more detailed/to the point reply but unfortunately you'll have to figure out some of the answers yourself (without any other specific information about the error you are getting).
If you're satisfied with a command line tool rather than a double-clickable app, it should suffice to zip it and attach that to the e-mail. Be sure to build universal if anyone you're sending to might be using a PowerPC-based Mac. Oh, and set the deployment target to the minimum OS that any recipient might be using.
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.
I'd like to download Qt. I tried to download it from Qt's website but this gives me an exe file and since I've got a limited account when I try to run it it asks for an admin password. I've searched the web for a way for a limited account to install Qt but I haven't found anything. Could someone please help me find a solution?
In case it matters, I'm using Code::Blocks and Windows 7.
You could download the free software source code and compile and build it on your machine (that takes about a whole night, or maybe more). Don't forget to configure the build appropriately (I don't know Windows, but on Linux I'll suggest explicitly setting the -prefix to some writable directory ...). Before starting, ask explicitly your boss for permission (if you violate your company policies, you can be fired at once), and ask for guidance from someone knowing your operating system better than you do. You might need to change your PATH too.
Alternatively, ask permission to install and use a Linux distribution.
PS. Be sure to get permission to do something (even if technically you can do it alone).
You can download this ZIP file with Qt. All you have to do is unzip the ZIP file (which will take time) and place the files it contains in the right folder, nothing that requires administrator privileges. I recommend you put the contents of the ZIP file in C:\Qt, otherwise it might not work correctly (if this folder doesn't already exist, you can create it without administrator privileges and if it does exist, Qt is probably already installed on your computer in which case you don't need to do anything). I've also posted Qt's license agreement as it is in the installer program here since Qt wants you to read it before you use Qt.
Furthermore, I recommend using Qt Creator to make your Qt projects instead of Code::Blocks, because it's difficult to get Qt5 to work with Code::Blocks and Qt5 is the version of Qt used on both this website and Qt's installer (see this question) (if you find a way to get Qt5 to work with Code::Blocks, all the better, maybe you could even answer the question for which I posted a link). Qt Creator is included in the ZIP files on my website and to use Qt with Qt creator, all you have to do is include the right header files, no linking is needed. The path of Qt Creator is in the table on the bottom of the website.
You can download an archived distribution of MSYS2. After you extract and run it, you can use its packet manager to download numerous packages, including Qt. The only downside is you will have to settle for the version it provides, which is a little old, currently 5.5.1. You can install by typing:
pacman -S mingw-w64-i686-qt5 // for 32bit build or
pacman -S mingw-w64-x86_64-qt5 // for 64bit
This will install Qt and all dependencies automatically. Make sure your antivirus is not running in the final stage, because it can mess with the binary patcher that patches Qt to run from its current installation folder (because advanced software like Qt apparently cannot work without hard-coded paths).
You can even get a static build of Qt, which is quite useful, just add a -static to the package name.
Just in case you were wondering - MSYS2 is a build environment, it can come quite in handy, for getting ready to use libraries, or for building libraries which require a build environment. You can build Qt without it, however, it is a very slow process that may fail, and even though it is not complex to do, I would not recommend it as a first option.
If you still decide to build it from source, there is a detailed guide which will get you through the process.
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.)
Is there any current, relatively simple way to compile and upload full .c/.cpp files for the Arduino DUE on Linux?
I'm beginning to regularly run into issues using the boilerplate code they provide around the sketches and so far, there is very little in the way of documentation or alternative IDE support for the arduino 1.5 SDK... That and the official 1.0.5 IDE is hopelessly broken for linux right now (serial port issues among other things).
There is a great example here.
He explains what you need and how to use it to be able to upload to the due from the terminal of a linux box.
He has done a great job in helping you set up an environment to compile and upload your c programs onto the SAM3X8E. He even gives you a makefile and sample code. What more could you ask for?
Give it a try, see if it works for you.
Even though you can program in c/c++ for the arduio, the arduino does not "use" c/c++ code alone per se. When you use the IDE for arduino, a few libraries are linked when compiled to give you the "arduino" functions like setup(), and loop() as well as constants such as HIGH and LOW. The arduino language is based off a language called Processing which is written in c.
If you are having troubles with the Arduino IDE, it might help to download an older version. Check out the Previous Releases page on their website.
If that still doesn't work, you could try to build it from the source code. https://code.google.com/p/arduino/wiki/BuildingArduino
I wanted to do the same thing as I really don't like IDE like Eclipse. And I didn't want to rely on Arduino environment. Just something minimalist under ubuntu.
For libraries, I downloaded the ASF (Atmel Software Framework) here http://www.atmel.com/tools/avrsoftwareframework.aspx
For compiling, I installed gcc-arm-embedded from here https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded. This provides gcc-arm-none-eabi.
The last part is 'bossac', the upload tool (just do an apt-get install bossa-cli).
Then, just use Vim or your fav editor, adapt a config.mk (configuration of the ASF's MakeFile) for your own project and once okay, upload the .bin to your board with bossac.
Note that bossac has to be run as root (sudo) if you want it to detect your usb port (/dev/ACM0).
After few days playing with examples provided by the ASF library, you'll be able to use a small subset of headers files (only basic definitions like registers names, bits function names in registers ...) to help you and do all the rest by yourself. I personally even don't use 'drivers' files anymore. I directly access registers with my own methods to get smaller code.
I would like to have a single run configuration that I can use whether I'm testing on a Windows system or a Unix system.
Everything seems to be fine with the exception that in the run configurations dialog the field for C/C++ Application requires the extension of the application as well.
So in Windows, it is: Path/To/Application.exe
and on a Unix system, it is: Path/To/Application
If there was someway to automatically detect the OS and apply the appropriate extension, I can share the same *.launch file with everyone working on the project regardless of their operating system.
I've looked a little bit into using Variables to set the path and file name, but most of them require additional dialogs and user inputs. Wild cards don't seem to work here either.
Any ideas?
Thanks to Marc K. for pointing out the quick fix of simply adding ".exe" extensions to the unix executables. Though, as he mentions, this isn't a perfect fix to the problem.