11480 cw runs smatch before it is built

Review Request #2194 — Created July 18, 2019 and submitted

citrus
illumos-gate
master
11480
ed637bd...
general
11480 cw runs smatch before it is built

Tested building gate from a clean tree. Now all of cw, smatch, install.bin and ctf are built first, before the build environment is reported.

  • 0
  • 0
  • 1
  • 0
  • 1
Description From Last Updated
yuri.pankov
  1. Ship It!
  2. 
      
alp
  1. Ship It!
  2. 
      
domag02
  1. There is an out-of-sync comment, but otherwise LGTM.
  2. usr/src/tools/Makefile (Diff revision 1)
     
     
    This comment is outdated.
  3. 
      
citrus
ptribble
  1. This doesn't seem to work properly. Yes, it solves the problem of the build trying to report the smatch version before it's built, but I get a large amount of build noise reported in my mail_msg.

    Looking at it, the output from this build ends up as build noise for me. So I see errors for smatch itself, as well as the build output for install.bin and ctf. (Those latter 2 don't contain any errors, as far as I can tell, I just get the whole build output.)

    In terms of the change, it appears to go beyond the stated problem of smatch not being built early enough and extends it to install.bin and ctf. Is that extension necessary?

    However, I wonder if we're solving the wrong problem. We report the compiler versions because we need to know what a user has chosen as they're external to the gate. We have less need to know the version of smatch, as that's shipped in the gate itself.

    1. I've fixed the problem of build noise ending up in mail_msg. Amongst other things, one of the redirections was after 2>&1 instead of before.

      In terms of the change, it appears to go beyond the stated problem of smatch not being built early enough and extends it to install.bin and ctf. Is that extension necessary?

      No, not to fix the specific smatch problem, but it makes sense to me to build the pre-requisites together, and early, and based on what is defined in the Makefile. Otherwise nightly ends up with hacks for individual utilities and not everybody builds using the nightly that belongs to their checked out tree (although they should).

      However, I wonder if we're solving the wrong problem. We report the compiler versions because we need to know what a user has chosen as they're external to the gate. We have less need to know the version of smatch, as that's shipped in the gate itself.

      True, but it is useful to know that SHADOW_CCS was set properly in the .env file and ends up pointing to a working binary.

  2. 
      
citrus
citrus
jlevon
  1. Thanks for fixing it. It seems fine to me to go ahead and explicitly build the bootstrap first.

  2. 
      
andy_js
  1. 
      
  2. usr/src/tools/scripts/nightly.sh (Diff revision 4)
     
     
    This will never evaluate to true because tee will always exit with 0.
  3. 
      
citrus
andy_js
  1. Ship It!
  2. 
      
alp
  1. Ship It!
  2. 
      
domag02
  1. Ship It!
  2. 
      
yuri.pankov
  1. Ship It!
  2. 
      
citrus
Review request changed

Status: Closed (submitted)

yuri.pankov
  1. I think this change deserves a flag day -- I just tried to build a bit older older gate contents on a system updated with this, and using the nightly from onbld now fails:

    ==== Bootstrap build errors ====
    
    dmake: Warning: Don't know how to make target `bootstrap'
    dmake: Warning: Target `bootstrap' not remade because of errors
    
    ==== Nightly build noise ====
    
    nightly: Error: could not bootstrap tools
    
  2. 
      
Loading...