| 98 | | |
| 99 | | ==== Dependency calculation using SAT solving ==== #dependencies |
| 100 | | |
| 101 | | This task consists of implementing a new dependency engine for MacPorts. The current dependency engine works for everyday use, but it could be extended to support a number of features we would like to have, such as dependencies on variants (ticket:126), versioned dependencies, pre-computing a plan of action (and asking the user for confirmation), conflict resolution proposals and metapackages. Note that we don't expect you to accomplish all of these ideas in one GSoC – setting the base would already be a huge help. |
| 102 | | |
| 103 | | This task requires understanding the dependency relations (required for fetching, building, configuring; static and dynamic linking; dependence at runtime). |
| 104 | | |
| 105 | | Instead of re-inventing the wheel it might be helpful to use software available to solve the problem of dependency calculation, e.g. by implementing an interface to a [http://www.mancoosi.org/cudf/ Common Upgradeability Description Format]-based SAT solver. Such a solver could generate an execution plan we could propose to the user and finally execute when confirmed. For this task, the MacPorts concept of variants needs to be transformed into a representation the SAT solvers will be able to optimize. If time permits, rolling back on failed updates can also be implemented. There is also a [browser:trunk/dports/devel/libCUDF/Portfile libCUDF] port that might be helpful to look at. |
| 106 | | |
| 107 | | * Difficulty: Challenging |
| 108 | | * Languages: Tcl, C |
| 109 | | * Potential mentors: cal |
| 155 | | |
| 156 | | ===== Generate Portfiles with auto-detection of build toolchain ===== #portfile-gen |
| 157 | | |
| 158 | | To ease creation of new ports, the helper script [http://trac.macports.org/browser/contrib/portfile-gen/portfile-gen portfile-gen] is able to generated a Portfile stub by taking the name, version and possible a port group as input. This should be extended to handle more things automatically. Lots of options in a Portfile need to be figured out by the maintainer, although they could be extracted automatically from the source. |
| 159 | | |
| 160 | | With just a URL to the tarball of a software, portfile-gen can usually automatically extract the name and the version from the filename. Furthermore, the master_sites and distfiles can be derived from the URL, with special handling for sites like sourceforge/gnu/github/etc. However, it should also be possible to specify this later and start portfile-gen with a pre-downloaded tarball. The checksums for the distfiles can be generated after fetching the tarball (portfile authors should be warned to verify these with upstream!) and even more information can be collected when extracting the tarball. |
| 161 | | |
| 162 | | Different build systems usually have a unique way to be detected. For example, if a `configure.ac` or `configure.in` exists, but no `configure`, we need to run autoconf. If there is also a `Makefile.am`, but no `Makefile.in` this is using automake and we should better use `autoreconf` instead. If there is a `CMakeLists.txt`, we should include the cmake port group. If there is just a Makefile, but no `configure`, chances are high we can skip the configure phase with `use_configure no`. |
| 163 | | |
| 164 | | There are a lot more of such heuristics similar the examples above. This tasks includes implementing a framework where more of these indicators and the resulting actions can be added. |
| 165 | | |
| 166 | | The goal of this task is to create an easy-to-use Portfile generator that derives the basic information of a Portfile automatically. This should lower the amount of lines to be written by Portfile authors and lower the barrier for writing the first Portfile. If this is implemented with Tcl modules in mind, this could probably even go into base as a `port new` or `port create` command. |
| 167 | | |
| 168 | | * Classification: Medium |
| 169 | | * Languages: Tcl |
| 170 | | * Potential mentors: raimue, pixilla |
