Match CMakeOptions.txt options default values

[ghost]

No description provided.

[orcmid]

I am in no position to assess the wisdom of that.

However, an alternative is to simply have those in CMake as previously specified but to also define EXTERNAL_CONFIG_FLAGS in that list. The CMake ON setting will go through and for the OFF (unset?) ones, whatever the files do in the absence of config.h and particular CMAKE setting will kick in.

I have no idea what kind of edge cases/holes might sneak in with that approach, though.

I think the expectation is that if neither CMAKE (nor command line) nor config.h are used to turn on a preprocessor var, files will detect what definitions have not been provided and automatically establish the official defaults stated in the (default) config.h file. That's much to check/test though.

[orcmid]

If you remove the CMakeOptions.txt from CMake, config.h will be used always and that is then the one place to make changes, whether using make or CMake. I think that is what Ray has in mind for it all to work.

Ultimately, if you want to change those choices, you have to change something in the installed raylib library. It seems that is what config.h is for.

config.h probably needs to be in a .gitignore in the raylib repo but it gets tricky how to have it be distributed in a release and in a fork. It can be done, but it means the user-changeable config.h needs to be copied from a different default value, such as a config.h.default. That's the only technique I have managed to use that prevents poisoning a clone/fork.

That makes things a little trickier for neophytes though. It does seem better than having these mysterious conflicts between CMake and make builds and other problems with "poisoning" CMakeOptions.txt instead :).

[orcmid]

I think I have misled you somehow. My suggestion is that CMakeOptions.txt be removed from the raylib CMake, in the raylib repo. That way, there will be no conflict with config.h which should be left as-is.

There's also something that needs to be done about documenting config.h and how an user can modify that in the way that Ramon intends. I guess if an user does that from a raylib fork/clone, they need to do it in a branch that is never pushed, so the raylib repo does not become polluted. If installation of raylib is from a source release, no problem.

I mentioned other safeguards that can be done instead, but that may be too complicated.

[raysan5]

@asdqwe thanks for the review, alighning CMakeOptions.txt with config.h is a good start.

If you remove the CMakeOptions.txt from CMake, config.h will be used always and that is then the one place to make changes, whether using make or CMake. I think that is what Ray has in mind for it all to work.

I don't maintain the CMake build system but it think keeping a CMakeOptions.txt available to modify build options is the simples option for CMake users, instead of directly editing a source code file. Personally, I use similar approaches with Makefile (gcc) and Directory.Build.props (VS2022) build files... and that was the best solution I found.

The problem with those mechanisms is that they could be miss-aligned easely... but still, that's ok, build configuration is up to the user, independently of default values.

I'm also considering to reduce the number of build options, just noticed that some options are always required and the overhead added is really minimal (i.e. compress/decompress functionality).

[raysan5]

@asdqwe Yeah, those flags should be added to CMakeOptions.txt. Feel free to send a PR with that addition.

Please note that I'm not the maintainer of CMake build system, it was added for convenience by some user. Consequently, it could not be so regularly updated like the other available build systems that I manage (Makefile, Visual Studio projects).

[orcmid]

I think I've said this already, but I'll try one more time.

Anything CMake does not set will be handled by config.h. The config.h header plays nice and only introduces its settings for preprocessor macros that are not already defined. That also works no matter what build system is used. There is a preprocessor variable, that if set in CMake, suppresses all use of config.h.

I recommend that config.h be the file of choice for varying the particular settings. And if it is awkward editing something from a raylib release, then set up a build in a way that introduces settings different from those that config.h defaults in some way that does not involve altering files of the raylib src release, whether config.h or CMake.

The problem with this CMake/config.h duality it puts beginners at risk of an IED trap when a modification to config.h doesn't change anything and it is not understood that CMake has trumped it.

Most of all, I think there needs to be more understanding of config.h and how it can be over-ridden from afar. I'm not the one to do that unless Ramon thinks that is a good direction to take.

[raysan5]

@orcmid I think it should probably be better documented, but, in any case, users tweaking it (or the related build options) should be advance users with some knowledge of build systems.