cglm icon indicating copy to clipboard operation
cglm copied to clipboard

Use a single build system

Open Chris-F5 opened this issue 2 years ago • 8 comments

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.

Chris-F5 avatar Jul 15 '22 21:07 Chris-F5

Hi @Chris-F5 ,

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

recp avatar Jul 16 '22 09:07 recp

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.

eli-schwartz avatar Jul 17 '22 05:07 eli-schwartz

@eli-schwartz thanks for your feedbacks 👍

recp avatar Jul 18 '22 21:07 recp

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

q234rty avatar Dec 17 '22 17:12 q234rty

Hi @q234rty,

With this PR, cmake uses separate pkg-config input file and the issue must be fixed I guess: https://github.com/recp/cglm/pull/271

recp avatar Dec 17 '22 19:12 recp

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.

masters3d avatar Dec 17 '23 04:12 masters3d

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

recp avatar Dec 18 '23 08:12 recp

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

waywardmonkeys avatar Feb 10 '24 07:02 waywardmonkeys