Chapter 6. Special Considerations

When creating a symbolic link, relative ones are strongly recommended. Use ${RLN} to create relative symbolic links. It uses install(1) under the hood to automatically figure out the relative link to create.

Some software requires the porter to locate third-party libraries and add the required dependencies to the port. Other software bundles all necessary libraries into the distribution file. The second approach seems easier at first, but there are some serious drawbacks:

This list is loosely based on the Fedora and Gentoo wikis, both licensed under the CC-BY-SA 3.0 license.

Whenever possible, use the unbundled version of the library by adding a LIB_DEPENDS to the port. If such a port does not exist yet, consider creating it.

Only use bundled libraries if the upstream has a good track record on security and using unbundled versions leads to overly complex patches.

This variable indicates that we may not generate a binary package of the application. For instance, the license may disallow binary redistribution, or it may prohibit distribution of packages created from patched sources.

However, the port’s DISTFILES may be freely mirrored on FTP/HTTP. They may also be distributed on a CD-ROM (or similar media) unless NO_CDROM is set as well.

If the binary package is not generally useful, and the application must always be compiled from the source code, use NO_PACKAGE. For example, if the application has configuration information that is site specific hard coded into it at compile time, set NO_PACKAGE.

Set NO_PACKAGE to a string describing the reason why the package cannot be generated.

This variable alone indicates that, although we are allowed to generate binary packages, we may put neither those packages nor the port’s DISTFILES onto a CD-ROM (or similar media) for resale. However, the binary packages and the port’s DISTFILES will still be available via FTP/HTTP.

If this variable is set along with NO_PACKAGE, then only the port’s DISTFILES will be available, and only via FTP/HTTP.

Set NO_CDROM to a string describing the reason why the port cannot be redistributed on CD-ROM. For instance, use this if the port’s license is for "non-commercial" use only.

Files defined in NOFETCHFILES are not fetchable from any of MASTER_SITES. An example of such a file is when the file is supplied on CD-ROM by the vendor.

Tools which check for the availability of these files on MASTER_SITES have to ignore these files and not report about them.

Set this variable alone if the application’s license permits neither mirroring the application’s DISTFILES nor distributing the binary package in any way.

Do not set NO_CDROM or NO_PACKAGE along with RESTRICTED, since the latter variable implies the former ones.

Set RESTRICTED to a string describing the reason why the port cannot be redistributed. Typically, this indicates that the port contains proprietary software and that the user will need to manually download the DISTFILES, possibly after registering for the software or agreeing to accept the terms of an EULA.

When RESTRICTED or NO_CDROM is set, this variable defaults to ${DISTFILES} ${PATCHFILES}, otherwise it is empty. If only some of the distribution files are restricted, then set this variable to list them.

If the port has legal concerns not addressed by the above variables, set LEGAL_TEXT to a string explaining the concern. For example, if special permission was obtained for FreeBSD to redistribute the binary, this variable must indicate so.

A port which sets any of the above variables must also be added to /usr/ports/LEGAL. The first column is a glob which matches the restricted distfiles. The second column is the port’s origin. The third column is the output of make -VLEGAL.

The preferred way to state "the distfiles for this port must be fetched manually" is as follows:

This both informs the user, and sets the proper metadata on the user’s machine for use by automated programs.

Note that this stanza must be preceded by an inclusion of bsd.port.pre.mk.

The FreeBSD ports framework supports parallel building using multiple make sub-processes, which allows SMP systems to utilize all of their available CPU power, allowing port builds to be faster and more effective.

This is achieved by passing -jX flag to make(1) running on vendor code. This is the default build behavior of ports. Unfortunately, not all ports handle parallel building well and it may be required to explicitly disable this feature by adding the MAKE_JOBS_UNSAFE=yes variable. It is used when a port is known to be broken with -jX due to race conditions causing intermittent build failures.

Several differing make implementations exist. Ported software often requires a particular implementation, like GNU make, known in FreeBSD as gmake.

If the port uses GNU make, add gmake to USES.

MAKE_CMD can be used to reference the specific command configured by the USES setting in the port’s Makefile. Only use MAKE_CMD within the application Makefiles in WRKSRC to call the make implementation expected by the ported software.

If the port is an X application that uses imake to create Makefiles from Imakefiles, set USES= imake. See the USES=imake section of Using USES Macros for more details.

If the port’s source Makefile has something other than all as the main build target, set ALL_TARGET accordingly. The same goes for install and INSTALL_TARGET.

If the port uses the configure script to generate Makefile from Makefile.in, set GNU_CONFIGURE=yes. To give extra arguments to the configure script (the default argument is --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${PREFIX}/man --build=${CONFIGURE_TARGET}), set those extra arguments in CONFIGURE_ARGS. Extra environment variables can be passed using CONFIGURE_ENV.

For ports that use CMake, define USES= cmake.

CMake supports these build profiles: Debug, Release, RelWithDebInfo and MinSizeRel. Debug and Release profiles respect system *FLAGS, RelWithDebInfo and MinSizeRel will set CFLAGS to -O2 -g and -Os -DNDEBUG correspondingly. The lower-cased value of CMAKE_BUILD_TYPE is exported to PLIST_SUB and must be used if the port installs *.cmake depending on the build type (see devel/kf5-kcrash for an example). Please note that some projects may define their own build profiles and/or force particular build type by setting CMAKE_BUILD_TYPE in CMakeLists.txt. To make a port for such a project respect CFLAGS and WITH_DEBUG, the CMAKE_BUILD_TYPE definitions must be removed from those files.

Most CMake-based projects support an out-of-source method of building. The out-of-source build for a port is the default setting. An in-source build can be requested by using the :insource suffix. With out-of-source builds, CONFIGURE_WRKSRC, BUILD_WRKSRC and INSTALL_WRKSRC will be set to ${WRKDIR}/.build and this directory will be used to keep all files generated during configuration and build stages, leaving the source directory intact.

If the port uses SCons, define USES=scons.

To make third party SConstruct respect everything that is passed to SCons in the environment (that is, most importantly, CC/CXX/CFLAGS/CXXFLAGS), patch SConstruct so build Environment is constructed like this:

It may be then modified with env.Append and env.Replace.

For ports that use Cargo, define USES=cargo.

For ports that use Meson, define USES=meson.

For ports that use Go, define USES=go. Refer to go for a list of variables that can be set to control the build process.

For ports that use Cabal, build system defines USES=cabal. Refer to cabal for a list of variables that can be set to control the build process.

Some Haskell ports install various data files under share/${PORTNAME}. For such cases special handling is required on the port side. The port should define the CABAL_WRAPPER_SCRIPTS knob listing each executable that is going to use data files. Moreover, in rare cases the program being ported uses data files of other Haskell packages, in which case the FOO_DATADIR_VARS comes to the rescue.

There is no easy way to find out a proper value for the FOO_DATADIR_VARS knob apart from running the program and checking that everything works. Luckily, the need to use FOO_DATADIR_VARS is very rare.

Another corner case when porting complex Haskell programs is the presence of VCS dependencies in the cabal.project file.

If the port requires gettext, set USES= gettext, and the port will inherit a dependency on libintl.so from devel/gettext. Other values for gettext usage are listed in USES=gettext.

A rather common case is a port using gettext and configure. Generally, GNU configure should be able to locate gettext automatically.

If it ever fails to, hints at the location of gettext can be passed in CPPFLAGS and LDFLAGS using localbase as follows:

Some software products allow for disabling NLS. For example, through passing --disable-nls to configure. In that case, the port must use gettext conditionally, depending on the status of the NLS option. For ports of low to medium complexity, use this idiom:

Or using the older way of using options:

The next item on the to-do list is to arrange so that the message catalog files are included in the packing list conditionally. The Makefile part of this task is already provided by the idiom. It is explained in the section on advanced pkg-plist practices. In a nutshell, each occurrence of %%NLS%% in pkg-plist will be replaced by "`@comment " if NLS is disabled, or by a null string if NLS is enabled. Consequently, the lines prefixed by `%%NLS%% will become mere comments in the final packing list if NLS is off; otherwise the prefix will be just left out. Then insert %%NLS%% before each path to a message catalog file in pkg-plist. For example:

In high complexity cases, more advanced techniques may be needed, such as dynamic packing list generation.

There is a point to note about installing message catalog files. The target directories for them, which reside under LOCALBASE/share/locale, must not be created and removed by a port. The most popular languages have their respective directories listed in PORTSDIR/Templates/BSD.local.dist. The directories for many other languages are governed by the devel/gettext port. Consult its pkg-plist and see whether the port is going to install a message catalog file for a unique language.

The X11 implementation available in The Ports Collection is X.Org. If the application depends on X components, add USES= xorg and set USE_XORG to the list of required components. A full list can be found in xorg.

The Mesa Project is an effort to provide free OpenGL implementation. To specify a dependency on various components of this project, use USES= gl and USE_GL. See gl for a full list of available components. For backwards compatibility, the value of yes maps to glu.

If the port requires a Motif library, define USES= motif in the Makefile. Default Motif implementation is x11-toolkits/open-motif. Users can choose x11-toolkits/lesstif instead by setting WANT_LESSTIF in their make.conf. Similarly x11-toolkits/open-motif-devel can be chosen by setting WANT_OPEN_MOTIF_DEVEL in make.conf.

MOTIFLIB will be set by motif.mk to reference the appropriate Motif library. Please patch the source of the port to use ${MOTIFLIB} wherever the Motif library is referenced in the original Makefile or Imakefile.

There are two common cases:

Note that MOTIFLIB (usually) expands to -L/usr/local/lib -lXm -lXp or /usr/local/lib/libXm.a, so there is no need to add -L or -l in front.

If the port installs fonts for the X Window System, put them in LOCALBASE/lib/X11/fonts/local.

Some applications require a working X11 display for compilation to succeed. This poses a problem for machines that operate headless. When this variable is used, the build infrastructure will start the virtual framebuffer X server. The working DISPLAY is then passed to the build. See USES=display for the possible arguments.

Desktop entries (a Freedesktop standard) provide a way to automatically adjust desktop features when a new program is installed, without requiring user intervention. For example, newly-installed programs automatically appear in the application menus of compatible desktop environments. Desktop entries originated in the GNOME desktop environment, but are now a standard and also work with KDE and Xfce. This bit of automation provides a real benefit to the user, and desktop entries are encouraged for applications which can be used in a desktop environment.

This chapter explains the GNOME framework as used by ports. The framework can be loosely divided into the base components, GNOME desktop components, and a few special macros that simplify the work of port maintainers.

Adding this variable to the port allows the use of the macros and components defined in bsd.gnome.mk. The code in bsd.gnome.mk adds the needed build-time, run-time or library dependencies or the handling of special files. GNOME applications under FreeBSD use the USE_GNOME infrastructure. Include all the needed components as a space-separated list. The USE_GNOME components are divided into these virtual lists: basic components, GNOME 3 components and legacy components. If the port needs only GTK3 libraries, this is the shortest way to define it:

USE_GNOME components automatically add the dependencies they need. Please see GNOME Components for an exhaustive list of all USE_GNOME components and which other components they imply and their dependencies.

Here is an example Makefile for a GNOME port that uses many of the techniques outlined in this document. Please use it as a guide for creating new ports.

This section explains which macros are available and how they are used. Like they are used in the above example. The GNOME Components has a more in-depth explanation. USE_GNOME has to be set for these macros to be of use.

The Ports Collection provides support for Qt 5 and Qt 6 with USES+=qt:5 and USES+=qt:6 respectively. Set USE_QT to the list of required Qt components (libraries, tools, plugins).

The Qt framework exports a number of variables which can be used by ports, some of them listed below:

Individual Qt tool and library dependencies must be specified in USE_QT. Every component can be suffixed with _build or _run, the suffix indicating whether the dependency on the component is at buildtime or runtime. If unsuffixed, the component will be depended on at both build- and runtime. Usually, library components are specified unsuffixed, tool components are mostly specified with the _build suffix and plugin components are specified with the _run suffix. The most commonly used components are listed below (all available components are listed in _USE_QT_ALL, which is generated from _USE_QT_COMMON and _USE_QT[56]_ONLY in /usr/ports/Mk/Uses/qt.mk):

To determine the libraries an application depends on, run ldd on the main executable after a successful compilation.

If the application provides a qmake project file (*.pro), define USES= qmake along with USE_QT. USES= qmake already implies a build dependency on qmake, therefore the qmake component can be omitted from USE_QT. Similar to CMake, qmake supports out-of-source builds, which can be enabled by specifying the outsource argument (see USES= qmake example). Also see Possible Arguments for USES qmake.

When using USES= qmake, these settings are deployed:

Some configure scripts do not support the arguments above. To suppress modification of CONFIGURE_ENV and CONFIGURE_ARGS, set USES= qmake:no_env.

Qt applications are often written to be cross-platform and often X11/Unix is not the platform they are developed on, which in turn leads to certain loose ends, like:

If the application depends on KDE, set USES+=kde:5 and USE_KDE to the list of required components. _build and _run suffixes can be used to force components dependency type (for example, baseapps_run). If no suffix is set, a default dependency type will be used. To force both types, add the component twice with both suffixes (for example, ecm_build ecm_run). Available components are listed below (up-to-date components are also listed in /usr/ports/Mk/Uses/kde.mk):

If the port needs a Java™ Development Kit (JDK™) to either build, run or even extract the distfile, then define USE_JAVA.

There are several JDKs in the ports collection, from various vendors, and in several versions. If the port must use a particular version, specify it using the JAVA_VERSION variable. The most current version is java/openjdk18, with java/openjdk17, java/openjdk16, java/openjdk15, java/openjdk14, java/openjdk13, java/openjdk12, java/openjdk11, java/openjdk8, and java/openjdk7 also available.

Below is the list of all settings a port will receive after setting USE_JAVA:

Use the java-debug make target to get information for debugging the port. It will display the value of many of the previously listed variables.

Additionally, these constants are defined so all Java ports may be installed in a consistent way:

The related entries are defined in both PLIST_SUB (documented in Changing pkg-plist Based on Make Variables) and SUB_LIST.

When the port is to be built using Apache Ant, it has to define USE_ANT. Ant is thus considered to be the sub-make command. When no do-build target is defined by the port, a default one will be set that runs Ant according to MAKE_ENV, MAKE_ARGS and ALL_TARGET. This is similar to the USES= gmake mechanism, which is documented in Building Mechanisms.

When porting a Java library, the port has to install the JAR file(s) in ${JAVAJARDIR}, and everything else under ${JAVASHAREDIR}/${PORTNAME} (except for the documentation, see below). To reduce the packing file size, reference the JAR file(s) directly in the Makefile. Use this statement (where myport.jar is the name of the JAR file installed as part of the port):

When porting a Java application, the port usually installs everything under a single directory (including its JAR dependencies). The use of ${JAVASHAREDIR}/${PORTNAME} is strongly encouraged in this regard. It is up the porter to decide whether the port installs the additional JAR dependencies under this directory or uses the already installed ones (from ${JAVAJARDIR}).

When porting a Java™ application that requires an application server such as www/tomcat7 to run the service, it is quite common for a vendor to distribute a .war. A .war is a Web application ARchive and is extracted when called by the application. Avoid adding a .war to pkg-plist. It is not considered best practice. An application server will expand war archive, but not clean it up properly if the port is removed. A more desirable way of working with this file is to extract the archive, then install the files, and lastly add these files to pkg-plist.

Regardless of the type of port (library or application), the additional documentation is installed in the same location as for any other port. The Javadoc tool is known to produce a different set of files depending on the version of the JDK that is used. For ports that do not enforce the use of a particular JDK, it is therefore a complex task to specify the packing list (pkg-plist). This is one reason why porters are strongly encouraged to use PORTDOCS. Moreover, even if the set of files that will be generated by javadoc can be predicted, the size of the resulting pkg-plist advocates for the use of PORTDOCS.

The default value for DATADIR is ${PREFIX}/share/${PORTNAME}. It is a good idea to override DATADIR to ${JAVASHAREDIR}/${PORTNAME} for Java ports. Indeed, DATADIR is automatically added to PLIST_SUB (documented in Changing pkg-plist Based on Make Variables) so use %%DATADIR%% directly in pkg-plist.

As for the choice of building Java ports from source or directly installing them from a binary distribution, there is no defined policy at the time of writing. However, people from the FreeBSD Java Project encourage porters to have their ports built from source whenever it is a trivial task.

All the features that have been presented in this section are implemented in bsd.java.mk. If the port needs more sophisticated Java support, please first have a look at the bsd.java.mk Git log as it usually takes some time to document the latest features. Then, if the needed support that is lacking would be beneficial to many other Java ports, feel free to discuss it on the freebsd-java.

Although there is a java category for PRs, it refers to the JDK porting effort from the FreeBSD Java project. Therefore, submit the Java port in the ports category as for any other port, unless the issue is related to either a JDK implementation or bsd.java.mk.

Similarly, there is a defined policy regarding the CATEGORIES of a Java port, which is detailed in Categorization.

Web applications must be installed into PREFIX/www/appname. This path is available both in Makefile and in pkg-plist as WWWDIR, and the path relative to PREFIX is available in Makefile as WWWDIR_REL.

The user and group of web server process are available as WWWOWN and WWWGRP, in case the ownership of some files needs to be changed. The default values of both are www. Use WWWOWN?= myuser and WWWGRP?= mygroup if the port needs different values. This allows the user to override them easily.

Do not depend on Apache unless the web app explicitly needs Apache. Respect that users may wish to run a web application on a web server other than Apache.

PHP web applications declare their dependency on it with USES=php. See php for more information.

Porting PEAR modules is a very simple process.

Add USES=pear to the port’s Makefile. The framework will install the relevant files in the right places and automatically generate the plist at install time.

There are many versions of the wxWidgets libraries which conflict between them (install files under the same name). In the ports tree this problem has been solved by installing each version under a different name using version number suffixes.

The obvious disadvantage of this is that each application has to be modified to find the expected version. Fortunately, most of the applications call the wx-config script to determine the necessary compiler and linker flags. The script is named differently for every available version. Majority of applications respect an environment variable, or accept a configure argument, to specify which wx-config script to call. Otherwise they have to be patched.

To make the port use a specific version of wxWidgets there are two variables available for defining (if only one is defined the other will be set to a default value):

The available wxWidgets versions and the corresponding ports in the tree are:

The variables in Variables to Select wxWidgets Versions can be set to one or more of these combinations separated by spaces:

There are also some variables to select the preferred versions from the available ones. They can be set to a list of versions, the first ones will have higher priority.

There are other applications that, while not being wxWidgets libraries, are related to them. These applications can be specified in WX_COMPS. These components are available:

The dependency type can be selected for each component by adding a suffix separated by a semicolon. If not present then a default type will be used (see Default wxWidgets Dependency Types). These types are available:

The default values for the components are detailed in this table:

To detect an installed version, define WANT_WX. If it is not set to a specific version then the components will have a version suffix. HAVE_WX will be filled after detection.

These variables are available in the port (after defining one from Variables to Select wxWidgets Versions).

Define WX_PREMK to be able to use the variables right after including bsd.port.pre.mk.

Some GNU configure scripts cannot find wxWidgets with just the WX_CONFIG environment variable set, requiring additional arguments. WX_CONF_ARGS can be used for provide them.

There are many versions of the Lua libraries and corresponding interpreters, which conflict between them (install files under the same name). In the ports tree this problem has been solved by installing each version under a different name using version number suffixes.

The obvious disadvantage of this is that each application has to be modified to find the expected version. But it can be solved by adding some additional flags to the compiler and linker.

Applications that use Lua should normally build for just one version. However, loadable modules for Lua are built in a separate flavor for each Lua version that they support, and dependencies on such modules should specify the flavor using the @${LUA_FLAVOR} suffix on the port origin.

A port using Lua should have a line of this form:

If a specific version of Lua, or range of versions, is needed, it can be specified as a parameter in the form XY (which may be used multiple times), XY+, -XY, or XY-ZA. The default version of Lua as set via DEFAULT_VERSIONS will be used if it falls in the requested range, otherwise the closest requested version to the default will be used. For example:

Note that no attempt is made to adjust the version selection based on the presence of any already-installed Lua version.

Software that uses Lua may have been written to auto-detect the Lua version in use. In general ports should override this assumption, and force the use of the specific Lua version selected as described above. Depending on the software being ported, this might require any or all of:

A port which installs a Lua module (rather than an application that simply makes use of Lua) should build a separate flavor for each supported Lua version. This is done by adding the module parameter:

A version number or range of versions can be specified as well; use a comma to separate parameters.

Since each flavor must have a different package name, the variable LUA_PKGNAMEPREFIX is provided which will be set to an appropriate value; the intended usage is:

Module ports should normally install files only to LUA_MODLIBDIR, LUA_MODSHAREDIR, LUA_DOCSDIR, and LUA_EXAMPLESDIR, all of which are set up to refer to version-specific subdirectories. Installing any other files must be done with care to avoid conflicts between versions.

A port (other than a Lua module) which wishes to build a separate package for each Lua version should use the flavors parameter:

This operates the same way as the module parameter described above, but without the assumption that the package should be documented as a Lua module (so LUA_DOCSDIR and LUA_EXAMPLESDIR are not defined by default). However, the port may choose to define LUA_DOCSUBDIR as a suitable subdirectory name (usually the port’s PORTNAME as long as this does not conflict with the PORTNAME of any module), in which case the framework will define both LUA_DOCSDIR and LUA_EXAMPLESDIR.

As with module ports, a flavored port should avoid installing files that would conflict between versions. Typically this is done by adding LUA_VER_STR as a suffix to program names (e.g. using uniquefiles), and otherwise using either LUA_VER or LUA_VER_STR as part of any other files or subdirectories used outside of LUA_MODLIBDIR and LUA_MODSHAREDIR.

These variables are available in the port.

These additional variables are available for ports that specified the module parameter:

There are multiple versions of the Guile libraries and corresponding interpreters, which conflict between them (install files under the same name). In the ports tree this problem has been solved by installing each version under a different name using version number suffixes. In most cases, applications should detect the correct version from the configuration variables provided and use pkg-config to determine the name and associated paths. However, some applications (especially those using their own configuration rules for cmake or meson) will always try to use the latest available version. In this case, either patch the port or declare a build conflict (see the conflicts option below) to ensure that the correct dependency is generated when building outside of poudriere.

Applications that use Guile should normally build for just one version, preferably the one specified in DEFAULT_VERSIONS, or failing that the latest version that they support. However, Guile or Scheme libraries, or extension modules for Guile are built in a separate flavor for each Guile version that they support, and dependencies on such ports should specify the flavor using the @${GUILE_FLAVOR} suffix on the port origin.

A port using Guile should define USES=guile:arg,arg…​ with appropriate arguments as follows:

Some additional arguments are available for handling unusual cases; see Mk/Uses/guile.mk for details.

Unless build or run is specified, then LIB_DEPENDS receives both the libguile library dependency and also any additional dependencies required by the guile version, e.g. libgc. Normally the port should not need any additional dependencies related to its use of Guile.

Software that uses Guile should be using the pkg-config mechanism to obtain compiler and linker flags. Some older or esoteric ports may be using guile-config or obtaining values directly from guile instead, which should also work (the alias argument may be useful in some of these cases).

The framework tries to inform the port of the desired Guile version using the following methods:

For some ports, it may be necessary to specify the version in additional ways, such as via CONFIGURE_ARGS or MESON_ARGS, depending on the port.

If none of these methods cause the port to select the specified Guile version when other versions are present, then preferably patch it to do so. If that is not feasible, specify the conflicts option to prevent building the port under conditions where it will detect the wrong version.

A port which installs a Guile extension or library, or a Scheme library that precompiles for Guile, should build a separate flavor for each supported Guile version. This is done by adding the flavors option.

Since each flavor must have a different package name, such ports must set PKGNAMESUFFIX, typically:

Such ports must install Scheme files to GUILE_SITE_DIR rather than to GUILE_GLOBAL_SITE_DIR even when the files are not version-specific. This often requires patching the port.

Additionally, if such a port installs a .pc file, it must be placed in GUILE_PKGCONFIG_PATH rather than in the global pkgconfig directory. This allows dependent ports to find a correct configuration for the specific Guile version in use.

If a Guile extension port installs a .so file, then it must usually be placed in the Guile-version-specific extensions directory. USE_LDCONFIG should usually not be used.

Any other files installed by a flavored port must likewise be in version-specific directories or use version-specific filenames. For documentation and examples, GUILE_DOCS_DIR and GUILE_EXAMPLES_DIR specify suitable locations in which the port should create a subdirectory, see below.

These variables are available in the port.

The following are defined as variables and as PLIST_SUB entries. The variable form is suffixed with _DIR and is a full path (prefixed with GUILE_PREFIX).

Before contributing a port with an rc.d script, and more importantly, before committing one, please consult this checklist to be sure that it is ready.

The devel/rclint port can check for most of these, but it is not a substitute for proper review.