This is beyond depressing. I can't get started with OpenGL because linking the c++ libraries feels like a university course in itself. Im using cmake

I installed assimp, free type, glfw3,glm from homebrew. How do I link those?

For glad and imgui which i got off the internet, how do I link?

cmake_minimum_required(VERSION 3.2)

set(CXX_STANDARD 20)
set(CXX_STANDARD_REQUIRED true)


project(3dmod VERSION 1.0.0
            DESCRIPTION "First OpenGL"
            LANGUAGES CXX)

CMAKE_PREFIX_PATH(/usr/local/opt)

find_package(glfw3 CONFIG REQUIRED)
find_package(glm CONFIG REQUIRED)
find_package(glad CONFIG REQUIRED)
find_package(assimp CONFIG REQUIRED)
find_package(imgui CONFIG REQUIRED)
find_package(freetype CONFIG REQUIRED)

add_executable(${PROJECT_NAME} main.cpp glad.c)

#target_link_libraries(${PROJECT_NAME} PUBLIC glfw3::glfw3)
#target_link_libraries(${PROJECT_NAME} PUBLIC glm::glm)
#target_link_libraries(${PROJECT_NAME} PUBLIC glad::glad)
#target_link_libraries(${PROJECT_NAME} PUBLIC assimp::assimp)
#target_link_libraries(${PROJECT_NAME} PUBLIC imgui::imgui)
#target_link_libraries(${PROJECT_NAME} PUBLIC freetype::freetype)

include_directories(/usr/local/include)
link_directories(/usr/local/lib)

CMake is mostly useful if you want to have cross-platform support. If that is not needed, I'd suggest to just use what your compiler provides.

I don't know about homebrew, but for Linx (gnu g++) you use -L and -l options. The former specifies a search path for the library(ies), the latter the library to link to.

If you have a “/some/where/libXYZ.so” library file, it's something like “g++ -o myexe program.cpp -L/some/where -lXYZ”. Likely you want to set some optimization flags etc too, eg -O2 for g++

• Order of mentioning libraries (the -l options) matters. Some libraries use other libraries. The latter should be mentioned after the former so all references are resolved.
• Standard library paths are known by the compiler, so if the library is located there, no need for -L.
• Usually,there are several libXYZ….so files, with version numbers. These files are usually all soft-linked to the same library file. It gives you the option to specify how precise you want the version to match.

Simplest is to stick the entire compile process in a shell script, eg

#!/bin/sh

set -e -u -x

CCFLAGS="-Wall -g"
FLEXFLAGS=

bison --defines=tokens.h --output=parser.cpp parser.y
flex $FLEXFLAGS --outfile=scanner.cpp scanner.l

g++ $CCFLAGS -c -o parser.o parser.cpp
g++ $CCFLAGS -c -o scanner.o scanner.cpp
g++ $CCFLAGS -c -o encode.o encode.cpp
g++ $CCFLAGS -c -o ast.o ast.cpp
g++ $CCFLAGS -c -o image.o image.cpp
g++ $CCFLAGS -c -o output.o output.cpp

g++ $CCFLAGS -o encoder parser.o scanner.o encode.o ast.o image.o output.o -lpng

bison and flex are two code generators so they run before compiling. Then it compiles each cpp file to an .o file, and links it all at the last line with libpng.so I use “mk” as name for such a script, and make it executable, so I can type “./mk” to get a build.

Alternatively, you can do everything in one g++ command line. It's just like the last line, except with “.cpp” instead of ".o" (and no need for “g++ -c” lines then).

Such a script is simple but it compiles every cpp file each time, and runs only one g++ at a time, while you can compile .cpp to .o in parallel. As your program grows, this may become a nuisance. This is where a Makefile can help, but that is a different topic 🙂

EDIT: Some libraries come with a pkg-config setup, which saves you the trouble of figuring out how to compile and link exactly., You may run into these. See also

https://stackoverflow.com/questions/20416956/what-is-the-significance-of-pkg-config-in-gcc

This is not the kind of problem that rewards theory or preparation. You should focus on concrete problems: try to link your program, obtain a terrible error message, look it up, edit your CMake configuration and try again. As long as you get new error messages you are making progress.

General advice:

• Alberth describes the correct end result: library search paths in -L options and library names in -l options matching, respectively, locations and filenames of library files in actual use.
  To ensure that these options are set appropriately, you need to inspect the actual command lines created by CMake. Don't waste time trying to compile your program blindly.
• The find_package command of CMake is expected to add libraries and library search paths to the appropriate compiler options. Does it work correctly for each library in use?
• You can try compiling existing software that uses CMake and has more or less the same dependencies; hacking your paths and filenames into a working cmakelist.txt should be easier than starting from a blank page,

My experience with build systems for C++ is that they all suck, but as a meta build system, CMake sucks twice over.

To make some token effort at actually solving your problem: why are those target_link_libraries lines commented out, and what happens if you remove the ‘#’ from the beginning of those lines?

This is the updated CMakeLists.txt

cmake_minimum_required(VERSION 3.19)

# THIS HAS TO COME BEFORE THE PROJECT LINE
set(CMAKE_C_COMPILER "gcc")
set(CMAKE_CXX_COMPILER "g++")
# THIS HAS TO COME BEFORE THE PROJECT LINE
SET( CMAKE_CXX_FLAGS_DEBUG  "")
SET( CMAKE_CXX_FLAGS_RELEASE  "")
SET( CMAKE_CXX_FLAGS  "-Ofast -DNDEBUG -std=c++20 -march=native -fpic -ftree-vectorize")

project(ogle VERSION 1.0.0
            DESCRIPTION "Our first project" 
            LANGUAGES CXX)

set(CXX_STANDARD 20)
set(CXX_STANDARD true)
set(INCLUDE_DIRECTORIES ${PROJECT_SOURCE_DIR}/include)

# find_package(glfw CONFIG REQUIRED)
find_package(glm CONFIG REQUIRED)
find_package(assimp CONFIG REQUIRED)
find_package(PkgConfig REQUIRED)
pkg_check_modules(freetype2 REQUIRED IMPORTED_TARGET freetype2)
pkg_check_modules(glfw3 REQUIRED IMPORTED_TARGET glfw3)
pkg_check_modules(glew REQUIRED IMPORTED_TARGET glew)

add_executable(ogle imgui_demo.cpp 
                        imgui_draw.cpp 
                        imgui_impl_glfw.cpp
                        imgui_impl_opengl3.cpp
                        imgui_tables.cpp
                        imgui_widgets.cpp
                        imgui.cpp 
                        glad.c
                        main.cpp
                        )

target_link_libraries(ogle PUBLIC PkgConfig::glfw3 PkgConfig::glew glm::glm PkgConfig::freetype2 PRIVATE assimp::assimp)

The error

/Users/baguma/desktop/graf/main.cpp:4:10: fatal error: 'GL\glew.h' file not found
#include <GL\glew.h>
         ^~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/ogle.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/ogle.dir/all] Error 2
make: *** [all] Error 2

The thing is, glew was found. I saw it while setting up the makefile with cmake. So why would I still get this error.

I'm using vscode on mac because system is too old. 2015 MBP 13" and Xcode isn't supported.

bhvrbhrr said:
2015 MBP 13" and Xcode isn't supported.

Depending on your OS, you can download old versions of xcode from the apple developer website (get the one tied to your OS version). Personally I do most development in OS 10.8.5 from 2013, using an xcode version 3.2.2 from 2008 (it was the last good one).

@Aressera I have gone to the website where that used to be possible. Looks like apple scraped it.

Only other option would have been to download it from the app store if I previously purchased it. It would then download the latest supported version for my os(i think) but option is also closed because this is my first MB which I got last year

bhvrbhrr said:
I have gone to the website where that used to be possible. Looks like apple scraped it.

I just checked, you can find all old versions here: https://developer.apple.com/download/all/

@Aressera I'm seeing Xcode 15 only

bhvrbhrr said:
I'm seeing Xcode 15 only

That's weird, did you press the “show more” button at the bottom? I had to press it a few times to see older stuff. The other (pretty evil) possibility is that Apple only provides old downloads to older developer accounts.