···
231
-
The extension of <envar>PATH</envar> with dependencies, alluded to
232
-
above, proceeds according to the relative platforms alone. The
233
-
process is carried out only for dependencies whose host platform
234
-
matches the new derivation's build platform i.e. dependencies which
235
-
run on the platform where the new derivation will be built.
231
+
The extension of <envar>PATH</envar> with dependencies, alluded to above,
232
+
proceeds according to the relative platforms alone. The process is carried
233
+
out only for dependencies whose host platform matches the new derivation's
234
+
build platform i.e. dependencies which run on the platform where the new
235
+
derivation will be built.
<footnote xml:id="footnote-stdenv-native-dependencies-in-path">
238
-
Currently, this means for native builds all dependencies are put
239
-
on the <envar>PATH</envar>. But in the future that may not be the
240
-
case for sake of matching cross: the platforms would be assumed
241
-
to be unique for native and cross builds alike, so only the
242
-
<varname>depsBuild*</varname> and
238
+
Currently, this means for native builds all dependencies are put on the
239
+
<envar>PATH</envar>. But in the future that may not be the case for sake
240
+
of matching cross: the platforms would be assumed to be unique for native
241
+
and cross builds alike, so only the <varname>depsBuild*</varname> and
<varname>nativeBuildInputs</varname> would be added to the
···
The dependency is propagated when it forces some of its other-transitive
(non-immediate) downstream dependencies to also take it on as an immediate
255
-
dependency. Nix itself already takes a package's transitive dependencies into
256
-
account, but this propagation ensures nixpkgs-specific infrastructure like
257
-
setup hooks (mentioned above) also are run as if the propagated dependency.
254
+
dependency. Nix itself already takes a package's transitive dependencies
255
+
into account, but this propagation ensures nixpkgs-specific infrastructure
256
+
like setup hooks (mentioned above) also are run as if the propagated
···
described by the current dependency's platform offsets. This results in sort
a transitive closure of the dependency relation, with the offsets being
approximately summed when two dependency links are combined. We also prune
273
-
transitive dependencies whose combined offsets go out-of-bounds, which can be
274
-
viewed as a filter over that transitive closure removing dependencies that
275
-
are blatantly absurd.
273
+
transitive dependencies whose combined offsets go out-of-bounds, which can
274
+
be viewed as a filter over that transitive closure removing dependencies
275
+
that are blatantly absurd.
···
290
-
They're confusing in very different ways so... hopefully if something doesn't
291
-
make sense in one presentation, it will in the other!
290
+
They're confusing in very different ways so... hopefully if something
291
+
doesn't make sense in one presentation, it will in the other!
let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
···
let f(h, h + 1, i) = i + (if i <= 0 then h else h)
let f(h, h + 1, i) = i + h
327
-
This is where "sum-like" comes in from above: We can just sum all of the host
328
-
offsets to get the host offset of the transitive dependency. The target
329
-
offset is the transitive dependency is simply the host offset + 1, just as it
330
-
was with the dependencies composed to make this transitive one; it can be
327
+
This is where "sum-like" comes in from above: We can just sum all of the
328
+
host offsets to get the host offset of the transitive dependency. The target
329
+
offset is the transitive dependency is simply the host offset + 1, just as
330
+
it was with the dependencies composed to make this transitive one; it can be
ignored as it doesn't add any new information.
335
-
Because of the bounds checks, the uncommon cases are <literal>h = t</literal>
336
-
and <literal>h + 2 = t</literal>. In the former case, the motivation for
337
-
<function>mapOffset</function> is that since its host and target platforms
338
-
are the same, no transitive dependency of it should be able to "discover" an
339
-
offset greater than its reduced target offsets.
335
+
Because of the bounds checks, the uncommon cases are <literal>h =
336
+
t</literal> and <literal>h + 2 = t</literal>. In the former case, the
337
+
motivation for <function>mapOffset</function> is that since its host and
338
+
target platforms are the same, no transitive dependency of it should be able
339
+
to "discover" an offset greater than its reduced target offsets.
<function>mapOffset</function> effectively "squashes" all its transitive
dependencies' offsets so that none will ever be greater than the target
offset of the original <literal>h = t</literal> package. In the other case,
343
-
<literal>h + 1</literal> is skipped over between the host and target offsets.
344
-
Instead of squashing the offsets, we need to "rip" them apart so no
343
+
<literal>h + 1</literal> is skipped over between the host and target
344
+
offsets. Instead of squashing the offsets, we need to "rip" them apart so no
transitive dependencies' offset is that one.
349
-
Overall, the unifying theme here is that propagation shouldn't be introducing
350
-
transitive dependencies involving platforms the depending package is unaware
351
-
of. The offset bounds checking and definition of
349
+
Overall, the unifying theme here is that propagation shouldn't be
350
+
introducing transitive dependencies involving platforms the depending
351
+
package is unaware of. The offset bounds checking and definition of
<function>mapOffset</function> together ensure that this is the case.
Discovering a new offset is discovering a new platform, and since those
platforms weren't in the derivation "spec" of the needing package, they
···
Since these packages are able to be run at build-time, they are always
added to the <envar>PATH</envar>, as described above. But since these
packages are only guaranteed to be able to run then, they shouldn't
384
-
persist as run-time dependencies. This isn't currently enforced, but could
384
+
persist as run-time dependencies. This isn't currently enforced, but
385
+
could be in the future.
···
platform, and target platform is the new derivation's host platform. This
means a <literal>-1</literal> host offset and <literal>0</literal> target
offset from the new derivation's platforms. These are programs and
399
-
libraries used at build-time that, if they are a compiler or similar tool,
400
-
produce code to run at run-time—i.e. tools used to build the new
401
-
derivation. If the dependency doesn't care about the target platform (i.e.
402
-
isn't a compiler or similar tool), put it here, rather than in
399
+
libraries used at build-time that, if they are a compiler or similar
400
+
tool, produce code to run at run-time—i.e. tools used to build the new
401
+
derivation. If the dependency doesn't care about the target platform
402
+
(i.e. isn't a compiler or similar tool), put it here, rather than in
<varname>depsBuildBuild</varname> or <varname>depsBuildTarget</varname>.
This could be called <varname>depsBuildHost</varname> but
<varname>nativeBuildInputs</varname> is used for historical continuity.
···
Since these packages are able to be run at build-time, they are added to
the <envar>PATH</envar>, as described above. But since these packages are
410
-
only guaranteed to be able to run then, they shouldn't persist as run-time
411
-
dependencies. This isn't currently enforced, but could be in the future.
410
+
only guaranteed to be able to run then, they shouldn't persist as
411
+
run-time dependencies. This isn't currently enforced, but could be in the
···
A list of dependencies whose host platform is the new derivation's build
platform, and target platform is the new derivation's target platform.
This means a <literal>-1</literal> host offset and <literal>1</literal>
424
-
target offset from the new derivation's platforms. These are programs used
425
-
at build time that produce code to run with code produced by the depending
426
-
package. Most commonly, these are tools used to build the runtime or
427
-
standard library that the currently-being-built compiler will inject into
428
-
any code it compiles. In many cases, the currently-being-built-compiler is
429
-
itself employed for that task, but when that compiler won't run (i.e. its
430
-
build and host platform differ) this is not possible. Other times, the
431
-
compiler relies on some other tool, like binutils, that is always built
432
-
separately so that the dependency is unconditional.
425
+
target offset from the new derivation's platforms. These are programs
426
+
used at build time that produce code to run with code produced by the
427
+
depending package. Most commonly, these are tools used to build the
428
+
runtime or standard library that the currently-being-built compiler will
429
+
inject into any code it compiles. In many cases, the
430
+
currently-being-built-compiler is itself employed for that task, but when
431
+
that compiler won't run (i.e. its build and host platform differ) this is
432
+
not possible. Other times, the compiler relies on some other tool, like
433
+
binutils, that is always built separately so that the dependency is
This is a somewhat confusing concept to wrap one’s head around, and for
good reason. As the only dependency type where the platform offsets are
not adjacent integers, it requires thinking of a bootstrapping stage
438
-
<emphasis>two</emphasis> away from the current one. It and its use-case go
439
-
hand in hand and are both considered poor form: try to not need this sort
440
-
of dependency, and try to avoid building standard libraries and runtimes
441
-
in the same derivation as the compiler produces code using them. Instead
442
-
strive to build those like a normal library, using the newly-built
443
-
compiler just as a normal library would. In short, do not use this
444
-
attribute unless you are packaging a compiler and are sure it is needed.
440
+
<emphasis>two</emphasis> away from the current one. It and its use-case
441
+
go hand in hand and are both considered poor form: try to not need this
442
+
sort of dependency, and try to avoid building standard libraries and
443
+
runtimes in the same derivation as the compiler produces code using them.
444
+
Instead strive to build those like a normal library, using the
445
+
newly-built compiler just as a normal library would. In short, do not use
446
+
this attribute unless you are packaging a compiler and are sure it is
Since these packages are able to run at build time, they are added to the
448
-
<envar>PATH</envar>, as described above. But since these packages are only
449
-
guaranteed to be able to run then, they shouldn't persist as run-time
450
-
dependencies. This isn't currently enforced, but could be in the future.
451
+
<envar>PATH</envar>, as described above. But since these packages are
452
+
only guaranteed to be able to run then, they shouldn't persist as
453
+
run-time dependencies. This isn't currently enforced, but could be in the
···
and <literal>0</literal> target offset from the new derivation's host
platform. These are packages used at run-time to generate code also used
at run-time. In practice, this would usually be tools used by compilers
465
-
for macros or a metaprogramming system, or libraries used by the macros or
466
-
metaprogramming code itself. It's always preferable to use a
467
-
<varname>depsBuildBuild</varname> dependency in the derivation being built
468
-
over a <varname>depsHostHost</varname> on the tool doing the building for
469
+
for macros or a metaprogramming system, or libraries used by the macros
470
+
or metaprogramming code itself. It's always preferable to use a
471
+
<varname>depsBuildBuild</varname> dependency in the derivation being
472
+
built over a <varname>depsHostHost</varname> on the tool doing the
473
+
building for this purpose.
···
<literal>1</literal> target offset from the new derivation's host
platform. This would be called <varname>depsHostTarget</varname> but for
historical continuity. If the dependency doesn't care about the target
484
-
platform (i.e. isn't a compiler or similar tool), put it here, rather than
485
-
in <varname>depsBuildBuild</varname>.
488
+
platform (i.e. isn't a compiler or similar tool), put it here, rather
489
+
than in <varname>depsBuildBuild</varname>.
These are often programs and libraries used by the new derivation at
···
<literal>hello.baz.value1</literal>. We don't specify any usage or schema
of <literal>passthru</literal> - it is meant for values that would be
useful outside the derivation in other parts of a Nix expression (e.g. in
667
-
other derivations). An example would be to convey some specific dependency
668
-
of your derivation which contains a program with plugins support. Later,
669
-
others who make derivations with plugins can use passed-through dependency
670
-
to ensure that their plugin would be binary-compatible with built program.
671
+
other derivations). An example would be to convey some specific
672
+
dependency of your derivation which contains a program with plugins
673
+
support. Later, others who make derivations with plugins can use
674
+
passed-through dependency to ensure that their plugin would be
675
+
binary-compatible with built program.
···
680
-
A script to be run by <filename>maintainers/scripts/update.nix</filename> when
681
-
the package is matched. It needs to be an executable file, either on the file
685
+
A script to be run by <filename>maintainers/scripts/update.nix</filename>
686
+
when the package is matched. It needs to be an executable file, either on
passthru.updateScript = ./update.sh;
···
update-source-version zoom-us "$version"
698
-
The attribute can also contain a list, a script followed by arguments to be passed to it:
703
+
The attribute can also contain a list, a script followed by arguments to
passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
702
-
Note that the update scripts will be run in parallel by default; you should avoid running <command>git commit</command> or any other commands that cannot handle that.
708
+
Note that the update scripts will be run in parallel by default; you
709
+
should avoid running <command>git commit</command> or any other commands
710
+
that cannot handle that.
For information about how to run the updates, execute
707
-
<cmdsynopsis><command>nix-shell</command> <arg>maintainers/scripts/update.nix</arg></cmdsynopsis>.
715
+
<command>nix-shell</command>
717
+
maintainers/scripts/update.nix
···
By default, when cross compiling, the configure script has
<option>--build=...</option> and <option>--host=...</option> passed.
Packages can instead pass <literal>[ "build" "host" "target" ]</literal>
1181
-
or a subset to control exactly which platform flags are passed. Compilers
1182
-
and other tools can use this to also pass the target platform.
1194
+
or a subset to control exactly which platform flags are passed.
1195
+
Compilers and other tools can use this to also pass the target platform.
<footnote xml:id="footnote-stdenv-build-time-guessing-impurity">
Eventually these will be passed building natively as well, to improve
···
1697
-
A package can export a <link linkend="ssec-setup-hooks">setup hook</link>
1698
-
by setting this variable. The setup hook, if defined, is copied to
1699
-
<filename>$out/nix-support/setup-hook</filename>. Environment variables
1700
-
are then substituted in it using <function
1710
+
A package can export a <link linkend="ssec-setup-hooks">setup
1711
+
hook</link> by setting this variable. The setup hook, if defined, is
1712
+
copied to <filename>$out/nix-support/setup-hook</filename>. Environment
1713
+
variables are then substituted in it using
linkend="fun-substituteAll">substituteAll</function>.
···
A list of dependencies used by the phase. This gets included in
1815
-
<varname>nativeBuildInputs</varname> when <varname>doInstallCheck</varname> is
1829
+
<varname>nativeBuildInputs</varname> when
1830
+
<varname>doInstallCheck</varname> is set.
···
dependency derivation is already built just the same—depending is just
needing something to exist, and needing is idempotent. However, a dependency
specified twice will have its setup hook run twice, and that could easily
2163
-
change the build environment (though a well-written setup hook will therefore
2164
-
strive to be idempotent so this is in fact not observable). More broadly,
2165
-
setup hooks are anti-modular in that multiple dependencies, whether the same
2166
-
or different, should not interfere and yet their setup hooks may well do so.
2177
+
change the build environment (though a well-written setup hook will
2178
+
therefore strive to be idempotent so this is in fact not observable). More
2179
+
broadly, setup hooks are anti-modular in that multiple dependencies, whether
2180
+
the same or different, should not interfere and yet their setup hooks may
···
Returning to the C compiler wrapper example, if the wrapper itself is an
<literal>n</literal> dependency, then it only wants to accumulate flags from
<literal>n + 1</literal> dependencies, as only those ones match the
2188
-
compiler's target platform. The <envar>hostOffset</envar> variable is defined
2189
-
with the current dependency's host offset <envar>targetOffset</envar> with
2190
-
its target offset, before its setup hook is sourced. Additionally, since most
2191
-
environment hooks don't care about the target platform, that means the setup
2192
-
hook can append to the right bash array by doing something like
2203
+
compiler's target platform. The <envar>hostOffset</envar> variable is
2204
+
defined with the current dependency's host offset
2205
+
<envar>targetOffset</envar> with its target offset, before its setup hook is
2206
+
sourced. Additionally, since most environment hooks don't care about the
2207
+
target platform, that means the setup hook can append to the right bash
2208
+
array by doing something like
<programlisting language="bash">
addEnvHooks "$hostOffset" myBashFunction
···
2207
-
First, let’s cover some setup hooks that are part of Nixpkgs
2208
-
default stdenv. This means that they are run for every package
2209
-
built using <function>stdenv.mkDerivation</function>. Some of
2210
-
these are platform specific, so they may run on Linux but not
2211
-
Darwin or vice-versa.
2223
+
First, let’s cover some setup hooks that are part of Nixpkgs default
2224
+
stdenv. This means that they are run for every package built using
2225
+
<function>stdenv.mkDerivation</function>. Some of these are platform
2226
+
specific, so they may run on Linux but not Darwin or vice-versa.
<literal>move-docs.sh</literal>
This setup hook moves any installed documentation to the
2220
-
<literal>/share</literal> subdirectory directory. This includes
2221
-
the man, doc and info directories. This is needed for legacy
2222
-
programs that do not know how to use the
2223
-
<literal>share</literal> subdirectory.
2235
+
<literal>/share</literal> subdirectory directory. This includes the man,
2236
+
doc and info directories. This is needed for legacy programs that do not
2237
+
know how to use the <literal>share</literal> subdirectory.
···
<literal>compress-man-pages.sh</literal>
2233
-
This setup hook compresses any man pages that have been
2234
-
installed. The compression is done using the gzip program. This
2235
-
helps to reduce the installed size of packages.
2247
+
This setup hook compresses any man pages that have been installed. The
2248
+
compression is done using the gzip program. This helps to reduce the
2249
+
installed size of packages.
···
<literal>strip.sh</literal>
2245
-
This runs the strip command on installed binaries and
2246
-
libraries. This removes unnecessary information like debug
2247
-
symbols when they are not needed. This also helps to reduce the
2248
-
installed size of packages.
2259
+
This runs the strip command on installed binaries and libraries. This
2260
+
removes unnecessary information like debug symbols when they are not
2261
+
needed. This also helps to reduce the installed size of packages.
···
<literal>patch-shebangs.sh</literal>
2258
-
This setup hook patches installed scripts to use the full path
2259
-
to the shebang interpreter. A shebang interpreter is the first
2260
-
commented line of a script telling the operating system which
2261
-
program will run the script (e.g <literal>#!/bin/bash</literal>). In
2262
-
Nix, we want an exact path to that interpreter to be used. This
2263
-
often replaces <literal>/bin/sh</literal> with a path in the
2271
+
This setup hook patches installed scripts to use the full path to the
2272
+
shebang interpreter. A shebang interpreter is the first commented line
2273
+
of a script telling the operating system which program will run the
2274
+
script (e.g <literal>#!/bin/bash</literal>). In Nix, we want an exact
2275
+
path to that interpreter to be used. This often replaces
2276
+
<literal>/bin/sh</literal> with a path in the Nix store.
···
<literal>audit-tmpdir.sh</literal>
2274
-
This verifies that no references are left from the install
2275
-
binaries to the directory used to build those binaries. This
2276
-
ensures that the binaries do not need things outside the Nix
2277
-
store. This is currently supported in Linux only.
2286
+
This verifies that no references are left from the install binaries to
2287
+
the directory used to build those binaries. This ensures that the
2288
+
binaries do not need things outside the Nix store. This is currently
2289
+
supported in Linux only.
···
<literal>multiple-outputs.sh</literal>
2287
-
This setup hook adds configure flags that tell packages to
2288
-
install files into any one of the proper outputs listed in
2289
-
<literal>outputs</literal>. This behavior can be turned off by setting
2299
+
This setup hook adds configure flags that tell packages to install files
2300
+
into any one of the proper outputs listed in <literal>outputs</literal>.
2301
+
This behavior can be turned off by setting
<literal>setOutputFlags</literal> to false in the derivation
2291
-
environment. See <xref linkend="chap-multiple-output"/> for
2303
+
environment. See <xref linkend="chap-multiple-output"/> for more
···
<literal>move-sbin.sh</literal>
2302
-
This setup hook moves any binaries installed in the sbin
2303
-
subdirectory into bin. In addition, a link is provided from
2304
-
sbin to bin for compatibility.
2314
+
This setup hook moves any binaries installed in the sbin subdirectory
2315
+
into bin. In addition, a link is provided from sbin to bin for
···
<literal>move-lib64.sh</literal>
2314
-
This setup hook moves any libraries installed in the lib64
2315
-
subdirectory into lib. In addition, a link is provided from
2316
-
lib64 to lib for compatibility.
2326
+
This setup hook moves any libraries installed in the lib64 subdirectory
2327
+
into lib. In addition, a link is provided from lib64 to lib for
···
<literal>set-source-date-epoch-to-latest.sh</literal>
2326
-
This sets <literal>SOURCE_DATE_EPOCH</literal> to the
2327
-
modification time of the most recent file.
2338
+
This sets <literal>SOURCE_DATE_EPOCH</literal> to the modification time
2339
+
of the most recent file.
···
The Bintools Wrapper wraps the binary utilities for a bunch of
2338
-
miscellaneous purposes. These are GNU Binutils when targetting Linux, and
2339
-
a mix of cctools and GNU binutils for Darwin. [The "Bintools" name is
2340
-
supposed to be a compromise between "Binutils" and "cctools" not denoting
2341
-
any specific implementation.] Specifically, the underlying bintools
2342
-
package, and a C standard library (glibc or Darwin's libSystem, just for
2343
-
the dynamic loader) are all fed in, and dependency finding, hardening
2344
-
(see below), and purity checks for each are handled by the Bintools
2345
-
Wrapper. Packages typically depend on CC Wrapper, which in turn (at run
2346
-
time) depends on the Bintools Wrapper.
2350
+
miscellaneous purposes. These are GNU Binutils when targetting Linux,
2351
+
and a mix of cctools and GNU binutils for Darwin. [The "Bintools" name
2352
+
is supposed to be a compromise between "Binutils" and "cctools" not
2353
+
denoting any specific implementation.] Specifically, the underlying
2354
+
bintools package, and a C standard library (glibc or Darwin's libSystem,
2355
+
just for the dynamic loader) are all fed in, and dependency finding,
2356
+
hardening (see below), and purity checks for each are handled by the
2357
+
Bintools Wrapper. Packages typically depend on CC Wrapper, which in turn
2358
+
(at run time) depends on the Bintools Wrapper.
2349
-
The Bintools Wrapper was only just recently split off from CC Wrapper, so
2350
-
the division of labor is still being worked out. For example, it
2361
+
The Bintools Wrapper was only just recently split off from CC Wrapper,
2362
+
so the division of labor is still being worked out. For example, it
shouldn't care about about the C standard library, but just take a
derivation with the dynamic loader (which happens to be the glibc on
linux). Dependency finding however is a task both wrappers will continue
···
<varname>nativeBuildInputs</varname>) in environment variables. The
Bintools Wrapper's setup hook causes any <filename>lib</filename> and
<filename>lib64</filename> subdirectories to be added to
2360
-
<envar>NIX_LDFLAGS</envar>. Since the CC Wrapper and the Bintools Wrapper
2361
-
use the same strategy, most of the Bintools Wrapper code is sparsely
2362
-
commented and refers to the CC Wrapper. But the CC Wrapper's code, by
2363
-
contrast, has quite lengthy comments. The Bintools Wrapper merely cites
2364
-
those, rather than repeating them, to avoid falling out of sync.
2372
+
<envar>NIX_LDFLAGS</envar>. Since the CC Wrapper and the Bintools
2373
+
Wrapper use the same strategy, most of the Bintools Wrapper code is
2374
+
sparsely commented and refers to the CC Wrapper. But the CC Wrapper's
2375
+
code, by contrast, has quite lengthy comments. The Bintools Wrapper
2376
+
merely cites those, rather than repeating them, to avoid falling out of
A final task of the setup hook is defining a number of standard
···
under the assumption that the Bintools Wrapper's binaries will be on the
path. Firstly, this helps poorly-written packages, e.g. ones that look
for just <command>gcc</command> when <envar>CC</envar> isn't defined yet
2373
-
<command>clang</command> is to be used. Secondly, this helps packages not
2374
-
get confused when cross-compiling, in which case multiple Bintools
2386
+
<command>clang</command> is to be used. Secondly, this helps packages
2387
+
not get confused when cross-compiling, in which case multiple Bintools
Wrappers may simultaneously be in use.
<footnote xml:id="footnote-stdenv-per-platform-wrapper">
···
Wrappers, properly disambiguating them.
2390
-
A problem with this final task is that the Bintools Wrapper is honest and
2391
-
defines <envar>LD</envar> as <command>ld</command>. Most packages,
2403
+
A problem with this final task is that the Bintools Wrapper is honest
2404
+
and defines <envar>LD</envar> as <command>ld</command>. Most packages,
however, firstly use the C compiler for linking, secondly use
<envar>LD</envar> anyways, defining it as the C compiler, and thirdly,
2394
-
only so define <envar>LD</envar> when it is undefined as a fallback. This
2395
-
triple-threat means Bintools Wrapper will break those packages, as LD is
2396
-
already defined as the actual linker which the package won't override yet
2397
-
doesn't want to use. The workaround is to define, just for the
2398
-
problematic package, <envar>LD</envar> as the C compiler. A good way to
2399
-
do this would be <command>preConfigure = "LD=$CC"</command>.
2407
+
only so define <envar>LD</envar> when it is undefined as a fallback.
2408
+
This triple-threat means Bintools Wrapper will break those packages, as
2409
+
LD is already defined as the actual linker which the package won't
2410
+
override yet doesn't want to use. The workaround is to define, just for
2411
+
the problematic package, <envar>LD</envar> as the C compiler. A good way
2412
+
to do this would be <command>preConfigure = "LD=$CC"</command>.
···
2409
-
The CC Wrapper wraps a C toolchain for a bunch of miscellaneous purposes.
2410
-
Specifically, a C compiler (GCC or Clang), wrapped binary tools, and a C
2411
-
standard library (glibc or Darwin's libSystem, just for the dynamic
2412
-
loader) are all fed in, and dependency finding, hardening (see below),
2413
-
and purity checks for each are handled by the CC Wrapper. Packages
2414
-
typically depend on the CC Wrapper, which in turn (at run-time) depends
2415
-
on the Bintools Wrapper.
2422
+
The CC Wrapper wraps a C toolchain for a bunch of miscellaneous
2423
+
purposes. Specifically, a C compiler (GCC or Clang), wrapped binary
2424
+
tools, and a C standard library (glibc or Darwin's libSystem, just for
2425
+
the dynamic loader) are all fed in, and dependency finding, hardening
2426
+
(see below), and purity checks for each are handled by the CC Wrapper.
2427
+
Packages typically depend on the CC Wrapper, which in turn (at run-time)
2428
+
depends on the Bintools Wrapper.
Dependency finding is undoubtedly the main task of the CC Wrapper. This
···
2441
-
Here are some more packages that provide a setup hook. Since the
2442
-
list of hooks is extensible, this is not an exhaustive list the
2443
-
mechanism is only to be used as a last resort, it might cover most
2454
+
Here are some more packages that provide a setup hook. Since the list of
2455
+
hooks is extensible, this is not an exhaustive list the mechanism is only to
2456
+
be used as a last resort, it might cover most uses.
···
The <varname>autoreconfHook</varname> derivation adds
2502
-
<varname>autoreconfPhase</varname>, which runs autoreconf, libtoolize and
2503
-
automake, essentially preparing the configure script in autotools-based
2504
-
builds. Most autotools-based packages come with the configure script
2505
-
pre-generated, but this hook is necessary for a few packages and when you
2506
-
need to patch the package’s configure scripts.
2514
+
<varname>autoreconfPhase</varname>, which runs autoreconf, libtoolize
2515
+
and automake, essentially preparing the configure script in
2516
+
autotools-based builds. Most autotools-based packages come with the
2517
+
configure script pre-generated, but this hook is necessary for a few
2518
+
packages and when you need to patch the package’s configure scripts.
···
2550
-
Exports <envar>GDK_PIXBUF_MODULE_FILE</envar> environment variable to the
2551
-
builder. Add librsvg package to <varname>buildInputs</varname> to get svg
2562
+
Exports <envar>GDK_PIXBUF_MODULE_FILE</envar> environment variable to
2563
+
the builder. Add librsvg package to <varname>buildInputs</varname> to
···
This is useful for programs that use <citerefentry>
2597
-
<refentrytitle>dlopen</refentrytitle>
2598
-
<manvolnum>3</manvolnum>
2599
-
</citerefentry> to load libraries at runtime.
2609
+
<refentrytitle>dlopen</refentrytitle>
2610
+
<manvolnum>3</manvolnum> </citerefentry> to load libraries at runtime.
2602
-
In certain situations you may want to run the main command
2603
-
(<command>autoPatchelf</command>) of the setup hook on a file or a set
2604
-
of directories instead of unconditionally patching all outputs. This
2605
-
can be done by setting the <envar>dontAutoPatchelf</envar> environment
2606
-
variable to a non-empty value.
2613
+
In certain situations you may want to run the main command
2614
+
(<command>autoPatchelf</command>) of the setup hook on a file or a set
2615
+
of directories instead of unconditionally patching all outputs. This can
2616
+
be done by setting the <envar>dontAutoPatchelf</envar> environment
2617
+
variable to a non-empty value.
2609
-
The <command>autoPatchelf</command> command also recognizes a
2610
-
<parameter class="command">--no-recurse</parameter> command line flag,
2611
-
which prevents it from recursing into subdirectories.
2620
+
The <command>autoPatchelf</command> command also recognizes a
2621
+
<parameter class="command">--no-recurse</parameter> command line flag,
2622
+
which prevents it from recursing into subdirectories.
···
This hook will make a build pause instead of stopping when a failure
2622
-
happens. It prevents nix from cleaning up the build environment immediately and
2623
-
allows the user to attach to a build environment using the
2624
-
<command>cntr</command> command. Upon build error it will print
2625
-
instructions on how to use <command>cntr</command>. Installing
2626
-
cntr and running the command will provide shell access to the build
2627
-
sandbox of failed build. At <filename>/var/lib/cntr</filename> the
2628
-
sandboxed filesystem is mounted. All commands and files of the system are
2629
-
still accessible within the shell. To execute commands from the sandbox
2630
-
use the cntr exec subcommand. Note that <command>cntr</command> also
2631
-
needs to be executed on the machine that is doing the build, which might
2632
-
not be the case when remote builders are enabled.
2633
-
<command>cntr</command> is only supported on Linux-based platforms. To
2634
-
use it first add <literal>cntr</literal> to your
2635
-
<literal>environment.systemPackages</literal> on NixOS or alternatively to
2636
-
the root user on non-NixOS systems. Then in the package that is supposed
2637
-
to be inspected, add <literal>breakpointHook</literal> to
2633
+
happens. It prevents nix from cleaning up the build environment
2634
+
immediately and allows the user to attach to a build environment using
2635
+
the <command>cntr</command> command. Upon build error it will print
2636
+
instructions on how to use <command>cntr</command>. Installing cntr and
2637
+
running the command will provide shell access to the build sandbox of
2638
+
failed build. At <filename>/var/lib/cntr</filename> the sandboxed
2639
+
filesystem is mounted. All commands and files of the system are still
2640
+
accessible within the shell. To execute commands from the sandbox use
2641
+
the cntr exec subcommand. Note that <command>cntr</command> also needs
2642
+
to be executed on the machine that is doing the build, which might not
2643
+
be the case when remote builders are enabled. <command>cntr</command> is
2644
+
only supported on Linux-based platforms. To use it first add
2645
+
<literal>cntr</literal> to your
2646
+
<literal>environment.systemPackages</literal> on NixOS or alternatively
2647
+
to the root user on non-NixOS systems. Then in the package that is
2648
+
supposed to be inspected, add <literal>breakpointHook</literal> to
<literal>nativeBuildInputs</literal>.
nativeBuildInputs = [ breakpointHook ];
···
2653
-
A few libraries automatically add to
2654
-
<literal>NIX_LDFLAGS</literal> their library, making their
2655
-
symbols automatically available to the linker. This includes
2656
-
libiconv and libintl (gettext). This is done to provide
2657
-
compatibility between GNU Linux, where libiconv and libintl
2658
-
are bundled in, and other systems where that might not be the
2659
-
case. Sometimes, this behavior is not desired. To disable
2660
-
this behavior, set <literal>dontAddExtraLibs</literal>.
2664
+
A few libraries automatically add to <literal>NIX_LDFLAGS</literal>
2665
+
their library, making their symbols automatically available to the
2666
+
linker. This includes libiconv and libintl (gettext). This is done to
2667
+
provide compatibility between GNU Linux, where libiconv and libintl are
2668
+
bundled in, and other systems where that might not be the case.
2669
+
Sometimes, this behavior is not desired. To disable this behavior, set
2670
+
<literal>dontAddExtraLibs</literal>.
···
2670
-
Overrides the default configure phase to run the CMake command. By
2671
-
default, we use the Make generator of CMake. In
2672
-
addition, dependencies are added automatically to CMAKE_PREFIX_PATH so
2673
-
that packages are correctly detected by CMake. Some additional flags
2674
-
are passed in to give similar behavior to configure-based packages. You
2675
-
can disable this hook’s behavior by setting configurePhase to a custom
2676
-
value, or by setting dontUseCmakeConfigure. cmakeFlags controls flags
2677
-
passed only to CMake. By default, parallel building is enabled as CMake
2678
-
supports parallel building almost everywhere. When Ninja is also in
2679
-
use, CMake will detect that and use the ninja generator.
2680
+
Overrides the default configure phase to run the CMake command. By
2681
+
default, we use the Make generator of CMake. In addition, dependencies
2682
+
are added automatically to CMAKE_PREFIX_PATH so that packages are
2683
+
correctly detected by CMake. Some additional flags are passed in to give
2684
+
similar behavior to configure-based packages. You can disable this
2685
+
hook’s behavior by setting configurePhase to a custom value, or by
2686
+
setting dontUseCmakeConfigure. cmakeFlags controls flags passed only to
2687
+
CMake. By default, parallel building is enabled as CMake supports
2688
+
parallel building almost everywhere. When Ninja is also in use, CMake
2689
+
will detect that and use the ninja generator.
···
2689
-
Overrides the build and install phases to run the “xcbuild” command.
2690
-
This hook is needed when a project only comes with build files for the
2691
-
XCode build system. You can disable this behavior by setting buildPhase
2692
-
and configurePhase to a custom value. xcbuildFlags controls flags
2693
-
passed only to xcbuild.
2699
+
Overrides the build and install phases to run the “xcbuild” command.
2700
+
This hook is needed when a project only comes with build files for the
2701
+
XCode build system. You can disable this behavior by setting buildPhase
2702
+
and configurePhase to a custom value. xcbuildFlags controls flags passed
···
2703
-
Overrides the configure phase to run meson to generate Ninja files. You
2704
-
can disable this behavior by setting configurePhase to a custom value,
2705
-
or by setting dontUseMesonConfigure. To run these files, you should
2706
-
accompany meson with ninja. mesonFlags controls only the flags passed
2707
-
to meson. By default, parallel building is enabled as Meson supports
2708
-
parallel building almost everywhere.
2713
+
Overrides the configure phase to run meson to generate Ninja files. You
2714
+
can disable this behavior by setting configurePhase to a custom value,
2715
+
or by setting dontUseMesonConfigure. To run these files, you should
2716
+
accompany meson with ninja. mesonFlags controls only the flags passed to
2717
+
meson. By default, parallel building is enabled as Meson supports
2718
+
parallel building almost everywhere.
···
2718
-
Overrides the build, install, and check phase to run ninja instead of
2719
-
make. You can disable this behavior with the dontUseNinjaBuild,
2720
-
dontUseNinjaInstall, and dontUseNinjaCheck, respectively. Parallel
2721
-
building is enabled by default in Ninja.
2728
+
Overrides the build, install, and check phase to run ninja instead of
2729
+
make. You can disable this behavior with the dontUseNinjaBuild,
2730
+
dontUseNinjaInstall, and dontUseNinjaCheck, respectively. Parallel
2731
+
building is enabled by default in Ninja.
···
2731
-
This setup hook will allow you to unzip .zip files specified in $src.
2732
-
There are many similar packages like unrar, undmg, etc.
2741
+
This setup hook will allow you to unzip .zip files specified in $src.
2742
+
There are many similar packages like unrar, undmg, etc.
···
2742
-
Overrides the configure, build, and install phases. This will run the
2743
-
"waf" script used by many projects. If waf doesn’t exist, it will copy
2744
-
the version of waf available in Nixpkgs wafFlags can be used to pass
2745
-
flags to the waf script.
2752
+
Overrides the configure, build, and install phases. This will run the
2753
+
"waf" script used by many projects. If waf doesn’t exist, it will copy
2754
+
the version of waf available in Nixpkgs wafFlags can be used to pass
2755
+
flags to the waf script.
···
2755
-
Overrides the build, install, and check phases. This uses the scons
2756
-
build system as a replacement for make. scons does not provide a
2757
-
configure phase, so everything is managed at build and install time.
2765
+
Overrides the build, install, and check phases. This uses the scons
2766
+
build system as a replacement for make. scons does not provide a
2767
+
configure phase, so everything is managed at build and install time.
<section xml:id="sec-purity-in-nixpkgs">
pyrox.dev