I'm learning to use the Codeblocks editor and I would like to setup a SDL2 project. My question is about the necessary files in the SDL2 package.
In the bin directory there is:
sdl-config
In the lib directory there is:
directories -
cmake and pkgconfig
In the share directory there is:
aclocal
I deleted these files, but my experience with SDL2 and C++ is almost at a beginner level. My understanding is, that these support files are for various command line tools used for compilation. For example I know what pkg-config is and I searched somewhat for the other file types. Is it ok to delete these files since I am using Codeblocks, or will Codeblocks possibly require any of these in some unexpected way at a later time? that I might not have considered. As far as I know, Codeblocks makes full use of it's wizards and it's project handling is separate from these other tools. I basically like to set everything up as an Empty Project. I have no compilation issues or errors, but I wanted the opinion of someone more experienced on this.
Related
I haven't programmed for a while and am trying to set up my build environment on a new laptop. I've just forgotten how and think that I did allot of things wrong last time!
What I'm trying to do is have that common Include Directory and common Lib directory so when I build projects or other dependencies, etc... my compiler is able to find all the include and lib files it needs. I'm not formally trained so some obvious things to you guys are learning points for me.
I'm going to use a Mingw compiler and MSYS. Off memory I put the Include directory and the lib directory in the Mingw directory but I could be wrong there.
I'm just trying to set up an effective and simple build environment on Windows 7.
Where should all my directories go? Thanks
If you aren't already, MSYS2 is generally preferred over MSYS. I'm going to answer this assuming MSYS2. I use the 64 bit version, so that is what I'll show, but it should be simple enough to change.
I will also assume you put the msys64 directory in the base directory, if not replace C:/msys64/ with C:/wherever/you/put/it/msys64/.
When using the msys shell, /c/msys64/usr/ is the same as C:/msys64/usr/ which is the same as /usr/ since it tries to blend Linux file organization with windows, and it can sometimes be slightly unintuitive. When you install msys libraries, usually the include files are in C:/msys64/usr/include/ and the libraries are in C:/msys64/usr/lib/. The exception to this is when you have a 64-bit version and a 32-bit version of a program, in which case the headers are in C:/msys64/mingw64/include/ and the libs in C:/msys64/mingw64/lib/ for 64-bit (mingw32 for 32 bit).
In order to build using these, you will need to add the appropriate include paths and library paths. So, to make all 64-bit programs available, you would add the following flags
-IC:/msys64/usr/include -IC:/msys64/mingw64/include -LC:/msys64/usr/lib -LC:/msys64/mingw64/lib
When you compile your own programs from source, you put them wherever you'd like. It is best not to put them in the same directory as the package manager to avoid collisions. Running make install sometimes won't run as seamlessly on msys as it would on linux. In these cases, creating a folder such as C:/msys64/custom/include/ is a safer alternative. See https://unix.stackexchange.com/questions/30/where-should-i-put-software-i-compile-myself for some more insight on this.
So I got into a problem where I needed to use linux for a while instead of windows, and figured linux doesn't have Visual Studio. I then also realized that I made my project Visual Studio only, which I don't want.
So I looked up some CMake tutorials and try'ed creating some examples that could be loaded in both Visual Studio and CodeBlocks. When I got that to work, I went and code a CMake script for my actual program by piecing together what I learned and what I found in tutorials.
See here:
cmake_minimum_required(VERSION 2.8.9)
add_subdirectory(libraries/glfw)
project (OpenGLEngine3D)
include_directories(libraries/glfw/include)
include_directories(libraries/glm)
include_directories(libraries/glad/include)
include_directories(libraries/whereami/src)
include_directories(libraries/stb)
file(GLOB SOURCES "src/*.cpp" "src/*.h" "libraries/whereami/src/whereami.c" "libraries/glad/src/glad.c")
add_executable(OpenGLEngine3D ${SOURCES})
target_link_libraries(OpenGLEngine3D glfw)
Its dirty(I think) but it works.
So now my first question is, how to improve my CMake script? What is redundant or done in a poor way?
Now my program also requires some resources(like shaders, textures) which I have stored in a directory along with my CMake script, libraries and c++ files.
So my second question is, how would I tell CMake to the ide/compiler to copy the files in a certain directory to the program build directory(where the compiled binaries are) after compiling?(And have it only do it when the files aren't there ofc.)
Thanks!
I recently came across this article, which might be help you with CMake.
Here are a couple suggestions from me:
You're safe to use newer version of CMake. Currently, it's 3.11. There's no point in sticking to old versions.
Consider listing all your sources in a variable (using set command) instead of using file(GLOB). file(GLOB) will be evaluated only once, when generating build files. If you add new sources, you'll have to re-generate it manually, so it doesn't help too much, and is harder to debug (and really, debugging more complex CMake projects can be painful).
Avoid using include_directories (and link_libraries). Prefer using target_include_directories which works per-target. It allows to express dependencies between targets (when you have more than one - which might happen as your project grows)
You might consider using find_package(GLFW), instead of including GLFW in your project. Edit: actually, CMake doesn't came with find module for GLFW, but you can use an external module for this (e. g. this one) as described here.
Edit:
Example below illustrates the idea behind point 2), assuming that sources are placed in "src/" directory on the same level as CMakeLists.txt file:
set(engine_sources
"src/header_1.hpp"
"src/source_1.cpp"
# and so on for reset of files...
)
add_executable(OpenGLEngine3D ${engine_sources})
As for the second question: that's what file(COPY) command is for. Alternatively, you could just leave assets in source directory, and set working directory in IDE.
Side note: if you choose the second options, there appears to be a way to set this from CMake for Visual Studio, by setting VS_DEBUGGER_WORKING_DIRECTORY property:
set_target_properties(OpenGLEngine3D PROPERTIES VS_DEBUGGER_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
(I haven't checked if this works as expected, as I rarely use VS. I remember looking for something like that in the past, and just recently came across it.)
I am facing a really for me time-expensive problem. I am new to ubuntu and want to start learning more about opengl by using the glfw. Of course I cannot switch the OS so I will have to stay at ubuntu. I have come so far that I installed the glfw( by following this "tutorial": 2. step by filipwasil), so I have got an include directory in the usr/local dir, aswell as a lib directory. The include directory contains the glfw3.h and the lib directory the libglfw3.a file. If I try to add them to my project in code::blocks it seems like only the include part works, because I can see the functions provided by the glfw while typing, but once I want to compile and run the project, I get an error for each glfw function call: like "not defined reference to e.g. glfwInit". The lib directory also contains a cmake dir, which contains glfwconfig and glfwtarget files, but I really do not know what these files should do. I also noticed the question by Artur, which is quiet identical, but it does not help me because I want to know which files exactly I have to add in order to get a running window. So may question is: How is it possible to make the code::blocks IDE, actually the gcc compiler, know whats behind the glfw functions?
Every help will be appreciated. Sorry for my bad english. :)
Add GL, GLEW and glfw in the linker settings. Note the "glfw" in lowercase
I'm having a problem linking SDL_ttf library with C++ compiler. I have tried three different programs and i couldn't solve the problem in any of them. I've tried Dev C++, Eclipse and CodeBlocks. In all of them it appeared a different error, but all related to not finding -lSDL_ttf or not recognizing the functions of that library.
I'm following this tutorial http://lazyfoo.net/SDL_tutorials/ and have done everything i have found on the internet. I copy the .h file inside /include/SDL/ directory, the .dll files inside the project directory, and the files within /lib directory into the /lib directory that i am using. I think the error might be here, as SDL_image for example, have ".lib" files, and in ttf there is no such file. They are all ".a" or ".la". I'm new to C++ so i don't know if i am doing something wrong.
Thank anyone for his help.
The error in code blocks is the following:
ld.exe cannot find -lSDL_ttf
Make sure you downloaded the correct version of the library. If you have ".a" files, you probably downloaded the mingw version. And for that you have to use a mingw compiler. If you are using something like Visual Studio, you need the version with -VC.zip at the end.
Hope it was useful.
Good coding ;-)
I currently have a project, written in C++, it uses multiple libraries, including an sqlite and a wxWidgets library, it has a Graphical User Interface, made with Interface Builder.
This project was made with Code::Blocks.
What I now want to do, is import this whole project into XCode to make an .app file. I know about linking and search paths and all that (learned how to do that with a Command Line Project), but other then that, I don't really know where to start. I have searched a lot of forums but it's driving me crazy.
Can anybody help me out with a step-by-step of some sort?
Thanks!
Steps taken
wx-config --cppflags
wx-config --libs
Opening a new xcode project (cocoa)
Pasting the code written (all the classes, and the interface built)
Organizing the header search paths (including the output of libs)
Organizing the linking
Organizing the GCC other flags (including the output of cppflags here)
after that it worked.