[GH-ISSUE #99] CMake Build System (Pull Request) #82

New issue

Closed

opened 2026-05-05 11:37:56 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 11:37:56 -06:00

Owner

Originally created by @Alexhuszagh on GitHub (Feb 28, 2017).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/99

Originally assigned to: @jmcnamara on GitHub.

I wrote a CMake build system for libxlsxwriter, and passes all the entire unit test suite for multiple different build environments.

The new build system should work for:

Visual Studio Projects (and can generate Visual Studio Solutions)
MinGW on Windows, MSYS2
MXE
XCode Projects (and can generate XCode projects)

The new build system has been tested to work for:

Linux, G++ 6.3
Linux, Clang, 3.8
Fedora MinGW (cross-compiling) 6.3, 32-bit and 64-bit

Other advantages of a CMake build system include out-of-source builds (make clean works, but so does rm -r *), and it's easy to integrate with platform-specific toolsets. The main disadvantage is CMake would be a required dependency if you use the build system, and the Python runners for the functional tests (which assume an in-source build) currently do not work.

If there is any interest, I am maintaining a fork with the build system here and would gladly make a pull request. The only current modifications are adding zlib as a submodule (optional, and can be removed), FindZlib.cmake and FindPackage to find existing zlib libraries and headers, and CMakeLists.txt for project generation. In total, the new build system is under 500 lines of code and may help reduce platform-specific build tools for XCode and perhaps Visual Studio. If there is no interest, feel free to close this.

Originally created by @Alexhuszagh on GitHub (Feb 28, 2017). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/99 Originally assigned to: @jmcnamara on GitHub. I wrote a CMake build system for libxlsxwriter, and passes all the entire unit test suite for multiple different build environments. The new build system should work for: - Visual Studio Projects (and can generate Visual Studio Solutions) - MinGW on Windows, MSYS2 - MXE - XCode Projects (and can generate XCode projects) The new build system has been tested to work for: - Linux, G++ 6.3 - Linux, Clang, 3.8 - Fedora MinGW (cross-compiling) 6.3, 32-bit and 64-bit Other advantages of a CMake build system include out-of-source builds (`make clean` works, but so does `rm -r *`), and it's easy to integrate with platform-specific toolsets. The main disadvantage is CMake would be a required dependency if you use the build system, and the Python runners for the functional tests (which assume an in-source build) currently do not work. If there is any interest, I am maintaining a fork with the build system [here](https://github.com/XLTools/libxlsxwriter) and would gladly make a pull request. The only current modifications are adding zlib as a submodule (optional, and can be removed), [FindZlib.cmake](https://github.com/XLTools/libxlsxwriter/blob/master/cmake/FindZLib.cmake) and [FindPackage](https://github.com/XLTools/libxlsxwriter/blob/master/cmake/FindPackage.cmake) to find existing zlib libraries and headers, and [CMakeLists.txt](https://github.com/XLTools/libxlsxwriter/blob/master/CMakeLists.txt) for project generation. In total, the new build system is under 500 lines of code and may help reduce platform-specific build tools for XCode and perhaps Visual Studio. If there is no interest, feel free to close this.

gitea-mirror

2026-05-05 11:37:56 -06:00

closed this issue
added the
feature request
label

gitea-mirror commented

2026-05-05 11:38:02 -06:00

Author

Owner

@jmcnamara commented on GitHub (Mar 1, 2017):

Hi,

Thanks for that. There was a similar feature request recently: #80 and an associated pull request #82. However, the previous one was more invasive so I wasn't keen on it.

Your one looks cleaner but maybe you can have a look at #82 anyway for ideas.

I'd like to add some CMake support but I don't think I will be able to maintain it. If the maintenance requirement is low I'd be willing to add it. Ideally the changes should only be a CMakeLists.txt file and a cmake subdirectory.

Personally, I will continue to use and update the current Make build system but I can add Cmake to the Travis CI build to ensure it works and is up to date.

The only current modifications are adding zlib as a submodule (optional, and can be removed),

I'm not in favour of having zlib as a submodule. The PR would need to avoid that.

The main disadvantage is CMake would be a required dependency if you use the build system,

That isn't a real disadvantage. People who want to use Cmake will have it installed.

and the Python runners for the functional tests (which assume an in-source build) currently do not work.

That isn't a big issue either.

Also, could you add a few examples here of building, installing, and other actions with Cmake.

Thanks,

John

@jmcnamara commented on GitHub (Mar 1, 2017): Hi, Thanks for that. There was a similar feature request recently: #80 and an associated pull request #82. However, the previous one was more invasive so I wasn't keen on it. Your one looks cleaner but maybe you can have a look at #82 anyway for ideas. I'd like to add some CMake support but I don't think I will be able to maintain it. If the maintenance requirement is low I'd be willing to add it. Ideally the changes should only be a CMakeLists.txt file and a cmake subdirectory. Personally, I will continue to use and update the current Make build system but I can add Cmake to the Travis CI build to ensure it works and is up to date. > The only current modifications are adding zlib as a submodule (optional, and can be removed), I'm not in favour of having zlib as a submodule. The PR would need to avoid that. > The main disadvantage is CMake would be a required dependency if you use the build system, That isn't a real disadvantage. People who want to use Cmake will have it installed. > and the Python runners for the functional tests (which assume an in-source build) currently do not work. That isn't a big issue either. Also, could you add a few examples here of building, installing, and other actions with Cmake. Thanks, John

gitea-mirror commented

2026-05-05 11:38:04 -06:00

Author

Owner

@jmcnamara commented on GitHub (Mar 20, 2017):

Closed with PR #100.

@jmcnamara commented on GitHub (Mar 20, 2017): Closed with PR #100.

gitea-mirror referenced this issue

2026-05-05 12:15:14 -06:00

[PR #82] [CLOSED] CMake configure #413