qmake needs uic to extract dependency information from .ui files. In -fast mode
qmake generates Makefiles for each subproject after the previous subproject is
built, and by the time it encounters subprojects with .ui files, uic is
available to provide dependency information. In -no-fast mode qmake builds
subprojects in the same order, but generates all Makefiles beforehand, without
uic, and they miss dependencies.
Previously the last of these commands:
```
make -j sub-tools-bootstrap
make -j sub-uic sub-moc sub-rcc
make -C tools/designer/src/lib .obj/release-shared/moc_qtgradientviewdialog.o
```
failed with this error:
```
In file included from .uic/release-shared/ui_qtgradientviewdialog.h:63:0,
from .moc/release-shared/../../../../../shared/qtgradienteditor/qtgradientviewdialog.h:47,
from .moc/release-shared/moc_qtgradientviewdialog.cpp:9:
../../../shared/qtgradienteditor/qtgradientview.h:47:31: fatal error: ui_qtgradientview.h: No such file or directory
```
because uic did not ensure that the build of moc_qtgradientviewdialog.o happens
after the build of moc_qtgradientview.o.
Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
Packages get --host and --target by default, but can explicitly request
any subset to be passed as needed. See docs for more info.
rustc: Avoid hash breakage by using the old (ignored)
dontSetConfigureCross when not cross building
I successfully built it with 8 free cores;
hopefully it won't give problems.
/cc maintainers: @lovek323, @phreedom, @sander.
I wonder that the build reports no support for gstreamer and pulseaudio.
I checked it was so before this commit, but it might still be useful
to enable those.
No more 4.8.x releases are planned. End of support is scheduled to Dec'15.
Mingw(32) is rather poorly maintaned and has quite a lot of bugs. And
because our Windows cross builds were also poorly maintained and most of
the cross-tests were broken as well, I'm just taking this step and try
to switch to mingw-w64 for everything "cross Windows".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
To give the ability to use a different Qt version than the default one
(which can build 3 different times Qt Libraries if we mixed the default
one, the qtcreator one and the version including all the examples and the
docs).
Right now a developer can choose to directly install the QtSDK which
includes a "full" (developerBuild + docs + examples) Qt version and uses
it to build QtCreator.
The possibility to only install QtCreator and its previous behavior has
been kept for flexibility purposes (we do not need to force someone on the
SDK approach).
After removing qt's dependency on the symlinked combination of mesa and glu,
many qt apps were missing it now (since e9f0d10).
I resove this to a compromise.
Conflicts (a little tricky, I did some cleanup of interacting changes):
pkgs/development/compilers/llvm/default.nix
pkgs/development/libraries/libpng/default.nix
pkgs/tools/package-management/nixops/default.nix
pkgs/top-level/all-packages.nix