• Daniel P. Berrange's avatar
    make: move top level dir to end of include search path · ba78db44
    Daniel P. Berrange authored
    
    
    Currently the search path is
    
      1. source dir corresponding to input file (implicit by compiler)
      2. top level build dir
      3. top level source dir
      4. top level source include/ dir
      5. source dir corresponding to input file
      6. build dir corresponding to output file
    
    Search item 5 is an effective no-op, since it duplicates item 1.
    When srcdir == builddir, item 6 also duplicates item 1, which
    causes a semantic difference between VPATH and non-VPATH builds.
    
    Thus to ensure consistent semantics we need item 6 to be present
    immediately after item 1. e.g.
    
      1. source dir corresponding to input file (implicit by compiler)
      2. build dir corresponding to output file
      3. top level build dir
      4. top level source dir
      5. top level source include/ dir
    
    When srcdir == builddir, items 1 & 2 collapse into one, and items
    3 & 4 collapse into one, but the overall search order is still
    consistent with srcdir != builddir
    
    A further complication is that while most of the source files
    are built with a current directory of $BUILD_DIR, target dependant
    files are built with a current directory of $BUILD_DIR/$TARGET.
    
    As a result, search item 2 resolves to a different location for
    target independant vs target dependant files. For example when
    building 'migration/ram.o', the use of '-I$(@D)' (which expands
    to '-Imigration') would not find '$BUILD_DIR/migration', but
    rather '$BUILD_DIR/$TARGET/migration'.
    
    If there are generated headers files to be used by the migration
    code in '$BUILD_DIR/migration', these will not be found by the
    relative include, an absolute include is needed instead. This
    has not been a problem so far, since nothing has been generating
    headers in sub-dirs, but the trace code will shortly be doing
    that. So it is needed to list '-I$(BUILD_DIR)/$(@D)' as well as
    '-I$(@D)' to ensure both directories are searched when building
    target dependant code. So the search order ends up being:
    
      1. source dir corresponding to input file (implicit by compiler)
      2. build dir corresponding to output file (absolute)
      3. build dir corresponding to output file (relative to cwd)
      4. top level build dir
      5. top level source dir
      6. top level source include/ dir
    
    One final complication is that the absolute '-I$(BUILD_DIR)/$(@D)'
    will sometimes end up pointing to a non-existant directory if
    that sub-dir does not have any target-independant files to be
    built. Rather than try to dynamically filter this, a simple
    'mkdir' ensures $(BUILD_DIR)/$(@D) is guaranteed to exist at
    all times.
    
    Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Message-id: 20170125161417.31949-2-berrange@redhat.com
    Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    ba78db44