SHAPE_BUILD(1)
π NAME π
ok so shape_build β that's the shapeTools RMS system building and installation situation, bestie. it's giving "how do i build and install this thing" energy. β¨
πΈ SYNOPSIS πΈ
shape [all][VERSIONS=<rule>] [variants] [macro settings]
shape install[VERSIONS=<rule>] [INSTALLBASE=<path>] [variants] [macro
settings]
shape clean[<macro settings>]
shape cleancache [<macro settings>]
make [all][<macro settings>]
make install[INSTALLBASE=<path>] [<macro settings>]
make clean[<macro settings>]
β¨ DESCRIPTION β¨
okay so shape all, or just plain shape (because all is the default target, she's the main character), builds the current system node. π«Ά it does literally everything needed to derive the main target β that's $(TARGET) in the Makefile β from the node's source components.
and like, shape all also builds all the subsystems of the current node. before it triggers any build action itself, it recursively calls shape for each subsystem. no cap. π¦
the version selection is driven by the rule you pass as the value of the VERSIONS macro, and the default is most_recent. and the version selection rule you set on the command line, if you set one, gets inherited by the recursive calls. the vibes propagate. periodt. π
shape install installs the build results of the current node in the appropriate locations. the things getting installed are usually binaries and manuals β the target installtargets in the Makefile lists all of those as its dependents.
not me β okay actually yes me β shape install updates all build results the same way shape all does, before installing them. and it invokes all subsystems of the current node in the installation procedure by recursively calling shape install for each of them. and yes, it does that before it performs any build or install actions itself. π
the appropriate versions get selected according to the version selection rule named in the VERSIONS macro. the default rule for shape install is recent_release, which selects the most recent release or prerelease β whichever is newer. π₯
the macro INSTALLBASE defines the installation base directory: an absolute pathname pointing to the root of a directory tree where the build results are to be copied to. check the Makefile for the default setting of INSTALLBASE and for the installation directories, which are defined as relative pathnames starting from the installation base directory.
values of the VERSION and the INSTALLBASE macro set on the command line are inherited to all recursive calls. π
shape clean removes all derived objects currently established as UNIX files. these are:
- the files listed in the
OBJECTSmacro in theMakefile - the derived target
$(TARGET) - the target aliases
$(ALIASES)
the derived objects "established as UNIX files" are the ones being produced from their source β or reinstalled from the derived object cache β during the last system build.
shape cleancache cleans up the derived object cache, will say, it removes all objects stored there. π all names listed as dependents of the .BPOOL special macro in the Shapefile are candidates to be cached. when multiple (different) versions of derived objects with the same name arise, the older ones get stored to the derived object cache.
shape cleancache in conjunction with shape clean removes all derived (automatically reproducible) objects.
heads up bestie π¨ the two cleanup actions are not called recursively. they apply only to the current node. don't @ me.
the build and cleanup actions (all, install and clean) of the shape RMS can be performed by make(1) and by shape(1). the main difference? shape is capable of setting up the appropriate source context according to a given version selection rule, while make only regards the regular UNIX files.
make will fail if not every component of the system has a checked out busy version. π
the intention for maintaining Makefiles suitable for complete system builds aims at system building and installation from a source distribution rather than from the development area. source distributions are system copies taken from one of the release trees (partial release area or release area). see shape_RMS(1) for details. π
make all, make install and make clean behave similar to their shape counterparts. the difference is that they expect a complete system source context to be set up as UNIX files (see above).
each macro definition in the Make- or Shapefile may be redefined from the command line. most of the shape RMS standard macro definitions are inherited to recursive calls of make or shape. check the shape_tmpl(7) manual page for a list of the standard macros. β
π INCONVENIENCES π
for technical reasons, each make call recursively invokes make on the same level before performing any actions. this unfortunately restricts the efficacy of command line options.
e.g. there is no chance to work with the -f option (alternate name for the Makefile), and the redefinition of macros is restricted to inherited ones. π
ngl this restriction does not apply to shape calls. so. just saying. π
π FILES π
MakefileShapefile
π¦ SEE ALSO π¦
and that's the whole page, bestie!! π this was shape_build(1), dropped on 12.10.126, and honestly? iconic. go build something. πβ¨π
π¦ where this page comes from
- debian bookworm: shapetools 1.4pl6-15+b1
- ubuntu jammy: shapetools 1.4pl6-15
- ubuntu noble: shapetools 1.4pl6-16.1build1
- ubuntu questing: shapetools 1.4pl6-16.1build1
- ubuntu resolute: shapetools 1.4pl6-17
- ubuntu stonking: shapetools 1.4pl6-17
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms