4 ms·

I have one question to ask you. How do I do this in Make: find_package(OpenGL) target_link_library(app OpenGL::OpenGL) Goals: - Support Windows, ma

by jchw 4y ago

I have one question to ask you. How do I do this in Make: find_package(OpenGL) target_link_library(app OpenGL::OpenGL) Goals: - Support Windows, macOS, *NIX like - Compile with either MinGW or MSVC on Windows - Decent error output if GL headers are not found This SHOULD be possible. All we are doing here is calling the compiler with a fairly easy to derive set of options. Yet, in Make, there is no ideal way to abstract this. Even detecting platforms can be annoying, less trying to abstract the differences between them. I do not find Make hard to use. I do not lack knowledge on how to use Make, or not understand the "zen" of Makefiles. I just know that `-lGL` is a terrible answer to this question. And I find Make to be generally bad for compiling software. Out of tree builds and reasonable platform detection generally require configure scripts, at which point we've thoroughly left any semblence of elegance.

hedora 4y ago
You should either trust the OS to package GL, or vendor it yourself. If you trust your build environment, then -lGL is the right answer. If you do not, then vendoring libGL is the right answer. Both approaches are easy to achieve with make. find_package semantics are frankly weird: "maybe use the OS version, or override in nonstandard ways, or maybe download some version from somewhere and build it using some compiler flags that came from somewhere mysterious. If you succeed, have package-dependent side effects on the set of global variables in my cmake script". Does it have a higher chance of producing a binary in dodgy environments? Sure. Are those binaries actually reproducible or what the developer / distribution tested with? Absolutely not. As for windows with visual studio: Either point make at the visual studio compiler, or hand maintain a separate .SLN file. The impedance mismatch between Unix and Windows builds is too great, and the auto-generated .SLN files that tools like cmake produce are low quality.
- jchw 4y ago
  This is the perfect non-answer. The question I asked is simple. CMake has an answer. Make has more questions.
chlorion 4y ago
If you are targeting a GNU/Linux system and possibly other Unix like systems you can use pkg-config for this. All of the mainstream Linux distros support and use pkg-config, but I'm less sure about the BSD systems and MacOS since I've never used those before but from what I gather it should work for them too. Most Windows users probably don't have pkg-config installed but I also am not familiar with Windows. Anyways if you are targeting platforms that support it, pkg-config will automatically generate the required flags for you, you can append them to a variable however you like, and later pass that variable to the compiler and linker. You can try this out in a shell session if you are curious, try running: pkg-config gl --cflags --libs You can see what libraries it knows about by running: pkg-config --list-all Even when not using make directly a lot of build systems will be using pkg-config "under the hood"! Cmake is an exception here and has it's own way of doing this, but you can configure it to use what you want. Just to be clear I am not saying makefiles are good or bad or what you should use, I just wanted to mention pkg-config because it's pretty cool and useful to know about. The real answer to your question is to just use cmake I think!
- jchw 4y ago
  This is basically the best way I've seen to do this with pure Make, though I don't think it will work on macOS or even MSYS2 because even if you install pkg-config I don't think anything will provide definitions for OpenGL. (That's part of the reason I picked it; OpenGL is a really annoying edge case, since every platform went about it a little differently, and yet it is a common thing to need to link to.)
padf 4y ago
The trouble is not supporting all the different Operating systems/compilers, as make can do that. The issue is when the OpenGL library location varies, even on the same OS/compiler set.
- jchw 4y ago
  It's kinda both. The problem is that it doesn't really make sense to do all of this work to configure the build directly in Make, so if you need any kind of expensive detection (like calling pkg-config or testing if some library function is available) it's best to do it in a configure script. Most projects don't have terribly special needs, so it would be both overkill (too much effort) and insufficient (not supporting enough use cases) to do a lot of custom configuration code. So most projects wind up using something like Autoconf, which has already done a ridiculous amount of work to work on almost everything, supporting important use cases like out-of-tree builds and cross-compilation, but even then it has some unfortunate limitations. As much as I don't think CMake is elegant or perfect by any means, CMake is nice because it does work, and there generally is a proper way to do things even if it's not always intuitive. And for how bad it can be, honestly, it's much less of a pain in my opinion than dealing with autotools, for many reasons. Just to be concrete about it, one thing I find really painful with autotools is trying to find the exact combination of versions that will actually work with a given project... With CMake, usually newer versions are always OK, and there's a decent focus on both backwards compatibility as well as explicitly declaring the required CMake version. There's more, but it's probably not worth getting into, as I don't think most people defend autotools as being particularly nice to use. Some projects, like the Linux kernel, can definitely get away with Make and custom configuration, since a lot of higher-level general purpose tools are not really well-suited for their needs anyways. I feel like most projects (somewhere on the order of >99% of them) are not really in this boat.

by jchw 4y ago

hedora 4y ago

You should either trust the OS to package GL, or vendor it yourself. If you trust your build environment, then -lGL is the right answer. If you do not, then vendoring libGL is the right answer. Both approaches are easy to achieve with make. find_package semantics are frankly weird: "maybe use the OS version, or override in nonstandard ways, or maybe download some version from somewhere and build it using some compiler flags that came from somewhere mysterious. If you succeed, have package-dependent side effects on the set of global variables in my cmake script". Does it have a higher chance of producing a binary in dodgy environments? Sure. Are those binaries actually reproducible or what the developer / distribution tested with? Absolutely not. As for windows with visual studio: Either point make at the visual studio compiler, or hand maintain a separate .SLN file. The impedance mismatch between Unix and Windows builds is too great, and the auto-generated .SLN files that tools like cmake produce are low quality.

jchw 4y ago
This is the perfect non-answer. The question I asked is simple. CMake has an answer. Make has more questions.

chlorion 4y ago

If you are targeting a GNU/Linux system and possibly other Unix like systems you can use pkg-config for this. All of the mainstream Linux distros support and use pkg-config, but I'm less sure about the BSD systems and MacOS since I've never used those before but from what I gather it should work for them too. Most Windows users probably don't have pkg-config installed but I also am not familiar with Windows. Anyways if you are targeting platforms that support it, pkg-config will automatically generate the required flags for you, you can append them to a variable however you like, and later pass that variable to the compiler and linker. You can try this out in a shell session if you are curious, try running: pkg-config gl --cflags --libs You can see what libraries it knows about by running: pkg-config --list-all Even when not using make directly a lot of build systems will be using pkg-config "under the hood"! Cmake is an exception here and has it's own way of doing this, but you can configure it to use what you want. Just to be clear I am not saying makefiles are good or bad or what you should use, I just wanted to mention pkg-config because it's pretty cool and useful to know about. The real answer to your question is to just use cmake I think!

jchw 4y ago
This is basically the best way I've seen to do this with pure Make, though I don't think it will work on macOS or even MSYS2 because even if you install pkg-config I don't think anything will provide definitions for OpenGL. (That's part of the reason I picked it; OpenGL is a really annoying edge case, since every platform went about it a little differently, and yet it is a common thing to need to link to.)

padf 4y ago

The trouble is not supporting all the different Operating systems/compilers, as make can do that. The issue is when the OpenGL library location varies, even on the same OS/compiler set.

jchw 4y ago
It's kinda both. The problem is that it doesn't really make sense to do all of this work to configure the build directly in Make, so if you need any kind of expensive detection (like calling pkg-config or testing if some library function is available) it's best to do it in a configure script. Most projects don't have terribly special needs, so it would be both overkill (too much effort) and insufficient (not supporting enough use cases) to do a lot of custom configuration code. So most projects wind up using something like Autoconf, which has already done a ridiculous amount of work to work on almost everything, supporting important use cases like out-of-tree builds and cross-compilation, but even then it has some unfortunate limitations. As much as I don't think CMake is elegant or perfect by any means, CMake is nice because it does work, and there generally is a proper way to do things even if it's not always intuitive. And for how bad it can be, honestly, it's much less of a pain in my opinion than dealing with autotools, for many reasons. Just to be concrete about it, one thing I find really painful with autotools is trying to find the exact combination of versions that will actually work with a given project... With CMake, usually newer versions are always OK, and there's a decent focus on both backwards compatibility as well as explicitly declaring the required CMake version. There's more, but it's probably not worth getting into, as I don't think most people defend autotools as being particularly nice to use. Some projects, like the Linux kernel, can definitely get away with Make and custom configuration, since a lot of higher-level general purpose tools are not really well-suited for their needs anyways. I feel like most projects (somewhere on the order of >99% of them) are not really in this boat.