mirror of
https://github.com/jmcnamara/libxlsxwriter.git
synced 2026-05-15 14:15:54 -06:00
[GH-ISSUE #168] cmake compatibility #141
Labels
No labels
awaiting user feedback
bug
cmake
cmake
docs
feature request
in progress
long term
medium term
medium term
pull-request
question
question
ready to close
short term
under investigation
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/libxlsxwriter#141
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @remicollet on GitHub (Apr 27, 2018).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/168
Originally assigned to: @jmcnamara on GitHub.
Despite
It fails with cmake 2.8.12
@jmcnamara commented on GitHub (Apr 27, 2018):
@Alexhuszagh Can you take a look at this as well.
Or @remicollet can you submit a Pull Request.
@remicollet commented on GitHub (Apr 27, 2018):
The problem is that I'm not a cmake expert, so not able to tell which is the right required version... only that
@remicollet commented on GitHub (Apr 27, 2018):
According to cmake changelog (in 3.1rst)
@jmcnamara commented on GitHub (Apr 27, 2018):
Neither am I. That's why @Alexhuszagh normally handles these issues.
I'm guessing that you are looking at this from the point of view of packaging. Is your preference to use cmake instead of make?
The make build system is still the primary build system for libxlsxwriter. Cmake is the secondary build system.
@remicollet commented on GitHub (Apr 27, 2018):
Yes
No, but I notice a CMakeFile so I use cmake ;)
And I always consider as suspect a static Makefile (without cmake/autotools...)
@remicollet commented on GitHub (Apr 27, 2018):
For your information I need this library for the upcoming new pecl extension excel-writer which offers bindings for this library
And if everything works as expected, RPM for Fedora / RHEL / CentOS will be available in my repository which is mostly provides PHP stuff, but is also an incubator for official Fedora/EPEL repositories.
@Alexhuszagh commented on GitHub (Apr 27, 2018):
FYI, @jmcnamara, I like @remicollet's commit with very minor, minor exceptions. I'm hoping to have a fix later today.
@Alexhuszagh commented on GitHub (Apr 27, 2018):
@remicollet Good catch on the
target_sources, I updated the library generation a few months ago but forgot to test the minimum version. My fault, very well done.@Alexhuszagh commented on GitHub (Apr 27, 2018):
The main issue now with multi-arch is the fact that
-m32can be passed to the CMake flags if intentionally aiming to build a 32-bit library on a 64-bit system, but this will still install to lib64.The proper, CMake way to do this would likely be to have a separate toolchain for 32-bit toolchain that specifies the proper CMake system processor, and then could be used during project configuration, rather than "Just another option" would be to add a toolchain file for 32-bit code generation.
This correctly tells CMake that the compiler is 32-bit, not 64-bit, updates the system name, and allows Cmake to correctly determine an installation path of
liborlib64as a resylt.I'll also update the CMake documentation as a result.
@jmcnamara commented on GitHub (Apr 27, 2018):
P.S. @remicollet and @Alexhuszag. Thanks for the input. In future PRs can you avoid putting defect numbers in the subject line. You can put them in the body of the commit message.