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.
Related
I am new (relatively) to C++ and to SO.
Having stretched the creativity of console applications to the limit, my very rabid mind wants to know how to code GUIs now. I did some research, decided to use GTK rather than Qt because of having freedom of choice, there being no strings attached and something about slow internet and having to download some 0.6GB were I to go with Qt.
It has been a brutal 48 hours trying to build 'Hello World' on Gtk. This is me throwing a tantrum. I'm using Visual Studio 2010. Perhaps this is the source of all my woes. It seems Gtk is meant for C and not C++. After solving issues with header files includes and a certain notorious glibconfig.h missing (which I downloaded from the internet only to find, to my horror,that it is supposed to be a generated file), the compiler threw syntax errors,especially in one gatomic.h.
I suspect 10 errors will come up for every one I manage to solve. This is where you come in. Do you use Gtk to develop c++? If not, why so? What would you recommend instead? Do you use Gtk on windows? How is that possible? Please give details.
Is it possible to make cross-platform apps that use C++ code and a Python/VB GUI?
Your answer will be sincerely appreciated.
First off, a general note: Gtk being mainly developed as a toolkit for Gnome, I think it is fair to say that the main focus is high quality on Linux while other platforms are somewhat second-class citizens. This is probably most visible by looking at the integration with the native look and feel of Windows and MacOS. If you are looking for a toolkit which behaves equally well on all major platforms, I'd recommend you reconsidered Qt.
As far as your more specific questions are concerned:
C/C++
Gtk is written in C, and consequently has a C API. If you are looking for a C++ API, look at the Gtkmm bindings. Note that you can also use the C API in a C++ application.
glibconfig.h
I don't know whether you tried compiling Gtk yourself, but the easiest way to get Gtk3 for windows is by downloading the precompiled all-in-one bundle from http://www.gtk.org/download/win32.php (which includes the glibconfig.h you are missing).
When and how to use Gtk and with what language
As pointed out above, the primary users oft Gtk are people who develop applications for the Gnome desktop environment. Most cross-platform applications nowadays however use Qt since the quality on Windows and MacOS is higher compared to Gtk on those platforms.
Concerning what langauge to use, a strength of Gtk is that there exists bindings for many languages (including C++ and Python), so you are certainly not confined to C.
When developing with C++, something that I personally like about Gtkmm is that it uses the standard library, as opposed to Qt which has it's own implementations for data structures etc (the reason being that Qt predates the times when the STL was generally available and usable on all main platforms).
How to use Gtk: contrary to Qt which has the excellent Qt Creator, Gtk is somewhat lacking a specifically designed IDE for easy development. The closes you'll get is using Glade for interface design and a text editor or IDE of your choice for the coding, but that choice will differ depending on the platform you are on. Clearly, as you probably noticed, integrating Gtk into the environment of choice usually requires some work (and also some more technical knowledge). So again, if you are looking for an easy to set-up and use environment for developing GUI applications, I'd just go with Qt and Qt Creator.
Cross-Platform apps
First off, Visual Basic is not cross-platform. But generally speaking, there are plenty of possibilities for doing cross-application development, using various languages.
I've had to get a gtk3 project working on windows a few months ago, when gtk3 just came out for windows. I've had problems compiling it under Visual Studio as well, and posted a question here, specifically this one.
Here's how I got it working on windows:
Download the all-in-one bundle for Windows from gtk.org
Install, etc, set up include/link dirs within the project. (personally, I dumped gtk's folders in the project folder, pointed at "include" as an include dir and "lib" as a link dir, then proceeded to move any files/folders the compiler cannot find around to the root of "include" )
If not set up automatically, add include and link dirs as necessary until the compiler finds all the files.
If using MinGW to compile, it will succeed at that point.
If using Visual Studio, you have to modify gtk headers as described in the gtk mailing list:
In gutils.h lines 82 and 122, and in gstring.h line 129, change
"static inline" to "static __inline".
Blockquote
Note that the modification does not impact MinGW's ability to compile.
I have successfully compiled my gtk3 project on both windows (with either Visual Studio or Code::Blocks) and linux without writing platform-specific code that way. Just don't forget to include the required runtime dlls with the program when you ship it.
A group of students and I are making a C++ game, but they have Windows and I have a Mac is there something we can use to share code between the systems?
I know Eclipse will work but I get Unresolved conclusion: <iostream> as an error. If anyone can help with that it would be great.
If you want something to actually "share the code" with, I would recommend git using github as the remote location. Its free and easy to use.
If your question is about the code not working, make sure you have X11 configured properly, and have the Eclipse C++ plugin installed.
And I would also recommend using XCode as your editor instead of Eclipse. It has a much better environment for C++, IMHO.
Hope this helps.
Personally I'd recommend setting up a cross-platform build process using something like CMake (http://www.cmake.org). CMake in particular will generate platform-specific project files for you -- so your friends could be working in Visual Studio and you could be working in Eclipse or XCode, with no problems at all (of course, you'd have to write portable code... :))
As far as sharing code and version control goes, I agree with Jon that something like git is ideal.
We build our Windows+Mac+Linux apps using Qt, which includes a nice build system (qmake) and cross-platform APIs (so the same code will run on all OS's) and an IDE (which I haven't used but I hear is okay).
With multiple developers you'll definitely want some sort of source-code-management system as well, git and svn are both good choices there.
I want to port wxwidgets opengl application that will be not library dependent.I want at least that it can be compiled without additonal libraries. I am thinking to port it to MFC or maybe WIN32.What is the most easiest?Maybe you have some other suggestion?
MFC is by far the easiest. It's also the only realistic option if you don't want to use libraries that aren't installed with Visual Studio.
You do realize, that MFC is just another library and works much like wxWidgets. The only difference is, that MFC ships with Visual C++. However if you were to compile with GCC (MinGW), then you'd have to obtain MFC somehow.
Also the whole boilerplate code for event handling and the like is rather prone to write. I say: Stick with wxWidgets, it's cross plattform, well supported and if you're scared by installing and using libraries, then you should not do programming.
Although one answer is already checked, taking the question the way it was worded, the answer is wrong. MFC is just an other dependency, although shipped with Visual Studio. You still need to ensure that the correct version is installed on the users system. The only real way to solve this problem is to go Win32 with WGL. Then you depend on nothing but OS libraries. (You probably still need to install the vcredist package though...)
I wanted to create a cross-platform 2D game engine, and I would like to
know how to create a cross-platform project with Makefile, so I can compile it to the platforms I choose with custom rule for any platform.
I'm working on the windows enviroment with Visual C++ Express 2008, so it would be nice
if I can use Visual C++ Express as the IDE.
My platforms are YET the Nintendo DS and the PC.
Please instruct me what to do.
Thanks in advance, Tamir.
Don't use make, use a cross-platform tool like cmake, it will take care of the platform-specific generation for you. Like on Windows, it will generate the project files to use Visual Studio; on Linux, it will generate the GNU make files for you. You can set it up to find the right versions of the right libraries and everything. Cmake is great.
CMake is not a compiler (neither is make) - it is a cross-platform build automation system. It allows you to develop on any platform and it defaults to assuming you're developing for the platform you're running. You can specify parameters if you want to do other things. However, most of the "cross-platform" stuff is still left to your code. I would also recommend a library that has been tested on many platforms, like Boost. Using Boost can help keep all your code working smoothly on any system and there is basically no overhead to using it.
I know you can use Makefiles to do #defines, which is, in turn, a common trick for swapping out chunks of code. There are also ways to detect the platform, although that's mostly for Mac/Windows/Linux differences.
Also, Travis is probably right; having your makefiles themselves be cross-platform is really excellent, since it's easier to then setup build servers and things.
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.