Md flag writer mac process

Binary archives are automatically created whenever a port is installed, and can also be downloaded from a server. MacPorts runs a buildbot infrastructure that creates prebuilt binary packages for all ports in MacPorts for the default installation prefix. Buildbots exist for systems later or equal to Snow Leopard.

If a port builds successfully and its license and those of its dependencies allow binary redistribution, the archives are uploaded to packages. The archive file type is set in macports. The default format is tbz2 ; other options are: tar , tbz , tbz2 , tgz , tlz , txz , xar , zip , cpgz , and cpio. Binary packages are standalone binary installers that are precompiled; they do not require MacPorts on the target system.

As such, they are helpful in generating disk images or installers to be redistributed to users without relying on MacPorts for installation. Binary installers created with MacPorts are usually. MacPorts can also convert a. You can create binary packages using port as shown in the following examples. If you do that, your installer package conflicts with MacPorts on systems that do have MacPorts installed. Then use this custom MacPorts installation to build your package. Create a macOS. In most cases you probably want to package a port and all its library and runtime dependencies in a single package.

You can use a metapackage to do this. Create one using:. Just as with a single package, a metapackage can also be wrapped in a. A port is a distribution of software that can be compiled and installed using MacPorts. A Portfile describes all the required steps such as where to get the source code from upstream, which patches have to be applied and which other tools and commands are required to build the source code.

Each port consists of multiple files in a directory, usually within a category subdirectory of the root of a ports tree. The MacPorts Project distributes the main ports tree that is by default configured in all installations of MacPorts. This section serves as a reference for the directory structure of a single port and the layout of the files within. The only required file in a port is the Portfile.

Every port has a corresponding Portfile, but Portfiles do not completely define a port's installation behavior since MacPorts base has default port installation characteristics coded within it. Therefore Portfiles need only specify required options, though some ports may require non-default options. A common way for Portfiles to augment or override MacPorts base default installation phase characteristics is by using Portfile phase declaration s.

Any statements not contained within a phase declaration, no matter where they are located in a Portfile, are said to be in the global section of the Portfile; therefore the global section need not be contiguous. Likewise, to remove statements from the global section they must be placed within a phase declaration. The default installation phase behavior performed by the MacPorts base works fine for applications that use the standard configure , make , and make install steps, which conform to phases configure, build, and destroot respectively.

See Example Portfiles below. For a detailed description of all port phases, see the Portfile Reference chapter. Here we list the individual Portfile components for an application that conforms to the standard configure , make , and make install steps of most open source application installs. This should be the first line of a Portfile. It sets the correct editing options for vim and emacs. See Port Style for more information. Its use is optional and up to the port maintainer. A port may belong to more than one category, but the first primary category should match the directory name in the ports tree where the Portfile is to reside.

A port's maintainers are the people who have agreed to take responsibility for keeping the port up-to-date. The maintainers keyword lists the maintainers' GitHub usernames or email addresses, preferably in the obfuscated form which hides them from spambots. For more, see the full explanation of the maintainers keyword in the Global Keywords section of the Portfile Reference chapter. The checksums specified in a Portfile are checked with the fetched tarball for security.

For the best security, use rmd and sha checksum types. Checksums should also include the target file's size. To find the correct checksums for a port's distribution file, follow one of these examples:. In this section we begin by taking a look at a complete simple Portfile; then we see how to augment default phases by defining pre- and post- phases, how to override default phases , and finally how to eliminate port phases. To augment a port's installation phase, and not override it, you may use pre- and post- installation phases as shown in this example.

To override the automatic MacPorts installation phase processing, define your own installation phases as shown in this example. Because many software packages do not use configure , a keyword is provided to eliminate the configure phase. Another exception is the destroot phase may not be eliminated.

See the chapter Portfile Reference for full information. Variants are a way for port authors to provide options that may be invoked at install time. The most common actions for user-selected variants is to add or remove dependencies, configure arguments, and build arguments according to various options a port author wishes to provide. Therefore, take care to never use hyphens in variant names. In the example variant declaration below, the configure argument --without-x is removed and a number of others are appended.

Variants are used to specify actions that lie outside the core functions of an application or port, but there may be some cases where you wish to specify these non-core functions by default. Patch files are files created with the Unix command diff that are applied using the command patch to modify text files to fix bugs or extend functionality. If you wish to contribute modifications or fixes to a Portfile, you should do so in the form of a patch.

Follow the steps below to create Portfile patch files. Make a copy of the Portfile you wish to modify; both files must be in the same directory, though it may be any directory. Put the name of the port in the patchfile, for example, Portfile-rrdtool. The Portfile patch below will change the version and checksums when applied. Now you may attach the patch file to a MacPorts Trac ticket for the port author to evaluate.

Necessary or useful patches to application source code should generally be sent to the application developer rather than the port author so the modifications may be included in the next version of the application. Generally speaking, you should create one patch file for each logical change that needs to be applied. An example filename would be patch- destdir-variable-fix. Locate the file you wish to patch in its original location within the unpacked source directory and make a duplicate of it. You should execute diff from the top-level directory of the unpacked source code, because during the patch phase MacPorts by default uses the patch argument -p0 , which does not strip prefixes with any leading slashes from file names found in the patch file as opposed to -p1 that strips one, etc , and any path not relative to the top-level directory of the unpacked source will fail during the patch phase.

If you find an existing source file patch you wish to use that contains leading path information diff was executed from a directory higher than the top-level source directory , you will need to use the patch phase keyword patch. Place the patch patch-destdir-variable-fix.

MacPorts applies patch files automatically, but you may want to know how to apply patch files manually if you want to test patch files you have created or you wish to apply uncommitted Portfile patches. Change to the directory containing the file to be patched. In this example, we'll apply a Portfile patch to the postfix port. Now apply the patch from your Downloads folder, or wherever you put it. The patchfile knows the name of the file to be patched. To create and test Portfiles that are not yet published in the MacPorts ports tree, you may create a local Portfile repository as shown.

Replace the hypothetical user julesverne with your username in the example below. Open sources. For example, to open it into TextEdit:. The file URL should always appear before the rsync URL so that local Portfiles can be tested that are duplicated in the MacPorts tree, because port will always operate on the first Portfile it encounters.

Place the Portfiles you create inside a directory whose name matches the port, which should in turn be placed inside a directory that reflects the port's primary category the first category entry in the Portfile. See other sections in the Guide for help writing Portfiles.

If you've already written the Portfile elsewhere, you can instead copy the Portfile into this directory. If your Portfile needs to apply any patches to the port's source files, create a files directory and place the patchfiles in it, and reference the patchfiles in your Portfile, as explained in Creating Source Code Patches. After you create or update your Portfile, use portindex in the local repository's directory to create or update the index of the ports in your local repository.

Once the local port is added to the PortIndex , it becomes available for searching or installation as with any other Portfile in the MacPorts tree:. This section contains practical guidelines for creating Portfiles that install smoothly and provide consistency between ports. The following sections are on the TODO list.

Portfiles may be thought of as a set of declarations rather than a piece of code. It is best to format the port file is if it were a table consisting of keys and values. In fact, the simplest of ports will only contain a small block of values. Nicely formatted compact tables will result in more values being visible at the same time. The two columns should be separated by spaces not tabs , so you should set your editor to use soft tabs, which are tabs emulated by spaces. By default, the top line of all Portfiles should use a modeline that defines soft tabs for the vim and emacs editors as shown.

The left column should consist of single words, and will be separated from the more complex right side by spaces in multiples of four. Variable assignments and variant declarations are exceptions, and may be considered a single word on the left side, with a single space between words.

When items require multiple lines with line continuation, they can be separated from the previous and next items with a blank line. Indent the additional lines to the same column that the right side begins on in the first line. Should a key item such as a phase or variant require braces, the opening brace should appear on the same line and the closing brace should be on its own line. The block formed by the braces is indented for visual clearance. Braces merely quoting strings, for example the description of variants, are placed on the same line without line breaks.

Frequently multiple items are necessary in the second column. Unless the second column items are few and short you should place each additional item on a new line and separate lines with a backslash. Indent the lines after the first line to make it clear the items are second column values and also to emphasize the unity of the block.

At the end of this section the use of the obsolete PortGroup is suggested as an even shorter approach to the below described workflow. The following steps have to be taken to ensure a smooth transition for a MacPorts user updating his local installation using sudo port upgrade :. Using the PortGroup obsolete makes the task described in the previous subsection much easier:. The PortGroup defines a number of reasonable defaults for a port that is only there to inform users that they should uninstall it and install something else instead. You might want to override some of the defaults though.

If a port has to be removed from MacPorts one should consider the hints concerning replacing it by some alternative port given above. It is recommended to wait one year before the port directory is actually removed from the MacPorts ports tree. Every time a maintainer commits changes to MacPorts' ports Git repository the buildbot will check whether a rebuild of the corresponding port s would be necessary. If the port s in question are distributable their binary archives will be kept for subsequent distribution for all versions of the Mac operating system for which build machines are available.

See the list of builders to find out which platforms these currently are. If a build error occurred for a port its maintainer will be informed via an email so that problems which did not surface on the maintainer's machine will not go unnoticed. Port maintainers will find the waterfall and the builders views most useful since they give information about the build status and offer the possibility to build one's port s on specific builders. Thus the buildbot helps to keep MacPorts consistent on various macOS versions, i.

Currently only the default port variants will be built and kept. This chapter serves as a reference for the major elements of a Portfile: port phases, dependencies, StartupItems, variables, keywords, and Tcl extensions. MacPorts keywords are used to specify required or optional items within a Portfile, or to override default options used by MacPorts base for individual ports. The global keywords listed below specify information for ports as a whole, whereas the keywords listed under a port phase specify information to be used during a particular installation phase.

The first non-comment line of every Portfile; it should be followed by PortGroup inclusions if any and then a blank line. It defines which version of the Portfile interpreter will be used. There is currently only one version. The name of the port. To avoid special interpretation by shells and the like, names should contain only alphanumeric characters, underscores, dashes or dots.

Optional keyword default is 0 that is used to track port revisions. It should not be incremented for port revisions unless it would benefit users to upgrade an installed port, and cleared when the port is updated to a newer version. It should be used if a bug in the Portfile was found and all installations of this port have to be updated.

If the change only affects new installations, there is no need to increase it. An optional keyword default value is 0 that must be used when a port is updated to a version that is numerically less than the previous version, for example 1.

Installation with Homebrew

Some Portfile authors have used large epoch values that look like a date, but there is no reason to do so. The epoch is simply an unsigned integer, and the only requirement is that it never be decreased. Remember that once set, it can never be removed because it takes precedence over version and revision. An epoch is not needed for most ports. If a port's version numbers advance in normal dotted-decimal sequence, there is no reason to add an epoch.

The category under which the ported software falls. The first category should be the same as the directory within which the Portfile is stored; secondary and tertiary categories may be selected. Most ports have only a single maintainer, but some ports have two or more co-maintainers. The maintainers keyword lists the maintainers' GitHub usernames or email addresses.

GitHub usernames start with an symbol. Email addresses are preferably listed in the obfuscated form below to hide them from spambots:. For addresses in other domains, e. Braces can be used to express that these refer to the same person, for example the GitHub username and an email. The address nomaintainer designates a port that is not maintained by anybody and may be modified by any committer.

Feel free to claim maintainership of a nomaintainer port if desired. The address openmaintainer designates a port that has a maintainer who allows minor changes to be committed without his or her prior approval. Port maintainers who are not committers are encouraged to add openmaintainer to their ports.

A list of the platforms on which the port has been tested. Required, but not interpreted in any way by the software at this time; it is purely informational for users. In general, it can just be set to darwin. See also os. The CPU architectures for which this port can be built. If this option is not set, it is assumed that the port can build for all archs. If a port does not install any architecture-specific files, use the special value noarch. The proper format for license consists of the license name, followed by a hyphen and number if indicating a specific version.

A space should be placed between licenses if there is more than one that applies. If an element in the license list is itself a list, it is interpreted as offering a choice of any one of the licenses in the sub-list. If the version specified in this case is also the earliest version, just leave out the version number entirely since it implies all versions. By default, it is assumed that ports may use libraries or headers from their dependencies and thus form a derivative work.

A dependency with an incompatible license thus prevents the port from being distributed in binary form. If a dependency with an incompatible license is not used in such a way that a derivative work is formed, or should not prevent binary distribution for any other reason, add its name to this list. Global variables are variables available to any Portfile. For a list of additional variables available to ports that are assigned to a MacPorts Portgroup, see portgroup 7. Full path to the Portfile of the port being executed.

Portfile repositories are defined in the file sources. The underlying operating system platform e. The version number of the host operating system e. OS X The major version number of the host operating system e. The MacPorts port installation process has a number of distinct phases that are described in detail in this section. The default scripts coded into MacPorts base performs the standard configure , make , and make install steps. For applications that do not conform to this standard, installation phases may be declared in a Portfile to augment or override the default behavior as described in the Portfile Development chapter.

Execute commands to run test suites bundled with a port, available only for a fraction of ports. This is an optional phase, run only if port test is executed, and always works with a build from source, not a binary. A failure is only for the user's information, and does not block a subsequent installation from the build.

MacPorts uses the destroot phase to provide:. Port uninstalls - a port's files may be cleanly uninstalled because all files and directories are recorded during install. In other words, port phase keywords are not located within port phase declarations, but rather they refer to port phases and set options for those phases, and they take effect whether or not phase declarations have been explicitly defined in a Portfile. Keyword list modifiers are keywords that end in -append, -delete or -replace. Keywords that support list modifiers are identified under appropriate reference sections below.

There is also a deprecated syntax for -replace which takes only one argument and behaves the same as -strsed. Preserve configure defaults set by a previously executed Portfile keyword or by MacPorts base. Ports in a PortGroup have default library dependencies set by MacPorts base.

When a variant requires more or fewer dependencies, distfiles, or patchfiles, when the variant is invoked you want to add or remove items to the appropriate keyword values list set in the global section of the Portfile. Use the appropriate keywords, for example:. But it should be noted that all keyword argument modifiers implicitly support keyword list modifiers. For example, the keyword configure. You may also use mirror site lists predefined by MacPorts. Here the sourceforge, gnu, and freebsd mirrors are used. For ports that must fetch multiple download files from different locations, you must label the files with tags and match the tags to a distfiles keyword.

The format is mirror:subdirectory:tag. The full distribution filename, including the extract suffix. Override it to store multiple ports' distfiles in the same directory such as multiple ports providing different versions of the same software , or if a stealth update has occurred. Sets the path to source directory relative to workpath. It can be used if the extracted source directory has a different name then the distfile. Also used if the source to be built is in a subdirectory. Change the fetch type. This is only necessary if a bzr , cvs , git , hg , or svn checkout is being used.

Values: standard bzr cvs git hg svn. Bzr may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via bzr may cause non-reproducible builds, so it is strongly discouraged. The bzr fetch. CVS may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via CVS may cause non-reproducible builds, so it is strongly discouraged.

The cvs fetch. Git may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via Git may cause non-reproducible builds, so it is strongly discouraged. The git fetch. Optional tag for fetching with git, this specifies the tag or other commit-ish that git should checkout.

Mercurial may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via Mercurial may cause non-reproducible builds, so it is strongly discouraged. The hg fetch. Optional tag which should be fetched.

Can be a Mercurial tag or a revision. To prevent non-reproducible builds use of tip as revision is discouraged. Subversion may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via Subversion may cause non-reproducible builds, so it is strongly discouraged.

The svn fetch. Optional tag for fetching with Subversion, this specifies the peg revision to checkout; it corresponds to the REV syntax of the svn cli. Optional tag for fetching with Subversion, this specifies whether to check out the code into a working copy, or just export it without the working copy metadata. An export is preferable because it takes half the disk space, but some software expects to be built in a working copy for example because it wants to record the revision number into itself somewhere.

Checksum s of the distribution files. For ports with multiple distribution files, filenames must be included to associate files with their checksums. Each checksum entry should also indicate the file's size. At least two checksum types typically rmd and sha should be used to ensure the integrity of the distfiles. This keyword is used to specify that the extract phase should be done as the root user. This keyword is for downloads that are compressed using the 7z algorithm. When invoked, it automatically sets:.

This keyword is for downloads that are tarred and bzipped. This keyword is for downloads that are compressed using the lzma algorithm. This keyword is for downloads that are uncompressed tar archives. This keyword is for downloads that are compressed using the xz tool. This keyword is used to specify if the directory worksrcdir is part of the distfile or if it should be created automatically and the distfiles should be extracted there instead. This is useful for distfiles with a flat structure which would pollute the worksrcdir with lots of files.

Only use if default extract behavior is not correct for your port. Main arguments to extract. Specify patch files to be applied for a port; list modifiers specify patchfiles to be added or removed from a previous patchfile declaration. Main arguments to patch. MacPorts base sets some important default configure options, so should use the -append version of most configure keywords so you don't overwrite them.

For example, MacPorts base sets default configure. Sets if the configure phase should be run. Can be used if the port has no. Set environment variables for configure; list modifiers add and delete items from a previous Portfile configure. If available, it is encouraged to use the predefined options like configure. Set optimization compiler flags; list modifiers add or delete items from a previous Portfile configure. Select a compiler suite to fill the compiler environment variables. Manually set variables are not overwritten. Keep in mind that not all compiler suites might be available on your platform: gcc Default: llvm-gcc Values: gcc Main arguments to configure.

There is a default universal variant made available to all ports by MacPorts base, so redefining universal keywords should only be done to make a given port compile if the default options fail to do so. Only use it if you can't use build. Default: default the default Make on the current platform. Values: default bsd gnu xcode. Set environment variables for build; list modifiers add and delete items from a previous Portfile build.

This keyword is for specifying whether or not it is safe for a port to use multiple CPUs or multiple cores in parallel during its build phase. The number of simultaneous jobs to run when parallel build is enabled. The default value is based on the variable buildmakejobs in macports. Default: If buildmakejobs is 0, the number of CPU cores in the machine, or the number of GB of physical memory plus one, whichever is less.

Main arguments to test. Set environment variables for test; list modifiers add and delete items from a previous Portfile test. A port must destroot properly or the port will not install correctly, upgrade, or uninstall. If not, you may need to set this variable, or even patch the application's Makefile. If a port is not compliant with the standard, set it to yes.

You can find the macports standard in MacPorts File Hierarchy or in the porthier 7 man page. If destroot. Use port contents portname to see the location for all files that were installed by a given port. The keywords used when specifying dependencies in a Portfile are related to port install phases, and they refer to what are called library, build, fetch, extract and run dependencies. Though all of them install dependencies before a given port is installed, specifying dependencies with the correct keyword is important for proper port upgrade and uninstall behavior, or when running targets other than install.

For example, you may not uninstall a port that is a library dependency for another installed port, though you may remove one that is a build dependency. Likewise, if you run the fetch target for a port, only the fetch dependencies will be installed first, so they should be all that is needed for that target. The list of dependencies to check before phases fetch , checksum , extract , patch , configure , build , destroot , install , and package.

Fetch dependencies are needed to download the distfiles for a port, and are not needed at all once the software is installed. The list of dependencies to check before phases extract , patch , configure , build , destroot , install , and package. Extract dependencies are needed to unpack a port's distfiles into the work directory, and are not needed at all once the software is installed. The list of dependencies to check before phases configure , build , destroot , install , and package.

Build dependencies are needed when software is being built, but not needed at all once it is installed. Library dependencies are needed both at build time for headers and libraries to link against and at run time. The list of dependencies to check before phase test. Test dependencies are only needed when the port enables testing i. The list of dependencies to check before phases destroot , install , and package.

Run dependencies are needed when the software is run, but not to compile it. There are two types of dependencies: port dependencies and file dependencies. Port dependencies can be satisfied by reference to a port the MacPorts registry is queried , or by reference to a file whether provided by a port or not. The most commonly-used type of dependencies in Portfiles are port dependencies, because dependencies should be provided by MacPorts ported software whenever possible, and usually only one port can provide the needed libraries and files.

But when satisfying a dependency with vendor-supplied software is preferred for special reasons, or when it is possible for more than one port to satisfy a dependency, then file dependencies may be used. File dependencies should only be used if one of the reasons listed above applies. There are three types: bin for programs, lib for libraries, and path for any installed file. See the examples below:. MacPorts variants are conditional modifications of port installation behavior during port installation. There are two types of variants: user-selected variants and platform variants.

User-selected variants are options selected by a user when a port is installed; platform variants are selected automatically by MacPorts base according to the OS or hardware platform darwin, freebsd, linux, i, powerpc, etc. User-selected variants are those that are defined so a user can invoke them to enable port options at install time. Variant names may contain only letters, numbers and underscore characters. In particular, the hyphen is not a valid character in variant names because it would conflict with the notation for deselecting a variant.

The variant declaration may contain any keywords that can be placed in a Portfile's global section. Dependencies and conflicts with other variants in the same port can be expressed with requires and conflicts options as shown below. This allows for Portfile modularity and also allows users to suppress default variants if they wish. When using MacPorts on macOS, a universal variant is defined by default to configure ports with universal flags. The variant can be overridden if the default code does not work see the Configure Universal section above , or suppressed if a universal variant does not function properly for a given port.

User-selected variants ought to provide a description, which will be displayed when using command port variants foo. The syntax used for the description keyword is shown below. Descriptions should be short but clear, and not merely repeat the name of the variant. To allow for compatibility for possible MacPorts GUI support, a good rule of thumb is to use sentence fragments for brevity, with a capitalized first letter and no trailing punctuation.

Think of them as short labels such as ones you'd find next to a GUI checkbox or radio button. Platform variants are either defined by default in MacPorts base, or defined by a port author to customize a port's installation according to OS operating system or hardware platform. MacPorts allows platform-specific port options to be specified in a Portfile for handling differences between platforms and versions of the same platform.

Though a combination of OS version and hardware platform may be specified in a single platform statement e. For example, to select Darwin versions 9 and 10 while excluding all others, you would need two statements: platform darwin 9 and platform darwin Alternately, you could make that behavior the port's default, and add a platform darwin 8 block to remove it again. A MacPorts Portfile is a Tcl script, so it may contain any arbitrary Tcl code you may learn about in the Tcl documentation.

However, few authors will use arbitrary Tcl code; the vast majority will use a subset of Tcl commands and a number of Tcl extensions that are coded within MacPorts for performing the most common tasks needed for Portfiles. The list below is a list of useful Tcl commands for Portfile development and Tcl extensions provided by MacPorts base. The standard Tcl file command can be used for a number of operations on files, such as moving, renaming, deleting, or creating directories, among others. For a complete list, consult the Tcl reference manual for the file command , or the Tcl file manpage in the n section of manpages on your machine using man n file.

Remove a file or with -force a directory and its contents. For the above operations provided by Tcl's file command, MacPorts provides the following shorthands. These should be used in preference to the Tcl commands above, as they may work around certain bugs. Similar to file rename but correctly handles renames that only change the case of a file on a case-insensitive filesystem. Change to dir and install file s to a destination directory. Install the file s matching the glob pattern to a destination directory.

It supports a small subset of the commands known from sed 1. Replaces the first instance of regex with replacement. The same as the previous format, except all instances of the pattern will be replaced, not only the first mnemonic: 'g' is for global. Allows text specified by a regular expression to be replaced by new text, in-place the file will be updated itself, no need to place output into a new file and rename.

Replace text given by the regular expression portion of the command with the replacement text, in all files specified. Use -locale to set the locale. If you need it to work on non-ASCII characters you need to set a locale with the correct charset for the file, e. Use -- to end option processing and allow any further dashes not to be treated as options.

Add a new local user to the system with the specified uid, gid, password, real name, home directory and login shell. Check if a local user exists. Returns the uid for the given user, or 0 if the user wasn't found. Checking for the root user is not supported because its uid is 0, and it will always exist anyway. Add a new local group to the system, with the specified gid, password, real name, and with a list of users as members. Check if a local group exists and return the corresponding gid.

This can be used with adduser:. There are three categories of StartupItem keywords. This is useful for MacPorts installations that are not used with root privileges. Chooses the subdirectory in which to install the StartupItem. Also affects how it will be loaded: LaunchDaemons must be loaded as root, and only one instance will run for the whole system. LaunchAgents are loaded as a normal user, and one instance per user can run.

Path to a logfile for logging events about the lifetime of the StartupItem. Depending on the type of StartupItem, and the manner in which it is started, standard output from the daemon may also be directed to the logfile.

  • ApplePi-Baker – Overview;
  • mac os x dock add application.
  • wd passport ultra mac compatible!
  • Elevating Privileges Safely.
  • Shell tricks: the OS X open command.

Control whether or not to log events to the log file. If logevents is set, events with timestamps are logged to the logfile. Sets the name for the StartupItem. Defaults to the name of the port, so this keyword is usually unnecessary. The type of the StartupItem. Supported values are launchd for a macOS launchd. Used when a port needs to install more than one StartupItem, this option consists of a list where alternating elements represent keys and values.

Each key corresponds to one of the startupitem. Each StartupItem defined in the list must specify at least a name. Any keys that are not defined for a given StartupItem will use the value of the corresponding startupitem. Daemons run continuously, so monitoring the health of daemon processes and restarting them if they die is an important StartupItems' feature. Specifies the name of the daemon to be run. It may have multiple arguments, but they must be appropriate for a call to exec; arbitrary shell code may not be used.

A daemon to be started with startupitem. Often daemons have a command switch to run in the foreground, and this method should be used for daemons that detach. Notice that the script is not a daemon; rather the script indirectly launches the vm-pop3d daemon. - MacOS X - ApplePi Baker - Prep SD-Cards for IMG or NOOBS

Specify a shell script to start, stop, and restart the daemon. In the absence of startupitem. Wrap the stop, start, and restart values in quotes so they will be placed in the wrapper tagged as a single element. Shell code that will be executed prior to any of the options startupitem. It specifies two things: a process id PID file handling method, and a pidfile name and path. The started process must delete the PID file if this is necessary. A PID file is not needed to detect process death for daemons launched directly by daemondo. As with executable StartupItems, daemondo remembers the PID of the launched process and tracks it automatically.

A port with a StartupItem places a link to a. You may enable a startup script tag the. You may stop a running startup script, disable it tag the. During port installation a MacPorts StartupItem creates a. For example, the StartupItem for the mysql5 port is org. The wrapper manipulates the script as specified in the startupitem. An example wrapper script snippet is shown below. Options livecheck and distcheck are especially useful for port maintainers, but others may also find this information valuable.

Livecheck checks to see if MacPorts can query the developer's download site to determine if a newer version of the software has become available since the port was installed. Generic download site options are to specify a moddate modification date of a URL resource , a regex retrieve the version by applying a regex to a URL resource , regexm retrieve the version by applying a multi-line regex to a URL resource , md5 compares the md5 sum of a URL resource or none no check. Values: freecode sourceforge googlecode moddate regex regexm md5 none.

Name of the file release for sourceforge checks. Use the name of the package release. You may use this keyword without livecheck. Regular expression to parse the resource for regex checks. Be sure to use a regular expression grouping around the version component. Also remember that square brackets need to be quoted because Tcl otherwise interprets them as a procedure call. Distcheck reports whether or not the distfile s specified in a Portfile are still available on the developer's download site. Examples are given below. This option can be used to disable distcheck. It specifies what kind of check should be performed on distfiles: moddate check if the Portfile is older than the distfile or none no check.

PortGroups are simply include files for portfiles. They can define as much or as little as a portgroup author feels is necessary to provide a set of definitions or behaviors common to a group of portfiles, in order that those portfiles can be expressed as simply as possible with minimum redundancy. The requirements of a minimum portfile using a portgroup varies by portgroup. The sections below devoted to each portgroup or, for portgroups not documented there yet, the comments in the header of the portgroup file itself should provide guidance on how each portgroup is used.

Prospective MacPorts developers are also encouraged to examine existing portfiles that use these portgroups. The github portgroup allows for efficient porting of software hosted on GitHub. This portgroup greatly simplifies the porting of software hosted on GitHub. Provided a GitHub repository author follows common GitHub practices, a port can be almost fully configured simply by declaring the repository coordinates.

The github portgroup is indeed capable of configuring, amongst other things:. The main port configuration is triggered by the usage of the github. By default, the port name will be set to the GitHub project name project and version will be set to the GitHub project version. The port name can be overridden by using the name keyword. If, for example, the project uses tags such as v1.

GitHub, and as a consequence the github portgroup, offers multiple mechanisms to get a distfile:. Distfile from a GitHub release. Distfile from a GitHub download. The default behaviour of the portgroup is using GitHub automatically generated distfile from a git commit or tag. However, the best practice should be using a GitHub release. The default behaviour of the github portgroup is leveraging GitHub's ability to create a distfile from a git tag or commit.

In this case, the distname is irrelevant and should not be set. If the project's developers do not tag their releases, they should be encouraged to do so. Until they do, or in the case in which an untagged development version has to be used, port maintainers have the possibility of specifying a git commit hash and manually set the version field.

If the project does not assign version numbers the port maintainer has to define one. If, for example, the port maintainer decides to use a changeset with the hash 0ffcdcd3c73d , committed on April 1, , then the following would be used:. The github portgroup allows maintainers to easily configure the distfiles when the project uses GitHub releases. A release is the best distfile candidate, and project maintainers should be encouraged to use them.

To enable this feature, the following keyword must be used:. By default, the github portgroup sets distname to:. However, GitHub does not enforce any rule for release distfiles, so port maintainers may need to override the distname as they would do for other ports. Older projects use the discontinued downloads service. New GitHub downloads can no longer be created, but old ones are still available.

How to get Flag in Menu Bar on Mac

If the project doesn't have GitHub releases but does have GitHub downloads, they can be used using the following keyword:. Since GitHub doesn't enforce any naming rules for downloads, the portgroup can only provide a sensible default value for distname , which can be overridden if necessary. Further still, many Github projects have automatically-generated archive URLs that can be used for downloading distfiles. This can be enabled via archive as follows:. If the project uses git submodules, some projects' tag- or commit-based distfiles will not contain all the necessary files. Once again, the best distfile candidate if available is a distfile from GitHub releases, as described in the previous sections.

However, in the case a project doesn't provide any other alternative, a project using submodules can be successfully retrieved by fetching the sources using git and then using a post-fetch to initialize the submodules:. PortGroup gnustep allows for efficient porting of GNUstep-based open source software using the GNU objective-C runtime that defines options for the configuration, build, and destroot phases, and also defines some values for GNUstep-based software. A minimum Portfile using the gnustep PortGroup class need only define the fetch and the checksum phases.

Portfiles using the gnustep PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. This helps making the patching process easier on Darwin. Many GNUstep packages include a Documentation sub-directory that is not built by default. Enabling this variant builds and installs the included documentation. PortGroup gnustep supports both the traditional gnustep file layout and the new fhs file layout. However, a given ported application does not necessarily support both. The Portfiles have access to many procedures to handle these two layouts:.

The golang PortGroup allows for efficient porting of Go-based open source software. This PortGroup greatly simplifies the porting of software written in Go, especially when the software and its dependencies are hosted on GitHub or Bitbucket. Provided a project author follows common Go packaging practices, a port can be almost fully configured simply by declaring the package identifier.

The main port configuration is triggered by the usage of the go. By default, the port name will be set to the package name project and version will be set to the project version. When the domain is either github. See those PortGroups' documentation for details. The PortGroup provides a keyword to facilitate listing dependencies: go.

Supply a list of vendor package IDs, their versions git commit hashes, labeled "lock" as in "lockfile" , and their checksums as follows. The packages and their versions can usually be found in a lockfile e. All checksum types supported by the checksums keyword are supported here as well. Note that go. Such dependencies must be handled manually. After the extraction phase, the vendor packages will be placed alongside the main port code as appropriate in the GOPATH.

Assuming this results in a binary with the same name as the project, and that there are no other files to install, the following is sufficient for the destroot phase:. When the golang PortGroup is declared within a Portfile, the following variables are provided during port install. The package identifier of the port, e. Go can target these platforms, but individual ports should override this as necessary if only some are actually supported.

Portfiles using the haskell PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. Synopsis: the first argument is the package name, as called by hackageDB; the second is the version number. Default: creates and installs into destroot the register.

Portfiles using the java PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. This keyword indicates that the port requires a Java installation of the specified version. If no such installation can be located, and no fallback option is specified see below , the port will fail at the pre-fetch phase. Note that Java 8 and earlier are "1. This keyword indicates an optional port dependency that will be added to the ports 'depends-lib' list in the case a prior installation of Java satisfying the requested version can not be found.

PortGroup perl5 allows for efficient porting of perl modules and other perl open source software. Portfiles using the perl5 PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. Perl modules are ordinarily assumed to be built with ExtUtils::MakeMaker.

Use this keyword if a module must be built using Module::Build instead. When the perl5 PortGroup is declared within a Portfile, the following variables are provided during port install. Portfiles using the python PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. Defines the python versions supported by this port.

In this case, no subports are defined, and python. For modules i. If not explicitly set, a reasonable default is chosen from the list in python. For applications i. It can be changed in variants if desired. Can be cleared if no suffix is desired. When the python PortGroup is declared within a Portfile, the following variables are provided.

The python version in use in the current subport. This will be one of the versions listed in python. The python version in use in the current subport, in normal dotted notation. For example, if python. The prefix in which the current python version is installed. The Python dynamic library path, i. The path to python's lib directory, i. Path to the Python site-packages directory. When the ruby PortGroup is declared within a Portfile, the following variables are provided during port install.

Path to the Ruby vendorlibdir directory i. The name for the Ruby architecture-dependent directory name i. Path to the Ruby vendor archdir i. PortGroup xcode allows for efficient porting of Xcode-based opensource software. A minimum Portfile for PortGroup xcode uses defaults for the configuration, build, and destroot phases.

It also defines some values for Xcode-based software. Using PortGroup xcode is a way to make your port able to tolerate Xcode version updates because the PortGroup is tested against all supported macOS and Xcode versions. Portfiles using PortGroup xcode allow for port authors to set the following keywords in addition to the general Portfile keywords. If unset, Xcode Tools should be able to determine it automatically. It usually succeeds if there is only a single project in the directory.

If present, it overrides build. Additional settings passed to the xcodebuild tool during the build phase.

Darwin (operating system)

Type of project that will be installed. This tells the PortGroup xcode how to destroot the project. Defaults to uuid of build changed on each build of portable executable. Use electron-builder node-gyp-rebuild instead. Currently, only react-cra is supported. If react-scripts in the app dependencies, react-cra will be set automatically. Set to null to disable automatic detection. Works when npmRebuild is set to true. Resolving to false will skip dependencies install or rebuild.

Following options can be set also per platform top-level keys mac , linux and win if need. Not supported on Linux, file issue if need default icon will be x-office-document. The value can be Editor , Viewer , Shell , or None. Intended for command line usage:. The license name. Currently, only macOS and Linux supported. The function or path to file or module id to be run after pack but before pack into distributable format and sign.

Because in a configuration file you cannot use JavaScript, can be specified as a path to file or module id.