Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a single build system #255

Open
Chris-F5 opened this issue Jul 15, 2022 · 8 comments
Open

Use a single build system #255

Chris-F5 opened this issue Jul 15, 2022 · 8 comments

Comments

@Chris-F5
Copy link
Contributor

At the moment, cglm can be built with the following build systems:

  • CMake
  • Meson
  • Swift package manager
  • Autotools
  • MSBuild

It is not realistic to expect developers to check that cglm compiles correctly on all 5 build systems before making a pull request. So if a change breaks one build system, it is possible that the problem will go unnoticed.
Building with different systems can result in different libcglm.so files (building with CMake and Meson generate libcglm.so with different hashes). If a bug only occurs when building with a specific build system then it could be very difficult to find.

For these reasons, it would be better to use only a single build system. I think CMake would be most appropriate as its cross platform and because glm uses it.

I would be happy to make a pull request for this change if a single build system can be agreed upon.

@recp
Copy link
Owner

recp commented Jul 16, 2022

Hi @Chris-F5 ,

Thanks for the feedback, let's get more feedback for this.

@eli-schwartz
Copy link

eli-schwartz commented Jul 17, 2022

MSBuild at least can just be generated by either Meson or CMake, so it's probably not very important to keep. Also handwritten XML is going to be the hardest thing to keep up to date anyway.

Like cmake's support for add_subdirectory on another cmake project, there's one particular advantage to having meson support in that you can embed it as a subproject inside your own meson-using project and it "just works". This is described in the README the same way it's described for cmake.
This advantage is not present in autotools (and unlike both cmake and meson, autotools is not cross-platform enough to run well on Windows so an entire class of people cannot use it anyway).

Building with different systems can result in different libcglm.so files (building with CMake and Meson generate libcglm.so with different hashes). If a bug only occurs when building with a specific build system then it could be very difficult to find.

Different hashes can be caused by using different file paths when referencing the source files, that's not really a good proof of anything. Looking at differences in the compiler invocations in build.ninja or compile_commands.json should tell you all you need to know there.

@recp
Copy link
Owner

recp commented Jul 18, 2022

@eli-schwartz thanks for your feedbacks 👍

@q234rty
Copy link

q234rty commented Dec 17, 2022

The autotools build is currently broken (the built cglm.pc includes placeholders).

@recp
Copy link
Owner

recp commented Dec 17, 2022

Hi @q234rty,

With this PR, cmake uses separate pkg-config input file and the issue must be fixed I guess: #271

@masters3d
Copy link

masters3d commented Dec 17, 2023

not sure if applicable, one way I have seen this addressed is to add build steps on CI to build in all supported build systems.

@recp
Copy link
Owner

recp commented Dec 18, 2023

@masters3d sure hope we update CIs to cover all build systems 👍

@waywardmonkeys
Copy link
Contributor

I've submitted #386 which adds a bunch of CI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants