You can now refer to it as xcodebuild. This is meant to be more
discoverable for not familiar with xcbuild. xcodebuild should work in
the same way as the xcodebuild that comes with Xcode.app, but it is
built entirely with free software.
Not every package that needs xcbuild will want to use its build phase.
I have moved the xcbuild setup hook to the new attribute xcbuildHook.
This means that dontUseXcbuild is no longer needed. If you just need
to call xcbuild on its own you can just refer to xcbuild.
This reworks some of xcbuild logic to make it more compatible with
Apple’s SDK.
- Add a fake version of xcrun & xcode-select
- Cleanup platform generation. Clang does not like having 20 char
hashes in sysroot so it is much easier to just build the parent
directory for each runCommand. This is a little awkward but I have
renamed everything with an added ‘s’ to make the distinction more clear.
- Cleaned up wrapper.nix in some different ways
- Reuse some versioning logic so that we don’t end up with two
different versions of Xcode or SDK reported.
This will make it easier for people to access old versions.
You can now access attributes like:
- dwarf-fortress_0_44_11
- dwarf-fortress_0_43_05
- etc.
game.json now contains a dictionary of old game hashes. I have added
them for the last 3 releases.
- add script to generate hashes
Makes it much easier to update game.json file.
- add updateScript meta
This adds some info on the ./update.sh updateScript now available.
- cleanup updateScript
- Add some more systems
- Correctly detect source extensions (.zip or .tar.bz2)
- Proper bash quoting
- fix update.sh
- correctly detect latest df version
- append to game.json instead of overwriting it
- update hashes for 44.12
The line was essentially checking whether /bin/sh exists and is
executable and if that's the case, the isScript function returns
successfully.
When asking the author of this line on IRC it seems that even they can't
remember or imagine what this was supposed to be.
In summary: Whenever /bin/sh doesn't exist during a build, *any* file
given to isScript is reported as being a script even if it isn't.
This is kinda counter-intuitive and not something what somebody would
expect from a function called "isScript".
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra
This adds configuration options which automate the configuration of NVIDIA Optimus using PRIME. This allows using the NVIDIA proprietary driver on Optimus laptops, in order to render using the NVIDIA GPU while outputting to displays connected only to the integrated Intel GPU. It also adds an option for enabling kernel modesetting for the NVIDIA driver (via a kernel command line flag); this is particularly useful together with Optimus/PRIME because it fixes tearing on PRIME-connected screens.
The user still needs to enable the Optimus/PRIME feature and specify the bus IDs of the Intel and NVIDIA GPUs, but this is still much easier for users and more reliable. The implementation handles both the X configuration file as well as getting display managers to run certain necessary `xrandr` commands just after X has started.
Configuration of commands run after X startup is done using a new configuration option `services.xserver.displayManager.setupCommands`. Support for this option is implemented for LightDM, GDM and SDDM; all of these have been tested with this feature including logging into a Plasma session.
Note: support of `setupCommands` for GDM is implemented by making GDM run the session executable via a wrapper; the wrapper will run the `setupCommands` before execing. This seemed like the simplest and most reliable approach, and solves running these commands both for GDM's X server and user X servers (GDM starts separate X servers for itself and user sessions). An alternative approach would be with autostart files but that seems harder to set up and less reliable.
Note that some simple features for X configuration file generation (in `xserver.nix`) are added which are used in the implementation:
- `services.xserver.extraConfig`: Allows adding arbitrary new sections. This is used to add the Device section for the Intel GPU.
- `deviceSection` and `screenSection` within `services.xserver.drivers`. This allows the nvidia configuration module to add additional contents into the `Device` and `Screen` sections of the "nvidia" driver, and not into such sections for other drivers that may be enabled.
Otherwise extra packages in scope can't be made to work for cross. As
much as I think splicing is an evil trick, I think it's best to do this
and at least have it work consistently for now.
It would seems simpler to expose a `newScopeWithSplicing`, but there's a
few attrs (like `buildPackages` or `buildHaskellPackages`) that
shouldn't be spliced. Users should instead splice, override the splicing
on those packages, and apply `newScope` to that.
This was reverted in 6e07a3a19a with the
other commits in the PR, as the number of overrides added in that PR was deemed
excessive. But this commit adds no overrides, and is valuable on its
own, so I am adding it back.
(cherry picked from commit 359e0ce4bb)
Jan Tojnar