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

CMake Error in src/CMakeLists.txt: Imported target "QXlsx::QXlsx" includes non-existent path #3132

Closed
carlosal1015 opened this issue Mar 27, 2023 · 11 comments
Assignees
Labels
dependencies dependencies (such like ShowMySky, QXlsx, etc.) related issues importance: low Small problem, rarely visible, no crash opinion OP thinks something should behave differently
Milestone

Comments

@carlosal1015
Copy link

carlosal1015 commented Mar 27, 2023

Expected Behaviour

cmake configure and create a build directory for compile stellarium.

Actual Behaviour

When qxlsx-qt6 is installed on the system, we can not configure the build directory because is not found /usr/include/QXlsx, but exists /usr/include/QXlsxQt6.

Steps to reproduce

$ curl -LO https://github.com/Stellarium/stellarium/releases/download/v23.1/stellarium-23.1.tar.gz
$ tar -xvf stellarium-23.1.tar.gz
$ cmake -S stellarium-23.1 -B build -DENABLE_XLSX=1

System

  • Stellarium version: 23.1
  • Operating system: Arch Linux Rolling Release
  • Graphics Card: No apply
  • Screen type (if applicable): No apply

Logfile

log.txt

@alex-w alex-w added the dependencies dependencies (such like ShowMySky, QXlsx, etc.) related issues label Mar 27, 2023
@alex-w
Copy link
Member

alex-w commented Mar 27, 2023

Headers in the original library is expected in directory /usr/include/QXlsx (see)

If you want to use source directory as it in the Arch Linux, then you can re-define SOURCE_SUBDIR parameter for CPMAddPackage command (see): SOURCE_SUBDIR QXlsx -> SOURCE_SUBDIR QXlsxQt${QT_VERSION_MAJOR}

@alex-w
Copy link
Member

alex-w commented Mar 27, 2023

According to pkgs.org website only Arch Linux uses non-standard path for include directory of Qxlsx

@carlosal1015
Copy link
Author

carlosal1015 commented Mar 27, 2023

Headers in the original library is expected in directory /usr/include/QXlsx (see)

If you want to use source directory as it in the Arch Linux, then you can re-define SOURCE_SUBDIR parameter for CPMAddPackage command (see): SOURCE_SUBDIR QXlsx -> SOURCE_SUBDIR QXlsxQt${QT_VERSION_MAJOR}

Thanks for the hint.
I will take a look later for make a patch like this used for labplot. In the future, maybe having something like FindQXlsx.cmake will be a nice workaround for detect qt5 or qt6.

@alex-w alex-w added the opinion OP thinks something should behave differently label Mar 28, 2023
@DarthGandalf
Copy link
Contributor

In the future, maybe having something like FindQXlsx.cmake will be a nice workaround for detect qt5 or qt6.

No, the latest QXlsx versions install separate cmake files for qt5 and qt6: e.g. /usr/lib64/cmake/QXlsxQt5/QXlsxQt5Config.cmake which makes it work for find_package(QXlsxQt5), similar for Qt6

According to pkgs.org website only Arch Linux uses non-standard path for include directory of Qxlsx

The Arch package patches the install dir to install 2 copies of the same headers: https://github.com/archlinux/svntogit-community/blob/463e8ac91659f7b332c00e81e27e189528650ab7/trunk/coinstallability.patch#L10

In that setup, the target QXlsx::QXlsx is supposed to refer to /usr/include/QXlsxQt5, not /usr/include/QXlsxQt. But the Arch package didn't update the target. They either should install headers once instead of twice, or to also update the target.

@axd1967
Copy link
Contributor

axd1967 commented Mar 29, 2023

(related to vendor_branching; see also discussion)

@alex-w alex-w added the importance: low Small problem, rarely visible, no crash label Jun 16, 2023
@alex-w alex-w added this to the 23.2 milestone Jun 16, 2023
@alex-w alex-w self-assigned this Jun 16, 2023
@alex-w alex-w closed this as completed in 0178624 Jun 16, 2023
@alex-w alex-w added the state: published The fix has been published for testing in weekly binary package label Jun 18, 2023
@github-actions
Copy link

Hello @carlosal1015!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

@alex-w alex-w removed the state: published The fix has been published for testing in weekly binary package label Jul 2, 2023
@github-actions
Copy link

github-actions bot commented Jul 2, 2023

Hello @carlosal1015!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest

@carlosal1015
Copy link
Author

Hello @carlosal1015!

Please check the latest stable version of Stellarium: Stellarium/stellarium/releases/latest

Not working yet.

@DarthGandalf
Copy link
Contributor

@alex-w 0178624 actually doesn't affect this issue. You updated the version which Stellarium build system installs automatically, but the issue here is caused by the system package on Arch, which is inconsistent, not the one downloaded by stellarium itself when the system package is not found. Note that upstream 1.4.6 is also inconsistent itself (fixed by QtExcel/QXlsx@8c3e663 which will probably be in 1.4.7) but it's broken only when used as system package - your update of QXlsx version gladly didn't break anything in Stellarium.

@carlosal1015 Stellarium upstream cannot fix the issue with bad QXlsx package in Arch. Please complain to Arch package maintainers instead.

@DarthGandalf
Copy link
Contributor

@carlosal1015 what you can do is to force Stellarium's cmake to ignore your broken Arch package, e.g. by setting CPM_DOWNLOAD_ALL cmake option. Then it will download the working version of QXlsx.

But you still should complain to Arch maintainers about the broken package.

@carlosal1015
Copy link
Author

Now qxlsx-qt6 works out of the box with stellarium 23.4😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies dependencies (such like ShowMySky, QXlsx, etc.) related issues importance: low Small problem, rarely visible, no crash opinion OP thinks something should behave differently
Development

No branches or pull requests

4 participants