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.
Related
I want to use some of the great libraries out there (e.g. cgal), but don't know how (have been exclusively writing my own code so far).
It seems every library requires a different process in order to use it (at least on windows)
I'm currently using Clion as an IDE in Windows 10 with minGW. I've tried using the Conan dependency manager but couldn't get it to work (and the documentation/video tutorials are not done very well).
Is there a recommended simple way to do it?
Is using vcpkg with visual studio a good way to go about it?
edit: for clarification, I am an academic physicist developing scientific simulations mostly to be used by myself, so I don't have to package my code with all the dependencies included.
Thanks.
I need to configure Thrift for Eclipse project with MinGW compiler. I googled for it. I couldn't find proper instructions to do that? Can somebody suggest any suitable way or proper link to do that?
There are several partial answers to this.
The Windows build is made by means of MinGW cross compiler on a Linux machine.
Since (at least) 0.9.2 it is no longer necessary to use MinGW to build the Thrift compiler on a Windows machine.1) Aside from the fact, that you don't need to do that at all, because a precompiled EXE is available on the download pages, there is a nice Visual Studio project to build the Windows Thrift compiler EXE. The project has only two dependencies: Bison and Lexx/Yacc, which are both available elsewhere as precompiled Setups as well.
In either case MinGW is only used to build the compiler. If you want to build the libraries with MinGW, I'm not sure if that even works. This way of doing things is not implemented or supported, simply because nobody needs it.
Which brings us back to the question, why you think you "need" it this way.
1)To my knowledge, numerous severe problems exist with the autotools and all the stuff needed to build Thrift under MinGW on a Windows machine. You will have to patch things, build some from source, spend a lot of time and do some strange things with your file system to make it work. At least that was the case when I stopped using MinGW to build Thrift about two years ago. And even if you get it to work, you still only get the compiler (which you could easily download in a fraction of that time), not the libraries.
I have successfully installed allegro 4.2.3 in accordance with the instructions at the following link and it all works great:
http://blog.hamidnazari.com/2010/07/21/installing-allegro-on-visual-cpp-express-2010/
The only thing I've ended up deviating from in respect to the tutorial linked above, is I've selected Windows Application instead of Console Application where illustrated within the 3rd graphical example (note selecting between Win32 Console Application or Win32 Project as illustrated in the 2nd graphical example, I've found to make no noticeable difference so far).
Selecting Windows Application where illustrated in the 3rd graphical example, has for me at least, simply resulted in NOT Needing to include the line: #define USE_CONSOLE in all my Allegro programs.
Please in respect of the tutorial linked above and the title of this post, can someone please help me by answering the following question:
Start of Question:
How can I get my Allegro games to work on other computers that use Windows, without the other computers requiring that Visual C++ 2010 Express be installed, And/Or the pre-built binary version of Allegro 4.2.3 (linked to in the above tutorial) also being required to be on the other computers and linked to/configured within Visual C++ 2010 Express, also described in the above tutorial.
End of Question
Incidentally: A great link for anyone interested in making standard C++ programs (i.e. that don't use Allegro or other various libraries) work by having a fully independent .exe file (compiled/built using Visual C++ 2010 Express) which can indeed run on other computers using windows, is below:
http://www.youtube.com/watch?v=AvrjQtFBJvk
Thank you for taking the time to read this post and I hope very much that someone is able to help.
Gary.
My Reply To Matthews 1st Answer Is Below:
Hi Matthew,
I’ve been looking on Google to try and find out how the various elements you mention, fit in with and compare to the linked tutorial in my post which explains step by step how to configure visual C++ 2010 Express with the Allegro 4.2.3 binary.
The first thing I want to check with you, is if all the binaries in the 4.4.2 section and 4.2.3 section on the Allegro.cc site, are essentially both pre-built binaries, and therefore ultimately configuring version 4.4.2 to work with VC++ 2010 should be in principle similar to configuring version 4.2.3 (or perhaps not?) I have downloaded version 4.4.2 and can see that there are indeed the same 3 folders, bin, include & lib.
Here is the link again to the online tutorial which explains how to successfully configure step by step, Allegro 4.2.3 with visual C++ 2010 Express:
http://blog.hamidnazari.com/2010/07/21/installing-allegro-on-visual-cpp-express-2010/
Working through the steps in the above tutorial, I have noticed additional elements in your initial answer which I have listed below. (Please note, although the tutorial does indeed work well for version 4.2.3, simply selecting the release option instead of debug when building does not result in the .exe files working on other windows computers (although the .exe file in the release folder does still run on my primary computer), and so I guess there are other things that need to be done in addition to selecting release.
1) allegro-4.4.2-monolith-static-mt.lib --- Does this need to be added to additional dependencies in the Input Section within the Linker dropdown for both debug and release. (Also how does this compare with the tutorial for this part of the configuration i.e. are there any other additional dependencies)
2) link to all the various Win32 libraries when you static link --- I don’t know how to link to these libraries. I’m a bit stumped on this.
3) #define ALLEGRO_STATICLINK --- Does this mean that “ALLEGRO_STATICLINK” needs adding to the Preprocessor Section within the C/C++ dropdown, as I read somebody else did in an attempt to get it all working for 4.4.2
To conclude: I suppose to ask my initial question once again considering all that has been said so far, I would ask it in the following 2 parts:
Part 1) How would the online tutorial need adding to/modifying for static builds to work successfully on other computers using windows for version 4.2.3, and would this then just mean selecting the release build option and of course keeping together any files linked with the .exe when distributing.
Part 2) If using the 4.4.2 version, again how would the online tutorial need adding to/modifying for static and dynamic builds to work successfully.
Tutorial type answers to Part 1 or 2 would be awesome for me and many other newbies
Thank you very much indeed for reading this post.
Allegro 4.2 is painfully old. You should use 4.4 at minimum. It is source compatible with 4.2 (same API) and still receives updates from time to time. Allegro 5 is where all the active development is now, but it has a completely new API. I still highly recommend that you take a look at it.
Anyway, to answer the question, yes, you need to static link. Grab a binary from here:
https://www.allegro.cc/files/?v=4.4
Link with the allegro-4.4.2-monolith-static-mt.lib file, and make sure you compile using the /MT switch (as opposed to /MD). The -static aspect means the Allegro DLL is not needed. the -mt flag means the C runtime is not needed.
You'll also need to link to all the various Win32 libraries when you static link. Also, be sure to #define ALLEGRO_STATICLINK in your project settings.
It's been a little while, but if I remember correctly there's an easy way to do this, though it's probably not the best way. It's good for just sending a little demo to a friend. Even if you just build in Debug mode, you can send the game over to other people. Copy/paste the allegro-4.2.2-monolith-md.lib file (Its name is something like that, but probably not that exactly) into the project's Debug folder (next to the .exe). You'll probably also need the MSVCR1000.lib file (or something like that. Can't remember the exact name), but you'll have to find that online somewhere.
DISCLAIMER: I've never used such a completely old version of Allegro, so this solution may not exactly be applicable. But I was using Allegro after version 5 and up to 5.6, so I know it works for newer versions. You should just use a newer version, really.
I would like to develop a Windows build of my Android game for testing and demo purposes. Most of my code is C++, using OpenGL to render, with a thin Android/Java layer that forwards touch events and loads resources.
My first thought was to make a Visual Studio project for my Windows version, as I'm familiar with it and the debugger is excellent.
Can I get similar C++ debugging functionality with Eclipse & CDT? It seems tidier to have all versions working from the same IDE, and it would be nice to become less dependant on proprietary software. Would I be able to add a Windows build configuration in CDT, switch over, and have the IDE launch & debug my Windows version instead? Or would I be entering a world of pain setting this up?
Are there any other approaches I haven't considered? All advice welcome!
CDT is a perfectly good Windows development environment. Just make sure that you have installed the Windows SDK.
If the concern is that Visual Studio puts a lot of the Windows-specific code in place for you, you might consider starting a new project in it. I'd avoid MFC. Just create a new Win32 project. Then, you could take that code and use it as the basis for your Eclipse project, folding in the platform-independent code from your original Android game.
You can easily come up with a cross-IDE solution using makefiles. I guess cmake could help you here.
You could try out MPC. It can generate VS solutions or Eclipse CDT projects(and some more). I've been using it at my previous job and it's really neat once you get the hang of it(which shouldn't be very hard). I'm not sure how well does it work in a
cross-compilation environment, as we were using it to build our project on PC for Linux/Windows.
There's no reason why you shouldn't be able to use Eclipse on WIndows as well.
As far as I know though (I haven't used Eclipse for C++ that much), Visual Studio still has the best debugger. (it can also be a good code health check to compile it with more than one compiler). So there may be reasons to go with VS as well.
If you do decide to go with VS for the Windows version, you may want to look into CMake for managing the build system, since it can generate Visual Studio solutions as well as makefiles and pretty much anything else you may need to build.
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.