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

[WIP] qt57: add darwin support + add new modules #17328

Closed
wants to merge 1 commit into from
Closed

[WIP] qt57: add darwin support + add new modules #17328

wants to merge 1 commit into from

Conversation

adolfogc
Copy link
Contributor

@adolfogc adolfogc commented Jul 28, 2016

Main changes
  • Add support for Mac OS X (currently only Qt4 version 4.8 is available for Darwin).
  • Add new Qt modules: QtMacExtras, QtQuickControls2, QtSCXML, QtSerialBus.
  • Other minor changes:
    • Modify maintainers/scripts/generate-qt.sh to fetch tarballs using TLS.
    • Change substituteInPlace instances for grep (otherwise it fails building in Darwin).
    • Build QtMultimedia with openal support.
    • Build QtImageFormats with libmng, libwebp and jasper support.
    • Build Qt using systems double-conversion library.
    • Build QtConnectivity with bluez support (Linux).
    • Remove line that fixed bison to bison2. It was a workaround to a bug that was fixed with Qt 5.2.0 (see this).
TO-DO
  • Fix issue causing regression in Nixos.

  • Figure out why some _dylib_s aren't found by ld (Darwin).

  • Figure out why the Travis build failed for Xcode:

    The invocation of "nix-build -A qt57.qtdoc -A qt57.libdbusmenu -A qt57.qca-qt5 -A qt57.full -A qt57.qtconnectivity -A qt57.qtquickcontrols2 -A qt57.qtmacextras -A qt57.poppler -A qt57.qtmultimedia -A qt57.qtscript -A qt57.qtgraphicaleffects -A qt57.libcommuni -A qt57.qtxmlpatterns -A qt57.qtsensors -A qt57.accounts-qt -A qt57.qtscxml -A qt57.qtsvg -A qt57.qtquickcontrols -A qt57.grantlee

  • Add qtstyleplugins as a library separate from Qt5.

  • Check for #17413. A rebase and a fix may be needed if it is merged before this one.

  • Check for #16561. It enables building the QtWebEngine module in Qt 5.6.

Things done
  • Tested using sandboxing
    (nix.useChroot on NixOS,
    or option build-use-chroot in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • OS X
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

@adolfogc, thanks for your PR! By analyzing the annotation information on this pull request, we identified @ttuegel to be a potential reviewer

@@ -0,0 +1,7 @@
{ qtSubmodule, qtbase, pkgconfig, GConf, gtk, libX11}:

qtSubmodule {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adolfogc Please add this module as a library separate from Qt until it is part of a release.

@adolfogc adolfogc changed the title [RFC] qt5: 5.6 -> 5.7 + darwin support [WIP] qt5: 5.6 -> 5.7 + darwin support Jul 29, 2016
@ttuegel
Copy link
Member

ttuegel commented Jul 29, 2016

The update to Qt 5.7 is superseded by #17369, so you'll need to rebase your changes.

Thanks for getting this working on Darwin!

@adolfogc adolfogc changed the title [WIP] qt5: 5.6 -> 5.7 + darwin support [WIP] qt57: add darwin support + add new modules Jul 31, 2016
@adolfogc
Copy link
Contributor Author

adolfogc commented Jul 31, 2016

@ttuegel I've rebased and included the darwin changes (please note there are other changes as well). I omitted the QtStylePlugins library because I saw you added support for building the GTK theme in #17369 and I don't see a reason to add those plugins anymore.

-qml-debug
-rpath
-verbose
-silent
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using both -verbose and -silent is probably a mistake.

Copy link
Contributor Author

@adolfogc adolfogc Jul 31, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catch. I've just rebased, fixed and pushed back.

@adolfogc
Copy link
Contributor Author

@ttuegel I've made the requested changes. What's the difference between buildInputs and nativeBuildInputs when you're not cross-compiling?

@ttuegel
Copy link
Member

ttuegel commented Jul 31, 2016

What's the difference between buildInputs and nativeBuildInputs when you're not cross-compiling?

None, except documenting which inputs may be retained as runtime dependencies. I don't know if it will cross-compile, but I inherited the package that way.

@adolfogc
Copy link
Contributor Author

Ok, thanks. I was confused with how should I use those two lists for Qt.

@ttuegel
Copy link
Member

ttuegel commented Jul 31, 2016

Is this ready to go on your end? (The title still says "[WIP]" so I wanted to double-check.)

@adolfogc
Copy link
Contributor Author

I still want to check why the travis build isn't working for Xcode.

-plugindir $out/lib/qt5/plugins \
-importdir $out/lib/qt5/imports \
-qmldir $out/lib/qt5/qml \
-docdir $out/share/doc/qt5"
Copy link
Contributor Author

@adolfogc adolfogc Aug 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ttuegel I moved these lines (86-89) to configureFlags. I removed them.

@adolfogc
Copy link
Contributor Author

adolfogc commented Aug 1, 2016

@ttuegel Please see this discussion. Should we rename nativeBuildInputs to buildInputs?

buildInputs
A list of dependencies used by stdenv to set up the environment for the build. For each dependency dir, the directory dir/bin, if it exists, is added to the PATH environment variable. Other environment variables are also set up via a pluggable mechanism. For instance, if buildInputs contains Perl, then the lib/site_perl subdirectory of each input is added to the PERL5LIB environment variable. See Section 3.6, “Package setup hooks” for details.
propagatedBuildInputs
Like buildInputs, but these dependencies are propagated: that is, the dependencies listed here are added to the buildInputs of any package that uses this package as a dependency. So if package Y has propagatedBuildInputs = [X], and package Z has buildInputs = [Y], then package X will appear in Z’s build environment automatically.

Taken from: https://nixos.org/nixpkgs/manual/#ssec-stdenv-attributes

What I understand from reading the above is that propagatedBuildInputs is used to specify the packages retained as runtime dependencies.

@ttuegel
Copy link
Member

ttuegel commented Aug 1, 2016

What I understand from reading the above is that propagatedBuildInputs is used to specify the packages retained as runtime dependencies.

That is not true. Runtime dependencies are determined by Nix automatically at the end of a build by searching the output for store paths. Runtime dependencies can come from any of the build inputs, whether propagated or not. When cross-compiling, they cannot come from anything native, because those dependencies come from the build system.

The difference between buildInputs and propagatedBuildInputs is the following

  • everything in buildInputs it is included in the build environment for this package
  • everything in propagatedBuildInputs is included in the build environment for the package and in the build environment for every package that depends on this one.

@adolfogc
Copy link
Contributor Author

adolfogc commented Aug 2, 2016

Ok, thanks for explaining the difference between buildInputs and propagatedBuildInputs and their relationship to runtime dependencies. Regarding the other (difference between buildInputs and nativeBuildInputs) what is the action to take? Is it a good idea to rename nativeBuildInputs to buildInputs? My understanding is that they get both combined in a single list.

(I fixed the link above, it was this discussion).

@bennofs
Copy link
Contributor

bennofs commented Aug 2, 2016

@adolfogc That issue is about a greater refactoring of nixpkgs itself. For packages, the rule is currently as follows:

  • everything that should be build for the platform where the output is run should be in buildInputs (so libraries the output depends on, etc)
  • everything that should be build for the platform on which the compile happens should be in nativeBuildInputs (so build tools, etc)

This is what should be used for the time being. If that nixpkgs refactoring happens, then it will change, but since that is not yet the case, you should stick to the current meaning of these attributes.


nativeBuildInputs =
[ bison flex gperf lndir patchelf perl pkgconfig python ruby ];
[ bison flex gperf lndir patchelf perl pkgconfig python ruby bash ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adolfogc bash is already included in stdenv so this should not be necessary.

@ttuegel
Copy link
Member

ttuegel commented Aug 2, 2016

The build of qt57.qtbase fails for me on NixOS. The builder spawns more than 300 compiler processes and then dies when it runs out of memory. I can build it from master, so there seems to be a regression hidden here.

@adolfogc
Copy link
Contributor Author

adolfogc commented Aug 3, 2016

@bennofs Thanks, your explanation and ttuegels have helped me understand how I should use those lists correctly.

@adolfogc
Copy link
Contributor Author

adolfogc commented Aug 3, 2016

@ttuegel Thanks for the feedback, I will look into what's causing this regression and remove the unnecessary bash.

- Adds support for Mac OS X (currently only Qt4 version 4.8 is available for Darwin).
- Adds new Qt modules: QtMacExtras, QtQuickControls2, QtSCXML, QtSerialBus.
- Other minor changes:
   - Modifies `maintainers/scripts/generate-qt.sh` to fetch tarballs using TLS.
   - Changes some substituteInPlace instances for grep (otherwise it fails building in Darwin).
   - Builds QtMultimedia with openal support.
   - Builds QtImageFormats with libmng, libwebp and jasper support.
   - Builds Qt using systems double-conversion library.
   - Builds QtConnectivity with bluez support (Linux).
   - Remove line that fixed bison to bison2. It was a workaround to a bug that was fixed with Qt 5.2.0.

Thanks to @ttuegel for all the feedback.
@ttuegel
Copy link
Member

ttuegel commented Feb 14, 2017

I am closing this PR because it is outdated. Darwin support for all Qt 5 versions was added by another PR. Please open a new PR if there are still missing submodules.

@ttuegel ttuegel closed this Feb 14, 2017
@adolfogc
Copy link
Contributor Author

@ttuegel Thanks, good to hear Darwin support was added for Qt 5!

@lelongg lelongg mentioned this pull request Jun 8, 2020
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants