Uninstall darwin port

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 Only use it if a port really needs a specific different compiler. In many situations, the requirements system described in the CompilerSelection page on the wiki is more flexible. 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. 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. 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.

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 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.

Dependencies on appropriate front end tools will be added automatically. This is supported when using Python 3. This can be set to the name of the PEP build back-end used by the port. If python. Clearing this option or setting it to an unsupported value will result in no back-end dependencies being added.

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. Default python. 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. Type of project that will be installed. This tells the PortGroup xcode how to destroot the project. Correct values are application and framework. Additional settings passed to the xcodebuild tool during the destroot phase. The following Portfile phase keywords affect the PortGroup xcode in a unique way. In most cases, you will not need to set any of these keywords in the Portfile.

See portfile-phase 7. This chapter contains information about the MacPorts file layout, configuration files, a few fundamental port installation concepts, and the MacPorts APIs. A map of the filesystem hierarchy used by MacPorts and the ports it installs. Much of it is based on hier 7. Formerly contained the registry information and receipts for installed ports, in flat-file format.

Holds the sources for the ports tree the Portfiles and also MacPorts base. System information files describing various information about the system since it was booted. The MacPorts configuration files often do not need to be modified for the general end user. They contain options that may be of use to advanced users and port developers. Some automatically configured options may need to be updated when migrating to a new CPU architecture or a new OS version.

There are three MacPorts configuration files that define important variables used by the MacPorts system: macports. Lines beginning with ' ' are comments, empty lines are ignored. This file is read by the port command and determines how it behaves.

Sets the directory where ports are installed. Directory where MacPorts keeps working data such as downloaded sources, installed port receipts, and the main registry. Formerly selected the storage type to use for the MacPorts registry: flat or sqlite. Currently, only sqlite can be used.

The machine architecture for which to build in normal use. Controls whether ports are built from source or downloaded as pre-built archives. Setting to 'always' will never use archives, 'never' will always try to use an archive and fail if one is not available. Format of archives in which to store port images. This controls both the type of archive created locally after building from source, and the type to request from remote servers.

Changing this will not affect the usability of already installed archives; they can be of any supported type. Supported types are: tgz, tar, tbz, tbz2, tlz, txz, xar, zip, cpgz, cpio.

Number of simultaneous make jobs commands to use when building ports. Sets env PATH , the directory search path for locating system executables rsync, tar, etc. The binpath is implicitly defined, but it may be overwritten by defining the variable in macports.

However, using a non-default binpath is discouraged and should only be performed by advanced users. This feature is especially useful if a host turns out to be consistently slow and therefore should be excluded for MacPorts' actions. Controls whether the rev-upgrade action will be run automatically after upgrading ports.

Controls the rev-upgrade functionality which checks for broken linking and can rebuild ports to fix it. Options for generated startup items, though this may be overridden by the startupitem.

Create system-level symlinks to generated StartupItems. This setting only applies when building ports from source. Extra environment variables to keep. Any variables listed here are added to the list of variables that are not removed from the environment used while processing ports. This is convenient, but may not be ideal if you care about the structure of your ports tree.

For example, some developers keep their ports tree synchronized across multiple computers, and don't want to also synch build directories. This file enables rsync synchronization of the default ports tree with the MacPorts rsync server when either of the commands port selfupdate or port sync are run.

This optional file specifies any variants you'd like to be invoked globally. If a variant specified in this file is not supported by a given Portfile, the variant is simply ignored.

MacPorts has a unique ability to allow multiple versions, revisions, and variants of the same port to be installed at the same time, so you may test new port versions without uninstalling a previous working version. The Port API provides all the primitives required for a Portfile to be parsed, queried, and executed. The port Tcl library supplies these procedures, all of which are generated at run-time using the options procedure in portutil.

The macports Tcl library loads the Portfile into a sub-interpreter, within which all port-specific code is run.

This process ensures that there will never be pollution of the Tcl space of other ports, nor the MacPorts libraries, nor the calling application. Portfiles are executed in a Tcl interpreter as Tcl code and not truly parsed strictly speaking , so every Portfile option must be a Tcl procedure.

Manages target registrations. All targets register themselves with the Port API. All Portfile options name, version, revision The Port API creates procedures for these options, and sets up the complex variable traces necessary to support option defaults. Manages a state file containing information about what variants were specified and what targets have run successfully. The API has very little information about the contents Portfiles; instead, it relies entirely upon the port Tcl library.

By keeping the high level API simple and generic, revisions to the underlying ports system will not necessarily require a revision of the high level MacPorts API. User options are passed as part of the call to mportopen. This is implemented in a highly generic fashion, and is used throughout the system. UI Abstractions are handled at this layer. See also Section 6. Should be called before trying to use any other procedure. This is a little tricky and unstable and only used by portindex.

Returns Tcl array s containing data from the PortIndex : port name, version, revision, variants, etc. Calls the mportexec function to execute the install target in the port.

Last year, Sweden shut down the last existing Confucius Institute in the Scandinavian nation. The US too harbour concerns about these Chinese State-run language and cultural institutes.

There is a lot more to follow and it seems that Australian PM Scott Morrison will emerge victorious in his fierce battle against the Communist nation. Your email address will not be published.

Save my name, email, and website in this browser for the next time I comment. Remember Me. April 23, Share on Facebook Share on Twitter. Become a Patron! Also Read. Free weekly newsletter Subscribe to our mailing list to receive most important stories and updates direct to your inbox every week! Share Tweet Send. One law could have exposed all Chinese poodles in Canada but China blocked it January 13, He failed.

Load More. Leave a Reply Cancel reply Your email address will not be published. Trending Comments Latest. January 2, Global Variables 5. Port Phases 5. Dependencies 5. Variants 5. StartupItems 5. PortGroups 6. MacPorts Internals 6. File Hierarchy 6. Configuration Files 6.

Port Images 6. APIs and Libs 6. The MacPorts Registry 6. Tests 7. MacPorts Project 7. Using Trac for Tickets 7. Using Git and GitHub 7.

Contributing to MacPorts 7. Port Update Policies 7. Updating Documentation 7. MacPorts Membership 7. The PortMgr Team 8. MacPorts Guide Glossary Glossary. Uninstall MacPorts Prev Chapter 2. Installing MacPorts Next.