Build sh как запустить

Compiling with build.sh

With the build.sh script you can easily build myMPD and create your own packages. Downstream packagers should use cmake directly.

Compiling and installing

The build.sh script provides three compile targets for myMPD.

If compilation fails and you are building on top of an old version, try to run ./build.sh cleanup before.

Release

• ./build.sh release
  • Builds release binaries
  • Directory: release
  • Assets embedded in binary
  • Binary is stripped
  • Install prefix is /usr

  You can use ./build.sh releaseinstall to compile and install in one step.

  Debug

  • ./build.sh debug
    • Builds debug binaries
    • Directory: debug
    • Plain assets in htdocs directory
    • Use this to debug mympd with valgrind or gdb

    Memcheck

    • ./build.sh memcheck
      • Builds debug binaries linked with libasan
      • Directory: debug
      • Plain assets in htdocs directory
      • You must preload libasan, e.g. LD_PRELOAD=libasan.so.6 debug/bin/mympd

      Removing

      • ./build.sh uninstall to remove only binaries
      • ./build.sh purge to remove all

      Create distribution specific packages

      You can self create packages for your distribution:

      • ./build.sh pkgalpine for Alpine Linux
      • ./build.sh pkgarch for Arch based distributions (e.g. Manjaro)
      • ./build.sh pkgdebian for Debian based distributions (e.g. Ubuntu. Raspbian)
      • ./build.sh pkgrpm for RPM based distributions (e.g. openSUSE, Fedora)
      • ./build.sh pkgdocker to create a Docker image based on Alpine Linux
      • For gentoo you have to create a local overlay: https://wiki.gentoo.org/wiki/Custom_repository, the ebuild file is in the directory contrib/packaging/gentoo
      • Build a OpenWrt package

      Cross compiling debian packages

      The build script can use sbuild and qemu to cross compile debian packages, thanks to #264 @tsunulukai.

      1. Set target distributions: export DISTROS=»bullseye buster»
      2. Set target architectures: export TARGETS=»armhf armel»
      3. sudo -E ./build.sh sbuild_chroots to create chroot environments for build
      4. sudo -E ./build.sh sbuild_build to build the packages

      The successfully build packages can be found in the packager/builds directory.

      How to run .sh on Windows Command Prompt?

      Here the screen grab,

      11 Answers 11

      Install GIT. During installation of GIT, add GIT Bash to windows context menu by selecting its option. After installation right click in your folder select GIT Bash Here (see attached pic) and use your sh command like for example:

      

      

      The error message indicates that you have not installed bash , or it is not in your PATH .

      The top Google hit is http://win-bash.sourceforge.net/ but you also need to understand that most Bash scripts expect a Unix-like environment; so just installing Bash is probably unlikely to allow you to run a script you found on the net, unless it was specifically designed for this particular usage scenario. The usual solution to that is https://www.cygwin.com/ but there are many possible alternatives, depending on what exactly it is that you want to accomplish.

      If Windows is not central to your usage scenario, installing a free OS (perhaps virtualized) might be the simplest way forward.

      Глава 27. Использование утилиты build.sh

      NetBSD 1.6 и более поздние версии включают улучшенный набор инструментальных средств, для облегчения сборки дистрибутивов, ядра и прочих мелких нужд. В этой главе рассматривается утилита build.sh , применяемая для кросс-платформенной сборки ядра и компиляции релизов. Непосредственно сборка ядра рассмотрена в Глава 28, Компиляция ядра. Детальное описание структуры утилиты build.sh может быть найдено в документации Luke Mewburn и Matthew Green’s и их презентации на BSDCon 2003.

      Перед любыми нашими действиями необходимо установить исходные тексты системы. Смотри Глава 26, Obtaining sources by CVS для получения более полной информации.

      27.1. Сборка инструментов

      Как только исходные тексты были получены, необходимо собрать инструменты, родные для используемой платформы. Это довольно просто сделать. Будем использовать каталоги по умолчанию:

      Если инструменты уже были собраны, но нуждаются в модификации, то может быть спользована опция update, для пересборки только обновившихся утилит.

      После того, как утилиты для родной платформы были собраны, могут быть собраны утилиты других платформ, в нашем примере, для платформы sparc64 .

      Когда сборка инструментов будет закончена, будет выведена информация о переменных окружения:

      https://amdy.su/wp-admin/options-general.php?page=ad-inserter.php#tab-8

      Теперь, имея инструменты для sparc64, мы можем приступать к кросс-платформенной сборке ядра.

      27.2. Кросс-платформенная сборка ядра

      Кросс-платформенная сборка ядра может быть проведен в каталог conf соответствующей архитектуры с использованием имеющихся инструменов или, что легче, с использованием build.sh .

      Редактируем MYKERNEL . После того, как сие хитрое действо будет закончено, используем утилиту build.sh для сборки ядра.

      Обратите внимание, что обновления были получены, инструментальные средства собраны и нет никакой причины их пересобирать. Как только ядро будет собрано, build.sh доложит об этом, выведя местоположение ядра и некоторое количество дополнительной информации.

      27.3. Сборка & релиза

      Теперь Вам уже должно быть ясно, что инструментальный набор работает поэтапно. Перым делом мы компонуем инструменты для архитектуры, на которой будем проводить сборку, а затем ядро. Затем, в случае необходимости build.sh будет пересобирать инструменты. Использование опции update будет экономить Ваше время. Также должно быть ясно, что семантика использования утилиты build.sh довольно проста и процесс сборки релиза заключается только в правильном использовании команд.

      Не должно быть неожиданностью то, что сборка и создание релиза заключается в следующем:

      Просмотрев информацию о переменных окружения (напоминаю, мы использовали значения по умолчанию), мы обнаружим сборку в:

      Директория релиза будет определена как:

      27.4. Переменные окружения

      Мало чем отличаясь от старой технологии, новая имеет довольно большое количество переменных, которые могут быть использованы для указания путей к файлам или применяемых инструментов (если это необходимо). В файле src/BUILDING описывается большинство из них. В этом разделе мы приведем два примера изменения переменных по умолчанию и сделаем это несколькоми способами.

      27.4.1. Смена директории по умолчанию

      Довольно много людей отслеживают ветку current и регулярно делают кросс-платформенную сборку для нескольких используемых архитектур. Логика этого довольно проста — как только появляется новая опция или поддержка нового устройства, находятся люди, которым необходимо использование этих нововведений. Отслеживая изменения и переодически проводя сборку, они должны иметь возможность создания релиза.

      Разумно будет предположить, что если отслеживаются изменения и проводится сборка для нескольких архитектур, то стоит хранить различные сборки в разных местах. Есть два способа сделать это — использовать сценарий для установки DESTDIR, или вводить каталог назначения в интерактивном режиме. В любом случае, это делается точно также, как и определение любой другой переменной (в зависимости от Вашей оболочки, конечно).

      Для оболочек bourne или korn:

      Довольно просто. Когда сборка будет выполнена, бинарники и файлы будут находится в /usr/builds .

      Chapter 8 Using the build.sh Front End

      NetBSD 1.6 and forward comes equipped with an improved toolchain that can be used to easily perform system builds, new kernels, and cross compile with a relative amount of ease. In this chapter, the use of the build.sh cross compiling a kernel, cross compiling a build, and creating a release are covered. Native kernel builds are covered in Chapter 9.

      Before we do anything, the sources must be retrieved. See Chapter 19 for getting the sources.

      8.1 Building the tools

      Once the sources have been obtained, the native platform tools have to be built before doing anything else. Doing this is simple, we will use the default object directory.

      If the tools have already been built and they only need updated, then the update option can be used to only rebuild tools that have changed.

      Now that the native tools have been built, the tools for another target system can be created. In our example, sparc64 will be used.

      When the tools are finished building, information about them and several environment variables is printed out:

      Now that the tools for sparc64 have been built, it is time to cross compile the kernel.

      8.2 Cross Compiling a Kernel

      A cross compiled kernel can be done by either going to the architecture conf directory and explicitly calling the cross compiled tools or the easier method of using build.sh.

      Configuring the kernel is the same:

      Then edit MYKERNEL. Once finished, all that needs to be done is to use build.sh to build the kernel (it will also configure it):

      Notice that update was specified, the tools are already built, there is no reason to rebuild all of the tools. Once the kernel is built, build.sh will print out the location of it along with other information:

      8.3 Build & Release

      By now it is probably becoming clear that the toolchain actually works in stages. First is the native tools build (which actually has a step before it, makewrappers), then a kernel. Since build.sh will attempt to rebuild the tools at every invocation, using update saves time. It is also probably clear that outside of a few options, the build.sh semantics are basically [ build.sh command ]. So, it stands to reason that creating a build and/or release, is a matter of using the right commands.

      It should be no surprise that building and creating a release would look like the following:

      Looking at the information about environment variables (since so far only the defaults have been used), a build would be at:

      The release would be located at:

      8.4 Environment Variables

      Not unlike the old building method, the toolchain has a lot of variables that can be used to direct things like where certain files go, what (if any) tools are used and so on. A look in src/BUILDING covers most of them. In this section two examples of changing default variables are given in two different ways.

      8.4.1 Changing the Destination Directory

      Many people like to track current and perform cross compiles of architectures that they use. The logic for this is simple, sometimes a new feature or device becomes available and someone may wish to use it. By keeping track of changes and building every now and again, one can be assured that they can create their own release.

      It is reasonable to assume that if one is tracking and building for more than one architecture, they might want to keep the builds in a different location than the default. There are two ways to go about this, use a script to set the new DESTDIR, or simply do so interactively. In any case, it can be set the same way as any other variable (depending on your shell of course).

      For the bourne or korn shells:

      For the c shell:

      Simple enough. When the build is run, the binaries and files will be sent to /usr/builds.

      Похожие публикации:

      1. Как обратиться к глобальной переменной 1с
      2. Yyy mmm ddd что это
      3. Как инициализировать двумерный массив c
      4. Dim в vba что это