2. Building Builder
-Builder is normally built using itself. However, if you just downloaded the
-source and don't yet have a Builder binary, how is that possible? To resolve
-this problem, there's a script called bootstrap.sh in the Builder main
-directory. Before running it, make sure you have the following libraries
-available:
+Builder is normally built using itself. This creates a conundrum if you just
+downloaded the source and don't yet have a Builder binary. To resolve the
+problem, there's a script called bootstrap.sh in the Builder main directory.
+Before running it, make sure you have the following libraries available:
MSP libraries: core datafile
You should be able to get the MSP libraries from the same place you got
Builder itself from. Since they are also normally built with Builder, the
script will need to have their sources available. By default, it will look at
-the parent directory of builder. You can change this by setting the LIBPATH
-evironment variable for the script. If everything goes well, the script will
-build a builder-stage1 binary and then proceed to build a normal version with
-it.
+the parent directory of builder. You can change this with the --libpath
+parameter for the script. If everything goes well, the script will build a
+builder-stage1 binary and then proceed to build a normal version with it.
-------------------------------------------------------------------------------
tarballs
Depends on source tarballs of all packages.
-cmdline
- This target is an internal representation of the command line. Trying to
- add it to the command line will cause Builder to abort.
+goals
+ Depends on all targets on the command line. Trying to add this target to the
+ command line will cause Builder to abort due to a circular dependency.
-------------------------------------------------------------------------------
10. Logging
Sometimes you need to figure out what Builder is doing, perhaps because it's
-doing it wrong or you're just interested. To this end, a number of logging
+doing it wrong or you're just curious. To this end, a number of logging
channels are provided. To specify which channels to enable, use the -l
option. Some channels are also turned on by the -v option; the default
verbosity level is 1. The -s option disables all channels.
use "mylib_common";
-Libraries used in this way will always be linked in statically. This can be
-useful in organizing code when multiple components in a package share a common
-part.
+This can be useful in organizing code when multiple components in a package
+share a common part. If the used library is not specified to be installed,
+it will be linked statically.
Packages may want to offer optional features, for example to allow the user to
choose whether to use a particular external library:
};
Any statements inside the conditional block are evaluated if the feature is
-enabled. This can be negated with a !. Conditionals can appear at the package
-level and may contain anything that the package statement can.
+enabled. This can be negated with a !. Conditionals can appear at package and
+component scopes and may contain anything that the enclosing statement can.
When making cross-platform software, it's often necessary to use different
libraries on different platforms. Another kind of conditional can be used for
Bug reports, feature requests etc. may be sent to tdb@tdb.fi
-Read-only git access is available at http://git.tdb.fi/builder
+Read-only git access is available at git://git.tdb.fi/builder
-------------------------------------------------------------------------------