Where is macport download file

If it doesn't succeed, that goes beyond the scope of this document. Filing a pull request on Github is considered superior. Your request will get faster attention and it is much easier for the MacPorts team to process it that way. If you decide to file a Trac ticket instead : First, please don't forget to add the port maintainer's email addresses in CC.

Second, to make it easier for the maintainer you should attach a diff against the Portfile to the new ticket, so generate a diff by running:. One thing to add is about patches, some may no longer be needed they're irrelevant with the new version, they've been integrated upstream, etc , so should be removed. Occasionally a MacPorts developer may wish to install more than one MacPorts instance on the same host. The first command temporarily removes the standard MacPorts binary paths because they must not be present while installing a second instance.

Introduction 2. Installing MacPorts 2. Install Xcode 2. Install MacPorts 2. Upgrade MacPorts 2. Uninstall MacPorts 2. MacPorts and the Shell 3. Using MacPorts 3. The port Command 3. Port Variants 3. Common Tasks 3. Port Binaries 4. Portfile Development 4. Portfile Introduction 4. Creating a Portfile 4. Example Portfiles 4. Port Variants 4. Patch Files 4. 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. 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. 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.

The pextlib Tcl library provides a variety of C extensions to add capabilities to Tcl procedures; for example, an interface to flock 2 and mkstemp 3. The registry is queried by MacPorts utilities for information about installed ports related to dependencies, port images, and simple user information about what is installed.

It provides abstraction over a modular receipt storage layer; where the default format is a SQLite database. Query the global file and dependency databases for file conflicts between a port being installed and a port already installed. All data is stored in a single file named registry. Furthermore, access to the registry may be locked using.

If found, these will be automatically converted to the new SQLite registry. Using this API listed below you can access the MacPorts Registry using the default receipt storage mechanism chosen in macports. Begin the creation of a new registry entry for the given port. Returns a reference ID to the registry entry created. Opens an existing registry entry. Returns a reference ID to the registry entry that was opened. Checks to see if a port exists in the registry. Returns 1 if the entry exists, 0 if not.

Store the given value with the property name in the receipt associated with the given reference. Retrieve the property name from the receipt associated with the given reference. Returns the value of the property, if the property exists. Get all installed ports, optionally all installed ports matching the given name, or the given name and version.

Returns a list of the installed ports. Returns the physical location the port is installed in on the disk. This is primarily useful for finding out where a port image is installed. Returns the name of the port that owns the given file, if the file is registered as installed, and 0 otherwise. Returns a list of all files associated with the given port if that port is installed, and 0 otherwise.

Returns a list for the given file name representing all data currently known about the file. This is a 6-tuple in the form of:. Returns a list of information concerning each file in the given file list, if that file exists in the registry.

The MacPorts testing framework uses tcltest for its unit tests as well as regression tests. To keep things simple, each module of MacPorts macports1. Each Tcl script in a module e. Every proc in a script e. Test procs should maintain the order in the original script and should be independent of one another.

Tests can be run only on an installed version of MacPorts so make sure you have run sudo make install. The script just runs the tests individually, printing the test file name, the total number of tests, number of passed, skipped, failed as well as constraints or errors of failed tests.

This is one possible output when running macports. Many tests need root privileges to run correctly, but will be auto skipped in the other case. Constraints are printed just below the final result, together with the number of test cases that require it, as so:.

The stack trace of an error that occurs during a test is printed below the constraints if any. Specific test cases can be run using the '-match' argument for the file that contains the test, from its parent directory.

In all tests we use this Portfile. This is the test. Example of sources. An example of a test file macports. A library. Getting started with tcltest. Official tcltest documentation. The MacPorts Project uses a system called Trac to file tickets to report bugs and enhancement requests.

Though anyone may search Trac for tickets, you must have a GitHub account in order to login to Trac to create tickets. If a build fails or is otherwise interrupted, and you try again, MacPorts tries to pick up where it left off. Before filing a ticket, sudo port clean the port that failed, then try again. The Problem Hotlist contains possible solutions to problems that affect many MacPorts users. If a solution to your problem listed there works, don't file a ticket.

An application bug that affects a large number of MacPorts users might merit a MacPorts bug for informational purposes only, but this should be done sparingly. If so, try a 'port uninstall foo ' and then reinstall. You might also want to run 'port -nR upgrade --force foo ' to rebuild ports depending upon port foo. Note that it is safest and recommended that most users always upgrade with 'port upgrade outdated' to update all ports at once.

Upgrading a single port can lead to software errors in other ports that have not yet been upgraded. Once you are logged into Trac, you may click New Ticket and you will be presented with a new ticket window shown in the graphic below.

Follow the Trac ticket guidelines below to fill out the form. If you are reporting a failed port install and a log was mentioned in the error, please use the I have files to attach to this ticket checkbox to add that log file to the ticket. This is a short overview of the guidelines for Trac tickets. Please see below for longer and more detailed explanations. Example: openssl 1.

There are certain conventions used to ensure that Trac tickets convey as much accurate information as possible so problems and contributions may be acted upon efficiently. Summary: [port] [version] [concise description]. Description: All details that might be relevant to someone reading the ticket.

Be sure to mention the versions of your operating system and Xcode install. Wiki formatting should be used to ensure that text is formatted correctly.

Use the Preview button before submitting. Submitters are advised to trim inline pastes and logs to what's really relevant to the report, as otherwise overly large ticket pages can become unmanageable. Long output, such as the full log from a port build, should be added as an attachment, not pasted inline.

See I have files to attach to this ticket below. No, thanks. Project Activity. Categories Software Distribution. License BSD License. Mit einem Experten sprechen. User Reviews Be the first to post a review of MacPorts! Report inappropriate content. Thanks for helping keep SourceForge clean.