I have a prebuilt binary which was not built with xcode, therefore I don't have any .app or xctest or any other Xcode related build artifacts.
I'd like to run it however on the iOS Simulator. How can I do that?
I've already checked this and this. Didn't help.
Some more background to understand the question:
I am building one of the Boost C++ libraries for iOS and I want to execute it's own unit tests. Boost has a completely different build system (Bjam) and I customised it to use the proper iOS toolchain and clang link/compiler flags.
I can't create an Xcode project for the whole Boost library, I already have a binary file (the unit test), which I just want to execute on the iOS Simulator.
(I could do the same task with Android really easily.)
Thanks,
Gabor
After doing more research I've found the answer.
The answer in short is this: It is not possible to do that.
But I can have nasty and awful workarounds.
Here is what I did for a workaround in case of the boost log tests:
I've already had an Xcode project which was capable of executing some tests on iOS Simulator. So I hacked into the Xcode project all the source files of the boost log tests. This way recompiling them. Still, I don't know what could be the solution if the source files would not be available.
Related
I compiled Qt5 by myself years ago for a Linux project. These days I'm working on Windows and I install Qt5 using the online installer.
Here and there however I face indications that compiling Qt might led to a better debugging experience, last time I notice it was here.
From that days I was using compiled Qt I don't have any memories of better experience than using the online installer.
So I would like to know more about the possible benefits of using a Qt compiled by myself. Is it worth it? Does it give me any extras compared to the online installer?
TLDR: You can use the online installer for initial development and works great with Qt Creator. Maybe later, you might need to build it yourself.
Qt's Windows installer installs most everything you need - including pre-built reference binaries with the most common options available. Perfect for initial development. There's even an option to install the source with the binaries for easy debugging. Download the symbols too if you do this.
You may want to compile the binaries yourself would be for any of the following reasons:
Build with your own custom patches
In case you need to change a build option like the renderer or openssl linkage.
You have a business requirement to build all code you ship.
At least those are the 3 reasons why we build Qt binaries directly ourselves on my team.
We have a complex C++ codebase targeting multiple mobile platforms. We currently have Windows CE (4.2 to 6.5 both raw CE and Mobile based on those), Android (2.1+), iPhone (4+), almost working Bada (2.0+) and if anything comes of the new C++/CX thing, are likely to add Windows Phone (8+). Plus a testing version on Win32 and service application on Win64 that shares some code. We also already tried to compile unit tests on Linux and questions already came (too small business volume so far, but that might change) to get it working on some other Linux platforms.
We currently compile the code with native tools for each platform. Each of them is pretty complex and has some hacks in or around it to achieve reasonably single-click builds. And for Bada, we didn't solve builds outside of the Samsung-tweaked Eclipse yet, which we'll have to do for production.
So far it works, but is becoming more and more of a maintenance problem. The biggest problem currently is the iPhone build, because unlike Visual Studio project files and plain makefiles, it's not possible to add/remove/rename files in XCode project by hand and only two people have MacOS boxen and any experience with XCode (while everybody has Windows and knows Visual Studio). We also need to create some makefiles for the Bada target (it's plain GNU toolchain, so anything capable of cross-compiling with those should do) and I wouldn't mid getting rid of some of the kludges in Android build: fix for bug in dependency handling when building under cygwin, some hacks on top of the ant build script and shell glue to massage manifest and hold it all together.
So I am looking for advice on ways to unify the build process for this set of diverse platforms.
It absolutely has to handle building the iPhone and Bada executables and the native part of the Android build (because nobody has all three platforms to test separately).
Has to handle large project consisting of several shared libraries, one main binary, one test binary for the same platforms and some auxiliary binaries built only on some platforms (well, currently Win32 only).
Has to be able to generate build configuration header and Java file with version from version control system and some user-defied variables, since we do 18 and counting slightly different builds for various customers.
And of course it has to automatically handle dependencies (header files) and generally be reliable.
For the other things I am prepared to hack around any deficiencies, but I would obviously like to keep the amount of shell duct tape and spit to minimum, so it should:
Be able to integrate with Visual Studio, Eclipse and XCode enough that each environment can trigger build, upload the build product to the respective target and attach debugger to it there.
Be able to build Java and call the custom packaging tools for Android, so we don't have to hack around the ant build script that Google gratuitously and incompatibly changed twice in last two years already (and old SDK can't be downloaded).
Be able to install various data files and call random packagers and random other scripts and tools and stuff, so it does not have to be mixed with too much shell script.
We have so far started trying CMake (didn't have much time, so didn't get far, but will have to do something shortly) and also thought about SCons. However I have already tried building with SCons for Windows CE a few years ago, but since it generates makefile-type projects for Visual Studio and those didn't work for embedded platforms in VS2005, I gave up. CMake can generate native makefiles, but a custom, bit out of date, branch is needed for CE. So I'd like to ask whether there are any other tools we might want to look into or any known stumbling blocks with these tools we should be aware of.
Updates: I've found instructions for android native binaries in several places and pixellight even has cmake script to generate apk by directly calling the packaging tools. Also this shell script shows it. iPhone usage seems to be documented here.
The same CMake build files can be used to generate and build projects across platforms for atleast Win32 (VS2005), Linux(ubuntu), and OS X (10.5.8 Leopard), in my personal experince. There are multiple projects for using CMake in the android app build process, eg http://code.google.com/p/android-cmake/. With all these options, I would consider CMake a good option. Further CMake is easy to pick up, and even easier if you have prior experience with writing configure.ac and Makefile.ac files.
Note: How CMake works:
Developer/Maintainer creates CMakefile.
Builder runs cmake, which uses the CMakefile to generate platform specific build files.(linux makefiles/OSX makefiles/VS project files)
Builder fires off the build command.
CMake is the best choise.
Starting with CMake 2.8.11 Windows CE is supported out of the box. Until the release of that version a ​Nightly Binary of CMake can be used.
I am planning to build an app in C++ for ipad. I have never build any app for ios. I want to know whether is it possible to write a C++ app using Lucene library in ipad. Can i write the code in visual c++ and compile it in xcode. Can i use the same code to work in mac os as well? I really wanted to build the app in Java so it works every where but unfortunately I pad doesnt support java.
Please provide me some good suggestions to build this app.
Thank you.
No. You can't build for iPad in Visual Studio.
You can include C++ in "Objective-C++" files, named .mm, but you will have to learn a minimum of Objective-C in which to include your C++ code.
As for using the same code for mac, it depends on how well you separate your logic from your display code - you can reuse some code, but you can't simply hit "build for Mac" and have iPad apps magically run on the Mac. You'll have to, at the very least, build a totally separate interface.
Building apps for iOS, etc requires some simple steps :
Buy a Mac
Learn some Objective-C
There is no other way around that makes sense.
I'm working on a cross-platform C/C++ code base that has Visual C++ (super majority) & XCode developers. It also needs to compile on Linux, because that's where it's deployed. We are currently using a complicated Unix makefile that's called from Visual C++, XCode, & Unix command line.
However, the makefile project causes several productivity losses for Visual C++ developers:
Slower build times
Intellisense & text search don't work well for files not directly referenced in project
No .h dependency generation (not clear how to do on Windows)
Adding a native Visual C++ project has the following downsides:
lots of work to manage all those separate platform configuration as mentioned here Maybe VC++ 2010's hierarchical property sheets will help.
more work due to syncing makefile with native project
Currently, I'm considering to add a native project for Windows developers. Can anyone offer their experience on what's best or suggest how those problems with either approach can be reduced.
I have considered CMake and personally would use it, but it's going to be hard to convince other people to learn cmake & syncing it with the native projects would be an issue.
I have considered CMake and personally would use it, but it's going to be hard to convince other people to learn cmake & syncing it with the native projects would be an issue.
The nice thing about CMake is that it builds ALL of the configurations for you. You would setup a single CMake project, and then use it to generate VS solutions, XCode projects, and unix makefiles for you.
It's a huge improvement - everybody gets to work in their "native" environment, whether they're on Windows, Mac, or Unix.
I've handled this by writing my own converter that would synch scripts for various embedded development environments. If something like the above answer of using CMake does all that for you, then that would be the way to go. But if its too complex, rolling your own custom tool is not that hard. Just has to synch both ways.
Also, if you don't have it. Visual Assist for visual studio is awesome :)
I am not a fan of makefile generators, cmake, qmake and the like.
I am a fan of make. We have a single makefile (well, several actually but they include each other and there is no recursive make involved) which knows all of the project dependencies on all platforms (windows, wince, linux, mac, ...). This gives:
Makefile is really no more than a list of sources (include dependencies are auto-generated during the build)
Same build command on each platform, apart from specifying the tool chain
Build uses all my CPUs
Very short time-to-do-nothing
Developers can use whatever IDE they fancy
vim, emacs, qtcreator, eclipse, XCode all in use
I often use VC++ when on Windows (for the debugger)
Scriptable. Great way to automate your tests
Nice.
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.