[Nix-dev] make -jx within builds?
    Marc Weber 
    marco-oweber at gmx.de
       
    Sun May 23 18:29:41 CEST 2010
    
    
  
Hi,
I'd like to run make -j4 within a job. Some packages such as qt take
very long. So you have four cores and 3 are idle.
The only pure way allowing a -j setting was passing it as env var.
However I don't want to rebuild everything. Thus adding a
--pass-j-to-builder 4 option bypassing the hash generation will make
everything less pure - however it will be used for development only on
local machines such as mine and would be of great value to me.
I'd like to implement this feature.
Contstraints:
  - system setting to en/disable this feature (which should be used on the
    Nix build farms ?)
  - there must be a way to disable passing the -j option to some builds
    which are known to break when being compiled with make -j4.
  - the default builder must change to accept the -j option which defaults
    to 1 which will cause many rebuilds.
Questions:
How to implement the constraints?
namings (proposal):
  * nix-daemon setting to allow this:
    allow-concurrency-in-builds yes/no
  * nix-env -bj 4 ( pass env var J=4 to the builder, but don't affect
    derivation store path ) 
  * for derivations, use opt-in or opt-out? I expect most packages to
    build so I vote for opt-out (which will mean changing less code)
    So I'd call this attribute
    mkDerivation = {
      BJ_1_ONLY=1 # or maybe MAX_PER_BUILD_CONCURRENCY=1
    }
The default builder should be changed to contain this:
  J=${J:-1}
  make -j $J # run the build with given concurrency defaulting to 1
Of course neither changing NO_PER_BUILD_CONCURRENCY nor passing the -bj
option to a builder should change the hash - because you don't want to
rebuild everything.
Do you like these namings? Do you have any objections against this
experimental optional feature?
Maybe we can even make the nix-daemon touch a
$out/build-with-concurrency file containing the -bj setting to keep
track of which parts of your store path less pure - I'd even call this
dirty.
Of course this will go into stdenv-updates.
Thoughts?
Marc Weber
    
    
More information about the nix-dev
mailing list