VS Code GLFW and GLAD development in Mac and Windows - c++

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.

Related

Qt Application : How to create standalone executable file for Windows (& Mac) from Mac?

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.)

How build harfbuzz without dependencies

I want build latest harfbuzz-ng library on Windows 7. But in build system by default I must go through long quest to gain: ragel, pkg-config, gtkdocize and other stuff. Even in the end if I get all what need for build system I get errors (sorry cannot say which concrete errors), last time I tried to build this library 2 month ago). Maybe on Linux system it is easy to get and build all this stuff but on Windows always something doesn't want to be compiled. Or the problem is that I don't find instructions which guide me on Windows, only Linux.
What I want to get is simple instructions how build only harfbuzz-ng with freetype dependency (and maybe add ICU) by MinGW compiler on Windows.
Thanks you very much.
For anyone reading this, have a look at harfbuzz.cc in the project which makes you able to use harfbuzz without any build system, just include it in one of your sources, no build system is required, define HB_NO_MT or even HB_TINY (which brings a minimal harfbuzz) if you don't use harfbuzz in multithread mode.
I don't know i this is the answer you are looking for. I am trying to work with Harfbuzz as well and did this through several attempts which did not work out for various reasons.
One (old) example you could use as a starter is: HarfBuzz static lib. The .lib-file generated works with UCDN and just needs this file plus a source for the Freetype-functions to provide the necessary FT_Face-parameter (i did this by compiling another .lib via the freetype-sourcecode (freetype.org/download.html).
But I am unsure if this will work out for the MinGW-compiler (you don't use VC++ as IDE do you??).
You may find of interest the MSYS2 build system. It is essentially a linux-style packaging system built on top of Windows(TM). You can download and install binary packages with simple commands (including automatic dependency solving). If you want to download a source package you can do that as well. http://msys2.github.io

Managing a collection of libraries for C++ development on Windows

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.

How to prepare a codebase for compiling on both Windows and Unix-based systems

I am wondering about different solutions to easily compile my cross-platform application for both windows and unix.
Right now I am using a makefile on Ubuntu, but before my codebase grows larger I'd like to perform the steps necessary to compile it on Windows, and then continue doing so regularly to see that it still works.
I'd preferably not contaminate my SVN codebase repository with multiple "makefile" solutions, such as VC++ solutions and so on, I'd like a more automatic way. I tried using mingw with make for windows, but it seems my secondexpansion awesomeness doesn't work on the Windows version (or something like that). It wouldn't compile, and also complained about _winNT or something like that not being defined.
How should I prepare my codebase for cross-platform easy compiling? Things like buildtools, perhaps autogenerate VS file from makefile, or something similar. Some preprocessor magic in a stdinc file perhaps?
Thanks!
I will point you to CMake which is used by high-profile projects, such as MySQL, KDE, or Compiz.
It has the ability to generate native build files for the target system, such as Makefiles for Unix-based platforms, and Visual C++ project and solution files for Windows.
In order to deal with platform differences, I invite you to see my previous post on this subject: C++: Platform dependent types - best pattern
I would go for boost build: http://www.boost.org/doc/tools/build/doc/html/index.html
You can choose your platform and your compiler from the command line (dos command prompt on Windows) and everything else works.
e.g
bjam release gcc,
or
bjam debug msvc
You can add extra flags for each compiler (if you so wish) or different versions of the compiler.

What do people need to run my application?

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.