[GH-ISSUE #80] CMake build

gitea-mirror commented

2026-05-05 11:36:08 -06:00

Owner

Originally created by @burlen on GitHub (Dec 1, 2016).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/80

Originally assigned to: @jmcnamara on GitHub.

Have you considered switching to CMake, or adding it as a side by side option to complement your makefile base solution?

I'm contemplating writing a CMakeLists so that the xlsx writer can be built more easily integrated into our cmake based cross-platform superbuild, and was curious to see if you already written a CMakeLists file for xlsx writer, and to see what your thoughts are on the subject.

Thanks
Burlen

Originally created by @burlen on GitHub (Dec 1, 2016). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/80 Originally assigned to: @jmcnamara on GitHub. Have you considered switching to CMake, or adding it as a side by side option to complement your makefile base solution? I'm contemplating writing a CMakeLists so that the xlsx writer can be built more easily integrated into our cmake based cross-platform superbuild, and was curious to see if you already written a CMakeLists file for xlsx writer, and to see what your thoughts are on the subject. Thanks Burlen

gitea-mirror closed this issue

2026-05-05 11:36:10 -06:00

gitea-mirror commented

2026-05-05 11:36:12 -06:00

Author

Owner

@jmcnamara commented on GitHub (Dec 1, 2016):

Have you considered switching to CMake, or adding it as a side by side option to complement your makefile base solution?

I wouldn't be keen on the idea since I don't know enough CMake to maintain it.

If you do create a CMakeLists then feel free to post a link to it here in case other people are interested.

Thanks for the suggestion.

John

@jmcnamara commented on GitHub (Dec 1, 2016): > Have you considered switching to CMake, or adding it as a side by side option to complement your makefile base solution? I wouldn't be keen on the idea since I don't know enough CMake to maintain it. If you do create a CMakeLists then feel free to post a link to it here in case other people are interested. Thanks for the suggestion. John

gitea-mirror commented

2026-05-05 11:36:16 -06:00

Author

Owner

@burlen commented on GitHub (Dec 5, 2016):

here is link to branch in my fork:
https://github.com/burlen/libxlsxwriter/pull/1

@burlen commented on GitHub (Dec 5, 2016): here is link to branch in my fork: https://github.com/burlen/libxlsxwriter/pull/1

gitea-mirror commented

2026-05-05 11:36:17 -06:00

Author

Owner

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

See also #99

@jmcnamara commented on GitHub (Mar 1, 2017): See also #99

gitea-mirror commented

2026-05-05 11:36:19 -06:00

Author

Owner

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

So I've updated the fork here.

Pros:

Less than 500 lines of code, of which less than 200 are specific to libxlsxwriter
Source file globbing for minimal maintenance.
Automatic versioning (see lines 68-73).
Optional, manual ZLIB_ROOT for custom ZLIB install directories (only required for unittests and examples).
Same logic as Makefile
Out-of-source builds.
CMake generators, for integration with XCode and Visual Studio Projects

Cons:

No Functional Tests (due to out-of-source builds).

Maintenance:

There are a few conditions where I can see the CMake build sytem requiring separate maintenance. One is if the versioning changes syntax, or moves to a file other than include/xlsxwriter.h. The other is if a unittest or source file is added to a new directory, or another third party module is added. Other than those specific cases, CMake should automatically track new headers inside include and include/xlsxwriter, track new source files inside the existing source and unittest directories, so the maintenance should be little to none.

Examples

I've added examples inside the documentation of the CMakeLists file here, including documentation of the various configuration flags and build tools available.

A quick example for building libxlsxwriter with unittests and examples on a Unix-like platform, in release mode:

cmake .. -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DCMAKE_BUILD_TYPE=Release
make -j 5
make -j 5 check_xlsxwriter_unit    # run unittests
make install                       # install to the system prefix, uses /usr/local/lib on most platforms

Another example for building libxlsxwriter with Visual Studio is:

cmake .. -DCMAKE_BUILD_TYPE=Release
msbuild /P:Configuration=Release xlsxwriter.sln

If this seems suitable, I'll make a pull request.

@Alexhuszagh commented on GitHub (Mar 1, 2017): So I've updated the fork [here](https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt). **Pros:** - Less than 500 lines of code, of which less than 200 are specific to libxlsxwriter - Source file globbing for minimal maintenance. - Automatic versioning (see lines 68-73). - Optional, manual `ZLIB_ROOT` for custom ZLIB install directories (only required for unittests and examples). - Same logic as Makefile - Out-of-source builds. - CMake generators, for integration with XCode and Visual Studio Projects **Cons:** - No Functional Tests (due to out-of-source builds). **Maintenance:** There are a few conditions where I can see the CMake build sytem requiring separate maintenance. One is if the versioning changes syntax, or moves to a file other than `include/xlsxwriter.h`. The other is if a unittest or source file is added to a new directory, or another third party module is added. Other than those specific cases, CMake should automatically track new headers inside `include` and `include/xlsxwriter`, track new source files inside the existing source and unittest directories, so the maintenance should be little to none. **Examples** I've added examples inside the documentation of the CMakeLists file [here](https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt), including documentation of the various configuration flags and build tools available. A quick example for building libxlsxwriter with unittests and examples on a Unix-like platform, in release mode: ```bash cmake .. -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DCMAKE_BUILD_TYPE=Release make -j 5 make -j 5 check_xlsxwriter_unit # run unittests make install # install to the system prefix, uses /usr/local/lib on most platforms ``` Another example for building libxlsxwriter with Visual Studio is: ```bash cmake .. -DCMAKE_BUILD_TYPE=Release msbuild /P:Configuration=Release xlsxwriter.sln ``` If this seems suitable, I'll make a pull request.

gitea-mirror commented

2026-05-05 11:36:20 -06:00

Author

Owner

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

Hi Alexander,

Cool. By the way my fork has much of that functionality and the tests
working for out of source builds as well. :)
https://github.com/burlen/libxlsxwriter/tree/cmake_configure
although I hadn't ever tested mine on Visual Studio, just OSX and Linux
where we currently need it.

Burlen

On 03/01/2017 12:44 PM, Alexander Huszagh wrote:

So I've updated the fork here
https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt.

Pros:

Less than 500 lines of code, of which less than 200 are specific
to libxlsxwriter

Source file globbing for minimal maintenance.

Automatic versioning (see lines 68-73).

Optional, manual |ZLIB_ROOT| for custom ZLIB install directories
(only required for unittests and examples).

Same logic as Makefile

Out-of-source builds.

Cons:

No Functional Tests (due to out-of-source builds).

Maintenance:

There are a few conditions where I can see the CMake build sytem
requiring separate maintenance. One is if the versioning changes
syntax, or moves to a file other than |include/xlsxwriter.h|. The
other is if a unittest or source file is added to a new directory, or
another third party module is added. Other than those specific cases,
CMake should automatically track new headers inside |include| and
|include/xlsxwriter|, track new source files inside the existing
source and unittest directories, so the maintenance should be little
to none.

Examples

I've added examples inside the documentation of the CMakeLists file
here
https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt,
including documentation of the various configuration flags and build
tools available.

A quick example for building libxlsxwriter with unittests and examples
on a Unix-like platform, in release mode:

cmake .. -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DCMAKE_BUILD_TYPE=Release
make -j 5
make -j 5 check_xlsxwriter_unit# run unittests
make install# install to the system prefix, uses /usr/local/lib on most platforms

Another example for building libxlsxwriter with Visual Studio is:

cmake .. -DCMAKE_BUILD_TYPE=Release
msbuild /P:Configuration=Release xlsxwriter.sln

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jmcnamara/libxlsxwriter/issues/80#issuecomment-283464094,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHBbRjArpE9kt7wKPxHrkW0HuJLLB62ks5rhdi1gaJpZM4LB-tn.

@burlen commented on GitHub (Mar 1, 2017): Hi Alexander, Cool. By the way my fork has much of that functionality and the tests working for out of source builds as well. :) https://github.com/burlen/libxlsxwriter/tree/cmake_configure although I hadn't ever tested mine on Visual Studio, just OSX and Linux where we currently need it. Burlen On 03/01/2017 12:44 PM, Alexander Huszagh wrote: > > So I've updated the fork here > <https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt>. > > *Pros:* > > * Less than 500 lines of code, of which less than 200 are specific > to libxlsxwriter > * Source file globbing for minimal maintenance. > * Automatic versioning (see lines 68-73). > * Optional, manual |ZLIB_ROOT| for custom ZLIB install directories > (only required for unittests and examples). > * Same logic as Makefile > * Out-of-source builds. > > *Cons:* > > * No Functional Tests (due to out-of-source builds). > > *Maintenance:* > > There are a few conditions where I can see the CMake build sytem > requiring separate maintenance. One is if the versioning changes > syntax, or moves to a file other than |include/xlsxwriter.h|. The > other is if a unittest or source file is added to a new directory, or > another third party module is added. Other than those specific cases, > CMake should automatically track new headers inside |include| and > |include/xlsxwriter|, track new source files inside the existing > source and unittest directories, so the maintenance should be little > to none. > > *Examples* > > I've added examples inside the documentation of the CMakeLists file > here > <https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt>, > including documentation of the various configuration flags and build > tools available. > > A quick example for building libxlsxwriter with unittests and examples > on a Unix-like platform, in release mode: > > cmake .. -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DCMAKE_BUILD_TYPE=Release > make -j 5 > make -j 5 check_xlsxwriter_unit# run unittests > make install# install to the system prefix, uses /usr/local/lib on most platforms > > Another example for building libxlsxwriter with Visual Studio is: > > cmake .. -DCMAKE_BUILD_TYPE=Release > msbuild /P:Configuration=Release xlsxwriter.sln > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/jmcnamara/libxlsxwriter/issues/80#issuecomment-283464094>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAHBbRjArpE9kt7wKPxHrkW0HuJLLB62ks5rhdi1gaJpZM4LB-tn>. >

gitea-mirror commented

2026-05-05 11:36:22 -06:00

Author

Owner

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

Pros:

Source file globbing for minimal maintenance.

That's probably going to make things more difficult than you anticipate.
from the cmake documentation:

(We do not recommend using GLOB to collect a list of source files
from your source tree. If no CMakeLists.txt file changes when a
source is added or removed then the generated build system cannot
know when to ask CMake to regenerate.)

On 03/01/2017 12:44 PM, Alexander Huszagh wrote:

So I've updated the fork here
https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt.

Pros:

Less than 500 lines of code, of which less than 200 are specific
to libxlsxwriter

Source file globbing for minimal maintenance.

Automatic versioning (see lines 68-73).

Optional, manual |ZLIB_ROOT| for custom ZLIB install directories
(only required for unittests and examples).

Same logic as Makefile

Out-of-source builds.

Cons:

No Functional Tests (due to out-of-source builds).

Maintenance:

There are a few conditions where I can see the CMake build sytem
requiring separate maintenance. One is if the versioning changes
syntax, or moves to a file other than |include/xlsxwriter.h|. The
other is if a unittest or source file is added to a new directory, or
another third party module is added. Other than those specific cases,
CMake should automatically track new headers inside |include| and
|include/xlsxwriter|, track new source files inside the existing
source and unittest directories, so the maintenance should be little
to none.

Examples

I've added examples inside the documentation of the CMakeLists file
here
https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt,
including documentation of the various configuration flags and build
tools available.

A quick example for building libxlsxwriter with unittests and examples
on a Unix-like platform, in release mode:

cmake .. -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DCMAKE_BUILD_TYPE=Release
make -j 5
make -j 5 check_xlsxwriter_unit# run unittests
make install# install to the system prefix, uses /usr/local/lib on most platforms

Another example for building libxlsxwriter with Visual Studio is:

cmake .. -DCMAKE_BUILD_TYPE=Release
msbuild /P:Configuration=Release xlsxwriter.sln

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jmcnamara/libxlsxwriter/issues/80#issuecomment-283464094,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHBbRjArpE9kt7wKPxHrkW0HuJLLB62ks5rhdi1gaJpZM4LB-tn.

@burlen commented on GitHub (Mar 1, 2017): > *Pros:* > > * Source file globbing for minimal maintenance. > That's probably going to make things more difficult than you anticipate. from the cmake documentation: (We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.) On 03/01/2017 12:44 PM, Alexander Huszagh wrote: > > So I've updated the fork here > <https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt>. > > *Pros:* > > * Less than 500 lines of code, of which less than 200 are specific > to libxlsxwriter > * Source file globbing for minimal maintenance. > * Automatic versioning (see lines 68-73). > * Optional, manual |ZLIB_ROOT| for custom ZLIB install directories > (only required for unittests and examples). > * Same logic as Makefile > * Out-of-source builds. > > *Cons:* > > * No Functional Tests (due to out-of-source builds). > > *Maintenance:* > > There are a few conditions where I can see the CMake build sytem > requiring separate maintenance. One is if the versioning changes > syntax, or moves to a file other than |include/xlsxwriter.h|. The > other is if a unittest or source file is added to a new directory, or > another third party module is added. Other than those specific cases, > CMake should automatically track new headers inside |include| and > |include/xlsxwriter|, track new source files inside the existing > source and unittest directories, so the maintenance should be little > to none. > > *Examples* > > I've added examples inside the documentation of the CMakeLists file > here > <https://github.com/Alexhuszagh/libxlsxwriter/blob/master/CMakeLists.txt>, > including documentation of the various configuration flags and build > tools available. > > A quick example for building libxlsxwriter with unittests and examples > on a Unix-like platform, in release mode: > > cmake .. -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DCMAKE_BUILD_TYPE=Release > make -j 5 > make -j 5 check_xlsxwriter_unit# run unittests > make install# install to the system prefix, uses /usr/local/lib on most platforms > > Another example for building libxlsxwriter with Visual Studio is: > > cmake .. -DCMAKE_BUILD_TYPE=Release > msbuild /P:Configuration=Release xlsxwriter.sln > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/jmcnamara/libxlsxwriter/issues/80#issuecomment-283464094>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAHBbRjArpE9kt7wKPxHrkW0HuJLLB62ks5rhdi1gaJpZM4LB-tn>. >

gitea-mirror commented

2026-05-05 11:36:23 -06:00

Author

Owner

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

@burlen That's an issue if the maintainer is primarily using the build system. As an external build system for an existing project, it's entirely fine (and much easier).

It's true, if you don't edit the CMakeLists, then the build system isn't updated. But this lowers the amount of maintenance for @jmcnamara to maintain the CMake build system, since it should handle new files with any fresh build. I carefully chose globs rather than manually listing files since this is more of a supplementary build system, rather than the primary one.

Also, I'm not explicitly forbidding in-source builds, because the original project works fine with them. Yes, I dislike cluttering the source with files, but that's not exactly a flaw.

@Alexhuszagh commented on GitHub (Mar 1, 2017): @burlen That's an issue if the maintainer is primarily using the build system. As an external build system for an existing project, it's entirely fine (and much easier). It's true, if you don't edit the CMakeLists, then the build system isn't updated. But this lowers the amount of maintenance for @jmcnamara to maintain the CMake build system, since it should handle new files with any fresh build. I carefully chose globs rather than manually listing files since this is more of a supplementary build system, rather than the primary one. Also, I'm not explicitly forbidding in-source builds, because the original project works fine with them. Yes, I dislike cluttering the source with files, but that's not exactly a flaw.

gitea-mirror commented

2026-05-05 11:36:24 -06:00

Author

Owner

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

so to me, I want things done according to best practices it increases
quality reduces maintenance over time. when I integrated cmake into
libxlsxwriter, I ended up applying best practices, which meant some
differences compared to the current Makefiles.

I think the down side of trying to emulate the current Makefile is that
you'd not be able to transition to CMake as the primary build system,
without a bunch of work, and potentially lost time debugging odd issues
(eg: why my new source file isn't being compiled)

That said, I don't have a stake in libxlsxwriter, not sure how the
author prioritizes things, and very happy that your patch might be accepted

Burlen

On 03/01/2017 02:17 PM, Alexander Huszagh wrote:

@burlen https://github.com/burlen That's an issue if the maintainer
is primarily using the build system. As an external build system for
an existing project, it's entirely fine (and much easier).

It's true, if you don't edit the CMakeLists, then the build system
isn't updated. But this lowers the amount of maintenance for
@jmcnamara https://github.com/jmcnamara to maintain the CMake build
system, since it should handle new files with any fresh build. I
carefully chose globs rather than manually listing files since this is
more of a supplementary build system, rather than the primary one.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jmcnamara/libxlsxwriter/issues/80#issuecomment-283489253,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHBbUTgYp0OjBuwclUF2aLPmu2oAubYks5rhe6JgaJpZM4LB-tn.

@burlen commented on GitHub (Mar 1, 2017): so to me, I want things done according to best practices it increases quality reduces maintenance over time. when I integrated cmake into libxlsxwriter, I ended up applying best practices, which meant some differences compared to the current Makefiles. I think the down side of trying to emulate the current Makefile is that you'd not be able to transition to CMake as the primary build system, without a bunch of work, and potentially lost time debugging odd issues (eg: why my new source file isn't being compiled) That said, I don't have a stake in libxlsxwriter, not sure how the author prioritizes things, and very happy that your patch might be accepted Burlen On 03/01/2017 02:17 PM, Alexander Huszagh wrote: > > @burlen <https://github.com/burlen> That's an issue if the maintainer > is primarily using the build system. As an external build system for > an existing project, it's entirely fine (and much easier). > > It's true, if you don't edit the CMakeLists, then the build system > isn't updated. But this lowers the amount of maintenance for > @jmcnamara <https://github.com/jmcnamara> to maintain the CMake build > system, since it should handle new files with any fresh build. I > carefully chose globs rather than manually listing files since this is > more of a supplementary build system, rather than the primary one. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/jmcnamara/libxlsxwriter/issues/80#issuecomment-283489253>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAHBbUTgYp0OjBuwclUF2aLPmu2oAubYks5rhe6JgaJpZM4LB-tn>. >

gitea-mirror commented

2026-05-05 11:36:25 -06:00

Author

Owner

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

@Alexhuszagh

So I've updated the fork here.

That looks good. Submit a PR as a single (squashed) commit and I'll merge it. It doesn't need to have every build option in the first version. You or others can add to it as required.

:license: BSD, see LICENSE.txt for more details.

Could you change this to FreeBSD. That is the main license.

Maintenance

Don't be too worried about zero maintenance. I can add dirs to the file if required. :-)

Automatic versioning isn't required since the Make build already has this and that is what I will be using for the release process.

Also, in general the Cmake system doesn't have to mirror the Make system. There are a lot of targets in there that only the maintainer needs and itt is unlikely that I will move to Cmake.

Thanks,

John

@jmcnamara commented on GitHub (Mar 3, 2017): @Alexhuszagh > So I've updated the fork here. That looks good. Submit a PR as a single (squashed) commit and I'll merge it. It doesn't need to have every build option in the first version. You or others can add to it as required. > :license: BSD, see LICENSE.txt for more details. Could you change this to FreeBSD. That is the main license. > Maintenance Don't be too worried about zero maintenance. I can add dirs to the file if required. :-) Automatic versioning isn't required since the Make build already has this and that is what I will be using for the release process. Also, in general the Cmake system doesn't have to mirror the Make system. There are a lot of targets in there that only the maintainer needs and itt is unlikely that I will move to Cmake. Thanks, John

gitea-mirror referenced this issue

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

[PR #68] [CLOSED] [PROPOSAL] ability to specify cell's format without changing cell's content #408

Rows
Columns

[GH-ISSUE #80] CMake build #68