Skip to content

Cleanup CMake even more#99

Open
Febbe wants to merge 4 commits intolexxmark:masterfrom
Febbe:master
Open

Cleanup CMake even more#99
Febbe wants to merge 4 commits intolexxmark:masterfrom
Febbe:master

Conversation

@Febbe
Copy link
Copy Markdown
Contributor

@Febbe Febbe commented Sep 24, 2025

Fixes #98

Previously a PR to fix #98, but was superseded by #101 and #104.
Only contains changes the other commits haven't done.

Copy link
Copy Markdown
Contributor

@Croydon Croydon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a lot of changes that are unrelated to increase the minimum CMake version, and many of those changes are non-obvious, that require much more explanation of their motivation and effects IMHO.

buildClangCl.bat Outdated
@@ -0,0 +1,5 @@
mkdir CMakeBuildClangCl
Copy link
Copy Markdown
Contributor

@Croydon Croydon Sep 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should stop adding more of those bat files. In times where CMake is well integrated in editors, we really shouldn't need them. These are highly unflexible anyway

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll remove it, shall I remove the others too?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just my make my role here clear: I contributed to winflexbison before, but I have no official say here in any way. So I am stating my own personal opinions here.

I am not sure if someone still relies on the existing bat files, but since the development of winflexbison is mostly dead, it can't affect too many people for sure, if we would remove all of them. But maybe this is something for another pull request.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another pull request it is... concerning cmake I'll let @Croydon decide, for the rest... stay compatible :-)

@GitMensch
Copy link
Copy Markdown
Collaborator

Can you please rebase and split the clang parts into a separate PR that would fix #103?

@Febbe Febbe force-pushed the master branch 2 times, most recently from c2cda58 to 1397107 Compare November 26, 2025 19:22
@Febbe Febbe force-pushed the master branch 3 times, most recently from 96f5524 to a95d9f7 Compare November 26, 2025 20:37
@Febbe Febbe changed the title Bump cmake version, fix clang-cl Cleanup CMake even more Nov 26, 2025
@GitMensch
Copy link
Copy Markdown
Collaborator

@Febbe can you please rebase? After the final review from @Croydon that can finally get live.
Thanks to both of you!

@GitMensch
Copy link
Copy Markdown
Collaborator

Is there a reason to prefer 3.21 over 3.15/3.10 (after all it is a minimal version)?

@Febbe
Copy link
Copy Markdown
Contributor Author

Febbe commented Mar 3, 2026

PROJECT_IS_TOPLEVEL requires at least 3.21.

I have no strong feelings about that feature, but FYI the original comparison was bug prone and it's now recommended to use this variable instead.

3.10 is already deprecated in newer versions and the support will be removed soon. Therefore I would not stay there. As you soon have to bump the version again.

I checked the last two Ubuntu LTS releases, both already ship a higher cmake version so most of the people won't have an issue with 3.21.

Beside the fact that one can always install the newest cmake version manually.

@GitMensch
Copy link
Copy Markdown
Collaborator

No problem with the version, mainly wanted to ask (we just add that info to the commit log).

RHEL7 has only cmake 2.x, RHEL8 already 3.26; only the oldest still supported current Debian (Bullseye) has 3.18 - but we build for Windows here, so if we don't expect Bison/Flex upstream to additional include cmake support then we can use 3.21... and even if: those projects won't leave autotools as the preferred way so "does only work that way, not with cmake" is no issue either.

Concerning this PR: is -D_DEBUG "lost"? On purpose?

@Febbe
Copy link
Copy Markdown
Contributor Author

Febbe commented Mar 3, 2026

No problem with the version, mainly wanted to ask (we just add that info to the commit log).

RHEL7 has only cmake 2.x, RHEL8 already 3.26; only the oldest still supported current Debian (Bullseye) has 3.18 - but we build for Windows here, so if we don't expect Bison/Flex upstream to additional include cmake support then we can use 3.21... and even if: those projects won't leave autotools as the preferred way so "does only work that way, not with cmake" is no issue either.

Oh right, a new cmake version is no issue on windows. You always have to install it manually.

Concerning this PR: is -D_DEBUG "lost"? On purpose?

Yes on purpose as stated in the review comment.

@GitMensch
Copy link
Copy Markdown
Collaborator

@Febbe wrote

Wouldn't you write/configure those files (headers and RC file) via cmake?

as we have a fixed cmake dependency - that's a good idea!

Would you like to inspect that (either within this or possibly with a next PR)?

endif ()
if (MSVC)
add_compile_options("/source-charset:utf-8")
option(WINFLEXBISON_USE_STATIC_RUNTIME "Set ON to change /MD(DLL) to /MT(static)" Off)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This multiple option for WINFLEXBISON_USE_STATIC_RUNTIME will be a nightmare for maintenance, preferable to consolidate them into a single variable before setting it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And also, don't expect anyone to dig through the PRs, please add a comments around the need for WINFLEXBISON_USE_STATIC_RUNTIME, I don't really know why at a glance, like its to prevent name clash with other code base that pull this in as a dependency if they use USE_STATIC_RUNTIME but we use this name previously so older scripts we missed will still work, etc.

Comment on lines +31 to +33
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>/bin")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>/bin")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELWITHDEBINFO "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>/bin")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't experimented this myself, why separate them, is the single CMAKE_RUNTIME_OUTPUT_DIRECTORY not working for some reason?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no reason, it was separated before I refactored it and was too tired to see that. Good catch.

Suggest more modern cmake commands.

Co-authored-by: jonnysoe <84360198+jonnysoe@users.noreply.github.com>
Co-authored-by: jonnysoe <84360198+jonnysoe@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Project is incompatible with modern tools

4 participants