cmake

[rapgro]

Please provide support for cmake. Attached a sample CMakeLists.txt as used currently in Fedora.

cmake_minimum_required (VERSION 2.6)
project (Stockfish)

set(EXE stockfish)

include_directories(${PROJECT_SOURCE_DIR}/syzygy)

aux_source_directory(. SOURCES)

add_executable(${EXE} ${SOURCES} syzygy/tbprobe.cpp)

target_link_libraries(${EXE} -lpthread)

[mcostalba]

Not an issue. Closed.

[jubalh]

@rapgro What would be the gains of switching to cmake from the existing make?

[rapgro]

@jubalh Please compare complexity of my proposed CMakeLists.txt file above and the internals of a manually written Makefile. CMake does generate Makefiles and cares about automated configuration.

[tristntran]

Sorry for the post necromancy, but I think that we should reconsider cmakes. It seems like cmake has become the new standard for builders and software like CLion heavily favors it for debugging as makefile does not play nice with their gdb and runtime configurations. In order to grow and pass knowledge onto more contemporary programmers, we should consider updating our tools as well.

[bftjoe]

Considering the maintainers didn't even want to commit to integrating cmake support when someone was willing to and did do all the work, good luck with that.

#3012

[ppigazzini]

Considering the maintainers didn't even want to commit to integrating cmake support when someone was willing to and did do all the work, good luck with that.
#3012

My opinion after reading that thread:

• the maintainers were interested to cmake:
  Port to using CMake. #3012 (comment)
• that PR mixed 2 things: adding cmake and making a static library
• the contributor never completed the work on the PR

[bftjoe]

I suppose if you call full cmake support including PGO "unfinished", then sure.

…

On Sat, Mar 5, 2022, 11:29 AM ppigazzini ***@***.***> wrote: Considering the maintainers didn't even want to commit to integrating cmake support when someone was willing to and did do all the work, good luck with that. My opinion after reading that thread: - the maintainers were interested to cmake: #3012 (comment) <#3012 (comment)> - the contributor never completed the work - that fork mixed 2 things: adding cmake and making a static library — Reply to this email directly, view it on GitHub <#272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVP55FYNT4N4PZPQUW3G2DU6ODUZANCNFSM4A46YVDQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ppigazzini]

You are free to suppose whatever you want.

That PR is "unfinished" because:

• the first post has a list of open point to be implemented
• the contributor never completed the work

The maintainers seems to be interested to switch to cmake so, if you are a cmake expert and you are sure that that code is ready, please open a PR.

[bftjoe]

Really? Because it was asked and no real interest in merging was shown.

…

On Sat, Mar 5, 2022, 2:18 PM ppigazzini ***@***.***> wrote: You are free to suppose whatever you want. That PR is "unfinished" because: - the first post has a list of open point to be implemented - the contributor never completed the work The maintainers seems to be interested to switch to cmake so, if you are a cmake expert and you are sure that that code is ready, please open a PR. — Reply to this email directly, view it on GitHub <#272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVP55AXDL5U44QW2YGN3M3U6OXQZANCNFSM4A46YVDQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ppigazzini]

Please stop hand waving and write here the technical open points to have cmake in Stockfish, just to be sure that you understand that PR and the topic.

[bftjoe]

"I never got a clear answer on if people were really interested enough in this. I can update it easy enough since there are no changes to the code itself, but keeping on top of the frequent updates to Stockfish requires some effort.

If the devs are willing and ready to accept a switch to CMake, I will update this. If not, I'll leave this fork up in case someone wants to use it as a reference someday."

Also, note that even when CMake was actually being used for travis CI, the maintainers were still unwilling to commit an actual cmake file and used an auto generated one from a script instead. Please show me any maintainers showing any interest whatsoever in cmake.

[vondele]

#3012 (comment)

as said, it would be important that the current functionality is available. I.e. passes our CI, and works for the various crosses I regularly test. Once we have such a working example, we can judge if it makes the maintenance of the code base easier.

[bftjoe]

Even the basic cmake file that the travis ci auto generated let you open the directory as a project in Visual Studio, it is very clear what the SF devs position is when they didn't even commit that file.

…

On Sat, Mar 5, 2022, 2:50 PM Joost VandeVondele ***@***.***> wrote: #3012 (comment) <#3012 (comment)> as said, it would be important that the current functionality is available. I.e. passes our CI, and works for the various crosses I regularly test. Once we have such a working example, we can judge if it makes the maintenance of the code base easier. — Reply to this email directly, view it on GitHub <#272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVP55BAAP4WVVFEWHPNJMDU6O3HTANCNFSM4A46YVDQ> . You are receiving this because you commented.Message ID: ***@***.***>

[vondele]

you mean having multiple build systems is a good idea? I disagree with that, would rather prefer to have one build system, to maintain, extend, debug, etc... and yes, we can't support every tool chain/IDE out there.

[ppigazzini]

And please, remember that the switch to cmake can be done only after updating fishtest too.