Match CMakeOptions.txt options default values

[asdqwe]

Hello,

Some options default values on CMakeOptions.txt do not match their default counterparts on config.h as illustrated on the table below:

Option	config.h	CMakeOptions.txt
SUPPORT_SSH_KEYBOARD_RPI	ON	OFF
SUPPORT_WINMM_HIGHRES_TIMER	ON	OFF
SUPPORT_FILEFORMAT_PNM	OFF	ON
SUPPORT_FILEFORMAT_KTX	OFF	ON
SUPPORT_FILEFORMAT_ASTC	OFF	ON
SUPPORT_FILEFORMAT_GIF	ON	OFF
SUPPORT_FILEFORMAT_QOI	ON	OFF

Assuming that a) compiling with make or cmake should have equivalence, and b) the default values on config.h are the correct ones, this pull request flips them on CMakeOptions.txt to match those on config.h.

I apologize in advance if that is not the case and there are underlying reasons for the divergence.

Best regards.

[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.

[asdqwe]

Hello @orcmid

Thanks for the reply!

The issue this pull request meant to address was that while compiling directly with make it uses the config.h default defines (if nothing is changed by the user). But while compiling with cmake it would end up using the CMakeOptions.txt default defines (if nothing is changed by the user). Therefore causing different build results for, effectively, the same task, since those defines differ (as illustrated on the previoust table).

For example, it did not made sense to me that while compiling with make I would end up with SUPPORT_FILEFORMAT_GIF, but while compiling with cmake I wouldn't, exactly because the defaults are different.

Since all other defines match on both, it seemed like the most logical solution would be to make CMakeOptions.txt have the same default values as config.h, thus ensuring the same default build result for both (if nothing is changed by the user). A rework of the cmake current operation is not in the scope of this change.

Best regards.

[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 :).

[asdqwe]

Hello @orcmid

Thanks for the reply!

In my opinion, I don't think it's expected that the user would remove files from the distribution. Neither that a user (specially a new user) would create a config.h from scratch, given the size, complexity and amount of options there.

None of those things are in the scope of this pull request.

All I wish is that the defaults match, so it won't accidentaly cause different default built results. I have no intent to change anything in the build system/structure in any way.

Best regards.

[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.

[asdqwe]

Hello @orcmid

Thanks for the reply!

Oh, I see. Well, I guess that level of change is "above my pay grade". I'm just after that small fix at the moment.

Best regards.

[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).

[asdqwe]

Hello @raysan5

Thanks for the reply and explanation!

I know you mentioned reducing the number of build options, but I noticed a few missing on CMakeOptions.txt that appear to be relevant for the user configuration:

Option	config.h
SUPPORT_FILEFORMAT_M3D	ON
SUPPORT_FILEFORMAT_QOA	ON
SUPPORT_FILEFORMAT_PIC	OFF
SUPPORT_EVENTS_AUTOMATION	OFF

I can send a pull request to add those, if that's ok.

Best regards.

[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.