I want to build a C++ library for Mac and iOS using the same Xcode project. When I'm creating a new project in Xcode I can choose Mac OS C++ library, but there is no similar option for iOS. The code is exactly the same on both platforms and I don't see any point having 2 different projects.
Can you provide me some guidance to achieve this?
EDIT: Now I'm using same project with different targets, one for Mac and one for iOS
Depending on what you want to use this library for, creating an iOS fake framework may also be an option: https://github.com/kstenerud/iOS-Universal-Framework/tree/master
I usually create both (libraries and (fake) frameworks) for a) binary-delivery only SDK projects or b) very fat libraries which are rarely changed but often used. An example for the latter is SQLite, which takes very long to compile for iOS and is maybe changed once a year. But for debugging purpose, I use the same project and code base using a static library target (for when we update the fake framework once in a while and need to debug it).
Related
I just wanted to ask if anyone has been able to setup your GLFW/GLAD project in VS Code to work both in Mac and Windows, as I usually have to switch between those 2 OS and I would like to be able to work on my project on both of them.
These libraries work across multiple platforms, and program code that uses them can too. Building your projects is your primary issue, which you can do either by writing a build script for both of your platforms, a makefile, or by using something like MSYS2/Cygwin to make your Windows environment more like your Mac one. I'm sure there are many other options too!
You'll want to set up version control to allow you to work on the same project from both environments without having to copy files over manually. Unless you want to compile all our libraries from source (which you might), your best bet would be to ignore your library folders from the main version control branch so that they can differ between environments.
I have written windows gui application using qt and i want to deploy it.Now when i place .exe to other PC it shows error which says that qt5core.dll and etc required.I can install this dll,but is it possible to run exe app with qt without qt's dll as one file?So i can for example give .exe to my friend and he can instantly run it without installing .dll?
Basically, if you want a single exe file, you probably mean static linking.
The legal commercial version makes it possible or if I am not wrong, you will have to build a static qt version.
In the latter case, you will have to provide the source code of your application.
I do this sometimes, but you'll have to be careful with the license requirements: if you go with GPL, it should be OK, if you choose LGPL, it may be a bit less simple. No idea about the commercial version.
What you must do is building Qt statically, and then use that Qt build to build your application. I had a good experience with mxe. MXE builds an entire crossbuild environment and allows you to build your big Qt exe statically. I used it on Mac OS and Linux to build static executables for Windows, but you can probably run it on WSL. It takes a bit to compile, but it is simple to use. Please note that it cannot be used if your app needs QtWebEngine as it won't build with mingw.
Another simpler option is to create an installer. The Qt installer framework is simple to use. If you include the VS runtime, you end up with a single exe to distribute (the installer).
You always need to include the libraries you use (including your compilers runtime libraries in fact) when you deploy your executable - otherwise how would your application be able to use the code in those libraries? You may be able to statically link some/most things, but rarely everything. Look into how to create an installer / package for your application, so you can bundle up everything as one convenient file.
You can buid you app using QT Static (a large .exe file, no external dependencies)
If you are using LGPL Qt, you must read this:
https://www.qt.io/faq/3.7.-what-are-my-obligations-when-using-qt-under-the-lgpl
Yo can use Qt and static linking, but "The user of your application has to be able to re-link your application against a different or modified version of the Qt library"
You can use an application template like this, very useful for LGPL Qt:
https://marketplace.qt.io/products/qt-lgpl-app-template
I'm responsible for developing a set of C++ libraries and programs. Currently building on Linux and MacOS, but Windows support is also a requirement. We will need to support VS2010 and VS2012, and in the future will also include VS2013 and maybe also MinGW. We're using cmake for building, so our code should build on all the platforms without issues; my problem is how to manage all the dependencies on Windows in order to be able to build in the first place, and keeping it up-to-date over time. At the moment, we have one virtual machine per visual studio version as a jenkins slave, so parallel builds of all the variants is fairly easy, but managing it is not.
The problem is the number of variants this requires building. If we consider only VS2010 and VS2012, with debug/release and i386/x64 builds, that's already 8 copies of each library; 16 if we include the other compilers. We will need all the libraries our code depends on, which will include at a minimum boost, qt, xerces+xalan, zlib, icu, libpng/tiff/jpeg, hdf5 and more, plus python, and all their dependencies. And as new upstream releases are made, we'll need to keep the entire collection up-to-date and consistent for all the build/arch/compiler variants.
I don't want to do this by hand, since this really needs automating. However, I'm unaware of any good solution for doing this on Windows. The Windows building guides I've seen for other projects often involve hand-building all the dependencies, and only build for a single variant. On Linux, it's already packaged, you don't need separate debug builds, and the arch variants can be catered for with chroots; on MacOS there's homebrew, macports etc., and it's also fairly simple to automate stuff there as well. Is there any equivalent for Windows? I've looked at stuff like chocolatey, but it's entirely unsuited to handling libraries, and is pretty poor as a package manager.
This seems like it should be a common problem for anyone doing C++ development on Windows? Are there any common solutions, tools or methodologies for managing a complex set of libraries and tools for development? How do other developers manage this?
NB. Just for the record, we are not using the visual studio application; we're doing all builds non-interactively via scripts driving the compilers directly with cmake and/or msbuild.
Many thanks,
Roger
I worked on large windows C++ project that delivers X86 Release, x86 Debug, x64 Release and x64 debug. Very similarly I used build system that does parallel builds for all target platforms using custom script.
We manage all third party dependency libraries in organized folders.
For example x86\release\Zlib.dll x86\Debug\zlib.dll x64\release\zlib.dll x64\zlib.dll
Custom script is made to pick all these libraries and project source code from configuration management tool. This allows to automatically build the relevant target binaries as needed.
any third party libraries change is updated in configuration management tool and then later picked up by the script for the next build.
For your question on VS2010 and 2012 support I don't understand importance. Is not one version of VS enough to support for the project?
you may take a look at Link, and their build system https://github.com/gisinternals/buildsystem
It's basicly a set of batch and make files calling each others. You still need keep track of lib update manually.
I am currently working on an opensource C++ project. I don't have much experience in C++ as my daily job mainly involves with Java. I am now planning to release my C++ project and I would like to know how should I should I arrange the packaging of my project. E.g, in Java, all the class files are packaged into jar file. So what is the equivalent approach in C++? Is there any good practise for organizing the source code/binary? My target platform is Linux by the way.
Another question is I am currently using Eclipse CDT plugin for development and building. So is there anyway that I can extract build script from Eclipse project and use it as generic build script? Is there any good reference regarding C++ build/packaging? Thanks in advance.
Edited
To clarify a bit more, I think the release of my project can be considered as an application. It's a command line tool for software configuration management.
I am currently working on an opensource C++ project.
That simplifies many things. You should supply the build scripts for you project and support them for different use cases (learn about Makefiles, there are similar concepts like "target").
I don't have much experience in C++ as my daily job mainly involves with Java.
Most of the things you're used to have (and ask for right now) in Java are invented because they lack in C/C++. Learn at least something about dynamic(shared)/static libraries (.so and .a files to be simple).
I am now planning to release my C++ project and I would like to know how should I should I arrange the packaging of my project.
The "packaging of a C++ project" is something informal. You may supply the sources, build scripts and some project-files for the well-known IDEs.
EDIT: you've specified that you're building the command-line application. I believe all you need is to start from a simple Makfile for that application. The reference Makefile can be automatically generated by Eclipse. If you are planning to deploy your application as a stand-alone software, then you have to earn about packaging (rpm, deb, tgz).
E.g, in Java, all the class files are packaged into jar file.
There are no such thing as a C++ "package" compatible accross compilers (even the "modules" were rejected in the latest C++11 standard)
because there is no binary standard to encode C++ classes (ABI). On linux you're most likely going to use GCC (or Intel's compiler, or LLVM's CLang, or custom build of OpenWatcom or...),
but the version of standard library you are linking to makes the release of binary builds close to useless.
That is the reason for redistibuting source code.
So what is the equivalent approach in C++?
No clear answer here.
Is there any good practise for organizing the source code/binary?
Look at the large-scale projects, see the way they organize their builds. The term "build engineer" as an occupation emphasizes the difficulties of large-scale projects compilation/linking.
My target platform is Linux by the way.
This is also something of an incomplete description. "Linux" is a blurry term. You should speak about the Linux distribution, compiler toolchain and package manager. E.g., Ubuntu 12, amd64, GCC 4.6 toolchain, APT package manager.
There are different "linuxes" built around the same kernel source. There are different compilers. There are at least three major package managers to consider: Debian/Ubuntu(deb,apt), Red Hat(rpm), Slackware(tgz).
Another question is I am currently using Eclipse CDT plugin for development and building. So is there anyway that I can extract build script from Eclipse project
There's a sort of "meta-technique": you write a "description" of your project and then a tool generates the project-file and build scripts for your sources. Have a look at CMake. Since you're on "linux", try looking at the somewhat standard way of autotools (autoconf).
Is there any good reference regarding C++ build/packaging?
You should start by building your application and then move on to the deployment issues. C/C++ is a hard-to-learn legacy with a lot of subtleties which are avoided in Java.
I made a little app and built a release version. Now I want to upload it to my site. I have never done this before with Qt, so I'm unsure as to what I should include along with the binary.
How do I figure out which DLLs should be included with my app? And where do I get them? I'm running Windows, but I'd also like to know what I should do in case I want to release a Linux version.
For windows:
You can use dependency walker to see what Qt libraries (or others) you should ship. This is the depends.exe executable that is included with Visual Studio, but you can download it separately from: http://www.dependencywalker.com/
Load your app into that and it will list out all the modules it expects at runtime. You might also have to ship a Visual C++ Runtime Redistributable compatible with the compiler that you built the executable with (if it's VC++).
Do note that dependency walker does not account for things like Qt's plugins. An example of this would be the QtAssistant system (for help menu-type functionality), which as of Qt4 relies on Qt's sqlite functionality, which is typically built as a plugin (qtsqlite4.dll if I remember).
For Linux:
This is trickier because of wider disparities in Linux distributions. You can of course use the GNU build system if you want to ship source, but if you're shipping binaries, and want to support a variety of distros, you might do best to build packages for each platform you want to release on.
In my past, a company I worked for switched to using cmake and after setting up all the project and build files, used that to generate builds and packages for different OSes. On Windows, this meant hooking in with Inno Setup, and for Unix-like systems, cmake knows how to generate things like installable shell scripts. Definitely made life much easier.
Our QA department would test our software in virtual machine instances of our supported platforms, completely clean, and see if anything was missing.
If you're talking about DLLs, I assume it is about Windows.
Use Dependency Walker to see the DLL dependencies.
Or... take a clean system, with no dev tools installed, and put your executable, try to run it there, and see what DLLs are reported as necessary and inexistent. Put the DLLs near the executable.
For a Linux version, you can either create platform targeted releases of installers for each Linux fork or you can let people compile from source. If your app is new, the only way you get exposure is supply people with readymade installers, the targeted installers. New users loathe compiling packages from source.
You can try debian (.deb) and redhat (.rpm) packages first. These two are extremely popular lines and will let you have a taste of things.