Attempting to add Darwin support for QGIS #71398
Comments
|
cc @worldofpeace for qt knowledge :) |
|
Since these headers are part of the QtGui framework I think |
|
I fixed the QGIS 2.X build for darwin a long time ago, perhaps that PR will provide some inspiration about how to fix these kinds of issues. #36902 |
|
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them. Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel. |
stale
bot
added
the
2.status: stale
|
Still important to me. |
stale
bot
removed
the
2.status: stale
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
@lsix i'm poking at this issue a little bit -- because qscintilla-qt5 is currently failing on Darwin, I'm trying to see if I can get that to pass. As is, darwin can't successfully generate any Makefiles or build with the current formula. If I update the formula to pull the source for 2.13 (which drops qt4, so would ultimately require a little more moving of pieces around -- one option might be to create a qscintilla-qt4 legacy formula, kind of like sip_4, and then make plain qscintilla default to qt5+), it gets gets things mostly working again, but this requires a switch to pyproject. With that switch (and removed logic for all the qt4 checks), it starts building from source and eventually fails with: Any advice on how to get pyproject or the qscintilla builder to be able to correctly find the new location for QtCoremod.sip? Since the newer versions don't have |
stale
bot
removed
the
2.status: stale
|
Note -- I've prepared a patch that enables a |
|
Not quite done yet! Still need #150286 to get finished and merged, and then I'll still need to file another PR based on the patch which I started in that PR, but it's a lot closer now. |
|
Note: #157862 is my progress so far here. If anyone has a suggestion for how to resolve the dylib issue I'm stuck on there, that may be the final step to getting this closed! |
|
Dylib issue from last year is now resolved, but the .app crashes on startup (see #157862 (comment)). If anyone has a suggestion on how to resolve this, it'd be appreciated! |
|
also very interested in this. if i had any knowledge of how to help here, i would! (also hi will, another urban planner who uses nix! a rare sight to see!) |
Describe the bug
I'm attempting to add Darwin support for QGIS. As my first attempt, I've tried the naive path of changing https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/gis/qgis/unwrapped.nix#L54 from
platforms = with lib.platforms; linux;toplatforms = with lib.platforms; all;and runningnix-shell. However, when building the dependencies, I run into this problem with the python module for Qscintilla:I'm not sure how to satisfy the
QAbstractScrollAreaheader file dependency. I did notice a file in qtbase in my store:/nix/store/jfj2fmclsd1fmly02sfga7ddf42yvpaj-qtbase-5.11.3-dev/include/QtWidgets/QAbstractScrollArea. My naive guess would be to pass-I/nix/store/jfj2fmclsd1fmly02sfga7ddf42yvpaj-qtbase-5.11.3-dev/include/QtWidgetsto the compiler, but I don't know whether it's that trivial nor how to do this using Nix.Any ideas?
To Reproduce
Steps to reproduce the behavior:
mkdir nixpkgs/tmp && cd nixpkgs/tmpnix-shell -E "with import ../pkgs/top-level/impure.nix {}; libsForQt5.callPackage ../pkgs/applications/gis/qgis/unwrapped.nix { withGrass = false; }"or alternativelynix-shell -E "with import ../pkgs/top-level/impure.nix {}; callPackage ../pkgs/applications/gis/qgis "Expected behavior
I should be dropped into a
nix-shellwith all my dependencies built and available to begin hacking on QGIS.Screenshots
N/A (see shell output above)
Additional context
Background: this is my first time modifying a Nix expression in Nixpkgs, indeed my first serious attempt at any kind of Nix packaging. I've been studying Nix very intently for the past few weeks and have gone through the Nix pills, the Nix manual, the Nixpkgs manual, and parts of Dostra's PhD thesis. I'm a beginner but not totally unfamiliar :-).
I'm also not too familiar with packaging Qt.
Finally, note that I'm trying to use my globally-installed Nix tools with my cloned nixpkgs. I'm not sure whether this is explicitly supported, please let me know if there's a better way.
Metadata
Note that the above output is from running
nix runglobally, whereas I'm trying to use my local cloned copy of nixpkgs. (Perhaps this is a problem?)Maintainer information:
The text was updated successfully, but these errors were encountered: