Build tool notes

From Helpful
Jump to navigation Jump to search
Some fragmented programming-related notes, not meant as introduction or tutorial

Data: Numbers in computers ·· Computer dates and times ·· Data structures

Wider abstractions: Programming language typology and glossary · Generics and templating ·· Some abstractions around programming · · Computational complexity theory notes · Synchronous, asynchronous · First-class citizen

Syntaxy abstractions: Constness · Memory aliasing · Binding, assignment, and such · Closures · Context manager · Garbage collection

Sharing stuff: Communicated state and calls · Locking, data versioning, concurrency, and larger-scale computing notes

Language specific: Python notes ·· C and C++ notes · Compiling and linking ·· Lua notes

Teams and products: Programming in teams, working on larger systems, keeping code healthy · Benchmarking, performance testing, load testing, stress testing, etc. · Maintainability

More applied notes: Optimized number crunching · File polling, event notification · Webdev · GUI toolkit notes

Mechanics of duct taping software together: Automation, remote management, configuration management · Build tool notes · Installers


This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


Build tools are things that help you compile things.

Sometimes it helps basic organization, and it becomes very useful when the underlying compilation environment or dependent libraries will vary - it will be a sort of template that hold your code and keeps it separated from all that varying bother.

Though for similar reasons, build tools can they can become constricting annoyances themselves.


In some cases, the fact that you're creating a predictable environment to build in is also a nice environment to run it in.

Yes, what it does overlap somewhat with configuration management, but the goal is more specific.



GNU build tools (a.k.a. autotools)

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Consists of autoconf, automake and libtool.


This is what you use when install instructions tell you to do a ./configure and make (and possibly some stuff before that).


configure mostly checks whether the target environment is as expected, and sets some environment (think libraries) based on that, to support the actual compilation without any hardcoding.


See also:


Makefile notes

CMake

Cross-platform make.

See


Scons

Written in python.

See

Buck

https://buck.build/

https://buck.build/setup/getting_started.html


Ant

Written in java

See:

Maven

In Java, and primarily for Java.

Applies a fairly standard directory structure to its projects.


Maven concepts

Each project has a POM (Project Object Model), which contains the description of the project and its dependencies.


A lifecycle is a sequence of phases, a phase tends to consist of its own set of goals.


Phases are more abstract than goals - but seem to be (context-dependently) mapped to goals.

Running a phase implies running its dependent/preceding phases. For example, 'package' implies building(verify)


Phases common to many lifecycles (see also [1]) include:

  • validate: check all necessary information is present
  • compile: compile project source code
  • test: run any configured tests on compiled code
  • package: place compiled code in a distributable format (e.g. a jar)
  • integration-test: process and deploy the package if necessary into an environment where integration tests can be run
  • verify: run any checks to verify the package is valid and meets quality criteria
  • install: install the package into the local repository, for use as a dependency in other projects locally
  • deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

For example, the basic build lifecycle is roughly the first half:

  • validate
  • generate-sources
  • process-sources
  • generate-resources
  • process-resources
  • compile

There are two lifecycles that exclude the already mentioned phases - the clean lifecycle (just the clean phase) and the site lifecycle (site, site-deploy).


This system can be extended. You can for example change and add goals to phases.


Phases and goals can be run in sequence. For example:

mvn clean dependency:copy-dependencies package

...means clean is the phase, dependency:copy-dependencies is the goal, 'package'



See:



NAnt

Like ant, for .NET.

See:


Gradle

https://gradle.org/


Jenkins

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Aimed at building, testing, and deploying.

Leverages

  • code versioning (Subversion, Git, Mercurial, CVS, etc.)
  • builders (Ant, Maven, sbt) and/or shell/batch commands

https://en.wikipedia.org/wiki/Jenkins_(software)

Vagrant

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


Vagrant helps set up (specify, also provision/run) build environments and test environments, within a VM or container, from a simple description.

At the first install it seems a little overkill for what it does -- yet the fact that it should do exactly the same thing regardless of the environment it's run in makes certain workflows a lot more painless.

It unifies different providers (Docker, Virtualbox, VMWare). People seem to prefer the VM approach because that makes it portable between win, lin, or osx.


You write a Vagrantfile to specify setup, environment that goes inside, commands that control running machines.

Since these are often installs/builds, this will often take a while.


There's a public hub often used to bootstrap such build environments.


Because vagrant not very flexible about choice of backend, this is typically only used for things like

  • binary compilation
  • demo environments
e.g. the salt demo[2], because it's useful to launch a master and two minions

but not for devops style development, and therefore also often not its deployment.


For example:

  • Install virtualbox
  • Install vagrant
  • Download a project with a vagrantfile


  • go to that directory, run vagrant up


See also:


waf

https://en.wikipedia.org/wiki/Waf

https://waf.io/

Docker

The fact that you specify the environment from scratch means the library environment can be easily controlled fairly well.

It also helps that it's also a runtime environment, making it a natural choice for validating builds in CI/CD.

See also