| |
|---|
| | |
|---|
| | |
|---|
| | ## Building The Bootstrap Image |
|---|
| | |
|---|
| | 1. Log into your build machine, VM, or docker image. |
|---|
| | 1. Log into your build machine, VM, or`docker`image. |
|---|
| | |
|---|
| | 2. Make sure you have write permission to the installation directory. |
|---|
| | |
|---|
| | 3. Make sure the native OS compiler tools are installed. |
|---|
| |
|---|
| | |
|---|
| | |
|---|
| | ## Building The Full Tools Set |
|---|
| | |
|---|
| | 1. Log into you build machine, VM, or`docker`image. *Make sure this |
|---|
| | machine does *not* have native OS compilers and development tools |
|---|
| | installed and/or in `${PATH}`!* We want to use only the compiler and |
|---|
| | tools created in the previous step. `Docker` containers are handy here: |
|---|
| | One for the bootstrap build, another for the self compiling |
|---|
| | full tools build. |
|---|
| | |
|---|
| | 2. Un-tar the bootstrap tarball created above into the proper location. |
|---|
| | Recall that this was saved with a date revision stamp. So, before |
|---|
| | proceeding, we have to: |
|---|
| | |
|---|
| | `cd ${INSTALLDIR} && mv -v ${TOOLS}-YYYYMMDD ${TOOLS}` |
|---|
| | |
|---|
| | 3. Setup the required environment variables: |
|---|
| | |
|---|
| | `. brewenv` |
|---|
| | |
|---|
| | 4. Make sure `${MYTOOLS}` has all the packages you want listed. |
|---|
| | |
|---|
| | 5. Build the full tool set using the bootstrapped compiler we just |
|---|
| | built: |
|---|
| | |
|---|
| | `make full-build` |
|---|
| | |
|---|
| | 6. Export it for installation elsewhere: |
|---|
| | |
|---|
| | `make full-release` |
|---|
| | |
|---|
| | 7. Cleanup: |
|---|
| | |
|---|
| | `make clean` |
|---|
| | |
|---|
| | ## Installing The Tools |
|---|
| | |
|---|
| | We've just created a tarball that has all the tools we want precompiled |
|---|
| | and ready for distribution. We just untar the full tools tarball onto |
|---|
| | any other machine. The only restrictions are: |
|---|
| | |
|---|
| | - We must un-tar *so that the tools directory ends up in the same |
|---|
| | location in the filesystem as where it was built*. The binaries |
|---|
| | we've just created make assumptions about where to find their |
|---|
| | libraries and other dependencies. So, if we built the tools |
|---|
| | under: |
|---|
| | |
|---|
| | `/opt/mydir/tools` |
|---|
| | |
|---|
| | Every installation on other machines must also install them |
|---|
| | there (and be added to `$(PATH}` as described in `brewenv`. |
|---|
| | |
|---|
| | Recall that this procedure actually creates the tools directory |
|---|
| | as: |
|---|
| | |
|---|
| | `/opt/mydur/tools-YYYYMMDD`. |
|---|
| | |
|---|
| | In this example, you could either symlink `tools` to that |
|---|
| | directory or just rename the directory accordingly. |
|---|
| | |
|---|
| | - The buil- and target machines must have reasonably close kernel |
|---|
| | versions. That's because the bootstrap phase makes use of |
|---|
| | native OS header files that are kernel-dependent. If, say, |
|---|
| | you try to build this on a CentOS 7 instance, but then attempt |
|---|
| | to deploy to, CentOS 5, expect problems. *Always build your |
|---|
| | deploy image on an OS that is substantially the same as your targets*. |
|---|
| | Again, `docker` is your friend here. |
|---|
| | |
|---|
| | ## The `brewenv` File |
|---|
| | |
|---|
| | The `brewenv` file documents the environment variables that need to be |
|---|
| |
|---|
| | |
