Skip to content
Snippets Groups Projects
  1. Dec 19, 2010
  2. Dec 17, 2010
    • Gaetan Nadon's avatar
      build.sh: another pass at the env variable help text · d9cc2242
      Gaetan Nadon authored
      Thanks to prior work, this opens the door to another attempt
      at improving the help text. Even until now, I was confused at what
      some of the variables were used for.
      
      These are the organizing principles I used in the hope of helping
      new contributors use build.sh and long time users who may have
      overlooked some of the available features.
      
      1- The variables are group by category, meaning the "owner" of the
      variables.
      
      2- The first line is the definition of the variable
      
      3- The second line is a hint as to what build.sh does with it
      
      4- Use the Autotools help text where it applies rather than inventing your own
      ------------------------------------------------------------------------------
      
      Environment variables specific to build.sh:
        QUIET       Do not print messages saying which checks are being made
                    Each module/components is invoked with --quite
        GITROOT     Source code repository path [git://anongit.freedesktop.org/git
      
      ]
                    Optional when using --clone to update source code before building
        CONFFLAGS   Configure options to pass to all Autoconf configure scripts
                    Refer to 'configure --help' from any module/components
        LIBDIR      Path segment under $PREFIX for libraries (e.g., lib64) [lib]
                    Used to build the font path, search libraries and packages
        FONTPATH    Path to fonts directories [$PREFIX/$LIBDIR/X11/fonts/misc/, ...]
                    Picked-up by the xserver as a value for --with-default-font-path
      
      Environment variables defined by the GNU Build System:
        DESTDIR     Path to the staging area where installed objects are relocated
        MAKE        The name of the make command [make]
        MAKEFLAGS:  Options to pass to all $(MAKE) invocations
        CC          C compiler command
        CFLAGS      C compiler flags
        LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
                    nonstandard directory <lib dir>
        CPPFLAGS    C/C++/Objective C preprocessor flags, e.g. -I<include dir> if
                    you have headers in a nonstandard directory <include dir>
        CPP         C preprocessor
      
      Environment variables defined by the shell:
        PATH        List of directories that the shell searches for commands
                    $DESTDIR/$PREFIX/bin is prepended
      
      Environment variables defined by the dynamic linker:
        LD_LIBRARY_PATH List directories that the linker searches for shared objects
                        $DESTDIR/$PREFIX/$LIBDIR is prepended
      
      Environment variables defined by the pkg-config system:
        PKG_CONFIG_PATH List directories that pkg-config searches for libraries
                        $DESTDIR/$PREFIX/share/pkgconfig and
                        $DESTDIR/$PREFIX/$LIBDIR/pkgconfig are prepended
      
      Reviewed-by: default avatarTrevor Woerner <twoerner@gmail.com>
      Signed-off-by: default avatarGaetan Nadon <memsize@videotron.ca>
      d9cc2242
    • Gaetan Nadon's avatar
      build.sh: new layout and updated text for options usage · 44604e4b
      Gaetan Nadon authored
      
      ------------------------------------------------------------------------------
      Usage: build.sh [options] prefix
      Options:
        -a          Do NOT run auto config tools (autogen.sh, configure)
        -b          Use .build.unknown build directory
        -c          Run make clean in addition to "all install"
        -D          Run make dist in addition to "all install"
        -d          Run make distcheck in addition "all install"
        -g          Compile and link with debug information
        -h, --help  Display this help and exit successfully
        -n          Do not quit after error; just print error message
        -o <module/component> Build just this <module/component>
        -p          Update source code before building (git pull --rebase)
        -s <sudo>   The command name providing superuser privilege
        --autoresume <file> Append module being built to, and autoresume from, <file>
        --check     Run make check in addition "all install"
        --clone     Clone non-existing repositories (uses $GITROOT if set)
        --cmd <cmd> Execute arbitrary git, gmake, or make command <cmd>
        --modfile <file> Only process the module/components specified in <file>
      
      Usage: build.sh -L
        -L          List the components to build to stdout
      ------------------------------------------------------------------------------
      
      Reviewed-by: default avatarTrevor Woerner <twoerner@gmail.com>
      Signed-off-by: default avatarGaetan Nadon <memsize@videotron.ca>
      44604e4b
    • Gaetan Nadon's avatar
      build.sh: use the script name only, not the path in usage statement · 7649929b
      Gaetan Nadon authored
      
      If invoked from $PREFIX you currently you get:
      Usage: util/modular/build.sh [options] prefix
      
      Where you should always get:
      Usage: build.sh [options] prefix
      
      The path name is not part of the usage. The GNU compiler and
      associated tools do not use the path.
      
      Autoconf recommends using "expr" rather than "basename" for portability.
      
      Signed-off-by: default avatarGaetan Nadon <memsize@videotron.ca>
      7649929b
  3. Dec 14, 2010
    • Gaetan Nadon's avatar
      build.sh: remove CACHE env variable as it is not implementable · 78579c65
      Gaetan Nadon authored
      
      The concept of global cache for multiple modules does not exist.
      
      When using --cache-file with the same path, variables with the same
      name have their values overwritten on a "last write wins" principle.
      
      For example, this cached variable from clock:
      pkg_cv_XFT_LIBS=${pkg_cv_XFT_LIBS='-L/home/nadon/xorg/src/lib -lXft  '}
      
      is overwritten with the value from xdm:
      pkg_cv_XFT_LIBS=${pkg_cv_XFT_LIBS='
      -L/home/nadon/xorg/src/lib -lXrender -lX11 -lXft  '}
      
      If there is some limited usefulness in specific scanerios, one
      can pass the --cache-file option in CONFFLAGS.
      
      This was introduced in commit e5592f54
      to improve performance.
      
      Acked-by: default avatarTrevor Woerner <twoerner@gmail.com>
      Signed-off-by: default avatarGaetan Nadon <memsize@videotron.ca>
      78579c65
  4. Dec 13, 2010
  5. Dec 04, 2010
  6. Nov 28, 2010
  7. Nov 26, 2010
  8. Nov 23, 2010
  9. Nov 21, 2010
  10. Nov 15, 2010
  11. Nov 13, 2010
  12. Nov 12, 2010
  13. Nov 10, 2010
  14. Nov 06, 2010
  15. Nov 05, 2010
    • Simon Braunschmidt's avatar
      build.sh: verbose error output for missing components · 1a25f8bb
      Simon Braunschmidt authored and Gaetan Nadon's avatar Gaetan Nadon committed
      Instead of Trevor Woerners proposal to automagically clone missing
      components,
      
      http://lists.x.org/archives/xorg-devel/2010-November/014883.html
      
      
      
      I would rather want to inform the user more verbosely
      about missing components and how to obtain them.
      
      This could avoid situations where the user calls the build.sh script
      from the wrong location, and build.sh subsequently littering the users
      machine with unwanted git repositories in the wrong place.
      
      One such situation would be calling "somedir/build.sh L" instead of
      "somedir/build.sh -L", starting a build in the current directory
      for PREFIX "L" instead of listing the missing components (with the
      users intention having been to just list the components in build order).
      
      Signed-off-by: default avatarSimon Braunschmidt <sbraun@emlix.com>
      Signed-off-by: default avatarGaetan Nadon <memsize@videotron.ca>
      1a25f8bb
    • Simon Braunschmidt's avatar
      build.sh: allow tarballs with --modfile · 009b6bc3
      Simon Braunschmidt authored and Gaetan Nadon's avatar Gaetan Nadon committed
      
      This change allows to build from tarballs when using the new --modfile
      user-supplied sub-projects feature. Without this change, using tarballs
      was not possible with --modfile
      
      The workflow with the --modfile feature is thus changed to explicitly
      require the use of the --clone flag when automatic git clone of the
      sub-projects is wanted, which was previously assumed implicitly with
      --modfile.
      
      You may shorten the commit message as you see fit.
      Cc: xorg-devel, Trevor Woerner, Gaetan Nadon
      
      Signed-off-by: default avatarSimon Braunschmidt <sbraun@emlix.com>
      Signed-off-by: default avatarGaetan Nadon <memsize@videotron.ca>
      009b6bc3
    • Gaetan Nadon's avatar
      radeonhd is now deprecated. · d235a5bf
      Gaetan Nadon authored
      
      From radeonhd wiki:
      Status 09/2010: Linux distributions, including Novell's openSUSE,
      have now abandoned radeonhd as the default driver, instead using the
      radeon driver. radeon has more features, including Kernel Mode-Setting
      support and more 3D support, and it supports all Radeon generation
      from original R100 Radeons to R800 Radeons (HD 5000 series).
      Radeonhd can be continued to be updated as long as there are
      people find it useful.
      
      Signed-off-by: default avatarGaetan Nadon <memsize@videotron.ca>
      d235a5bf
  16. Nov 03, 2010
  17. Oct 22, 2010
  18. Oct 07, 2010
    • Trevor Woerner's avatar
      Process a user-supplied sub-project list. · bf64bab9
      Trevor Woerner authored and Gaetan Nadon's avatar Gaetan Nadon committed
      
      New feature.
      
      Using the new "--modlist <file>" option, the user can specify a file which
      contains a list of the sub-projects to process. The file can contain blank
      lines as well as comment lines which start with a hash mark (#). The
      sub-projects will be processed in the order in which they are found in the
      list file.
      
      Suggested usage:
          1. run script to generate the list of sub-projects, redirecting to a file
      	$ util/modular/build.sh -L > list
          2. edit <list>, commenting-out or deleting unnecessary lines, or adding
             new lines as appropriate
          3. run the build with this list
      	$ util/modular/build.sh --modfile list
      
      Reviewed-by: default avatarGaetan Nadon <memsize@videotron.ca>
      Signed-off-by: default avatarTrevor Woerner <twoerner@gmail.com>
      Signed-off-by: default avatarGaetan Nadon <memsize@videotron.ca>
      bf64bab9
  19. Oct 05, 2010
  20. Oct 04, 2010
  21. Oct 02, 2010
  22. Oct 01, 2010
Loading