Programming Definitions: What exactly is 'Building'.

Question

What does it mean to BUILD a solution/project/program? I want to make sure I have my definitions correct (so I don't sound like a idiot when conversing). In IDE's, you can (correct me if I'm wrong) compile source-code/programming-code into computer-readable machine code. You can debug a program, which is basically stepping through the program and looking for errors.

But what exactly doe's building a program do? In VS im aware that when you build a program it produces a executable file in a debug folder. Any hard-core tech definitions of what it means to BUILD a program?

Answer 1

It means the process of converting the human-readable source artifacts into machine-readable artifacts.

Answer 2

Building means many things to many people, but in general it means starting with source files produced by developers and ending with things like installation packages that are ready for deployment.

"The build" can contain many things:

• Compilation of source files (for languages/environments that support a separate/explicit compilation step)
• Linking of object code (for languages/environments that support a separate/explicit linking step)
• Production of distribution packages, also called "installers"
• Generation of documentation that is embedded within the source code files, e.g. Doxygen, Javadoc
• Execution of automated tests like unit tests, static analysis tests, and performance tests
• Generation of reports that tell the development team how many warnings and errors occurred during the build
• Deployment of distribution packages. For example, the build could automatically deploy/publish a new version of a web application (assuming that the build is successful).

"The build" can be done "by hand" or it can be automated, or some hybrid of the two. A manual build is a build that requires build commands like compilers to be executed one by one. An automated build packages together all of the individual build tools into a large build program that can be (ideally) run in a single step.

Answer 3

This does not necessarily bear on what humans mean about 'build', but as far as MSBuild 2.0 is concerned, the code in Microsoft.Common.targets describes it thusly:

...
<!--
============================================================
                                    Build

The main build entry point.
============================================================
-->
<PropertyGroup>
    <BuildDependsOn>
        BeforeBuild;
        CoreBuild;
        AfterBuild
    </BuildDependsOn>
</PropertyGroup>
<Target
    Name="Build"
    Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
    DependsOnTargets="$(BuildDependsOn)"
    Outputs="$(TargetPath)"/>

<!--
============================================================
                                    BeforeBuild

Redefine this target in your project in order to run tasks just before Build
============================================================
-->
<Target Name="BeforeBuild"/>

<!--
============================================================
                                    AfterBuild

Redefine this target in your project in order to run tasks just after Build 
============================================================
-->
<Target Name="AfterBuild"/>

<!--
============================================================
                                    CoreBuild

The core build step calls each of the build targets.
============================================================
-->
<PropertyGroup>
    <CoreBuildDependsOn>
          BuildOnlySettings;
          PrepareForBuild;
          PreBuildEvent;
          UnmanagedUnregistration;
          ResolveReferences;
          PrepareResources;
          ResolveKeySource;
          Compile;
          GenerateSerializationAssemblies;
          CreateSatelliteAssemblies;
          GenerateManifests;
          GetTargetPath;
          PrepareForRun;
          UnmanagedRegistration;
          IncrementalClean;
          PostBuildEvent
    </CoreBuildDependsOn>
</PropertyGroup>
<Target
    Name="CoreBuild"
    DependsOnTargets="$(CoreBuildDependsOn)">

    <OnError ExecuteTargets="_TimeStampAfterCompile;PostBuildEvent" Condition="'$(RunPostBuildEvent)'=='Always' or '$(RunPostBuildEvent)'=='OnOutputUpdated'"/>
    <OnError ExecuteTargets="_CleanRecordFileWrites"/>

</Target>
...

which suggests that 'build' mean roughly "compile plus all the associated auxiliary events that get you from code artifacts to a deployable result".

Answer 4

Many projects involve lots of source files. In principle, you can manually compile any one of those files by itself -- you use a compiler to compile that source file into a (temporary) object file containing machine code.

In practice, it's far too tedious to manually compile every source file one at a time, and even more tedious to manually keep track of which source files need to be recompiled. So we build the entire project at once by running an automated build program -- typically called "make". That program goes through a list of source files, often stored in yet another "source" file named "makefile", and calls the compiler on each one -- many versions of "make" are smart enough to only recompile the files that have changed and so need to be recompiled.

While compiling is arguably the most important part of the build process, often a "build" runs lots of other programs after the compiler. Occasionally a complete build will spend more time running these other programs than running the compiler.

For example, many people find it convenient to have a single button not only compile all the source code to the latest version, but also run a standard series of tests (C2: One Button Testing). So the makefile also lists whatever commands are needed to run those tests, which become part of the build process.