| 120 | | ==== Managing and Fixing Qt Versions ==== #qt |
| 121 | | |
| 122 | | Fix issues in [query:status=assigned|new|reopened&port~=qt3|qt4|qt5 open tickets for Qt 3, Qt 4, and Qt 5], in particular allowing for concurrent installation of the various Qt versions. There are around 50 outstanding tickets for the various Qt versions, many of which would be resolved by installing all or enough of Qt* into the main install prefix subdirectories. Some involve patching and testing on multiple OSs. Some are probably invalid but need to be tested to determine validity. The end goal for this project is to allowing for concurrent installation of the various Qt versions, and then verifying and resolving as many issues as possible that weren't resolved by the concurrent changes. Requires knowledge of Portfile programming (Tcl), Qt programming (primarily C++), and Qt makefile programming (QMake); other programming knowledge that would be useful include shell (e.g., bash) and C. |
| 123 | | |
| 124 | | * Difficulty: Medium to Hard |
| 125 | | * Languages: Tcl, C++, QMake |
| 126 | | * Potential mentors: michaelld |
| 127 | | |
| 128 | | ==== Implement fakeroot functionality ==== #fakeroot |
| 129 | | |
| 130 | | Currently, MacPorts uses root privileges in the destroot phase. That should be replaced by a system that runs as the macports user but intercepts all operations that would require root privileges (chown/chmod/etc.) and record the resulting permissions in a database. |
| 131 | | |
| 132 | | The existing functionality of trace mode in darwintracelib1.0 could be leveraged for this task. |
| 133 | | |
| 134 | | * Difficulty: Medium |
| 135 | | * Languages: Tcl, C |
| 136 | | * Potential mentors: jeremyhu |
| 137 | | |
| 138 | | ==== Phase out dependency on Xcode ==== #xcode |
| 139 | | |
| 140 | | MacPorts currently requires a full Xcode installation, even though a lot of ports will install just fine with the Command Line Tools package only. Since we also have a number of ports that need Xcode to build, we cannot completely remove the Xcode dependency. Your task would be to provide a way for maintainers to easily identify ports that depend on Xcode and mark them as such, so MacPorts can warn users without Xcode installed that a port they want to install needs the full Xcode package. |
| 141 | | |
| 142 | | To achieve this, you can modify "trace mode", a `DYLD_INSERT_LIBRARIES`-based sandbox to track whether a port has accessed files belonging to the Xcode package. If it does, your modifications should cause a warning to be printed suggesting the port maintainers to add `use_xcode yes` to the Portfile (unless of course, it is already there). You should also implement an error message if a user without Xcode installed tries to install a port that has `use_xcode yes` set. |
| 143 | | |
| 144 | | * Difficulty: Medium |
| 145 | | * Languages: Tcl, C |
| 146 | | * Potential mentors: cal |
| 147 | | |
| 148 | | ==== Speed up trace mode ==== #tracemode |
| 149 | | |
| 150 | | Trace mode is a library preloading-based sandbox used to hide files that a port does not depend on or that are not part of a standard system's installation (such as `/usr/local`). This can avoid problems due to incompatible user-installed software and avoid "automagic" dependencies and increase the reproducibility of builds. |
| 151 | | |
| 152 | | Unfortunately, enabling trace mode adds a significant performance penalty to the build process. However, the trace mode code can certainly be optimized using appropriate cache data structures, such as a modified [http://en.wikipedia.org/wiki/Trie Trie]. Your task would be to identify the performance bottlenecks, draft appropriate caching data structures and implement them. |
| 153 | | |
| 154 | | * Difficulty: Medium to Hard |
| 155 | | * Programming languages: Tcl, C |
| 156 | | * Potential mentors: cal |
| 157 | | |
| 158 | | ==== Auto-detection of build dependencies ==== #dependencies-gen |
| 159 | | |
| 160 | | When creating a new portfile one of the problems is always the specification of the complete (and preferably minimal) list of build dependencies, especially when one starts with a complete install where most dependencies are already available. |
| 161 | | |
| 162 | | It is possible to invert the trace mode logic so that it detects all files a configure and/or build process accesses, in ${prefix} but outside of the port's build directory. This information can then be used to generate a dependency tree and information from the registry can then be used to simplify that tree so that it only lists direct dependencies. Can be combined with the above project. Consult mentor. |
| 163 | | |
| 164 | | * Difficulty: Medium to Easy |
| 165 | | * Programming languages: Tcl, C |
| 166 | | * Potential mentors: cal |
| 167 | | |
| 184 | | ==== Improve fetching from version control ==== #fetchtypes |
| 185 | | |
| 186 | | Make cvs/svn/git/hg/bzr fetch types checkout into the distfiles dir and then export into the work dir, to [[ticket:16373|avoid having to re-fetch]] after cleaning the work directory. |
| 187 | | "`fetch.type svn`" is inefficient in that it checks out a new working copy every time, directly to the work area. That would be like a normal port downloading the distfile every time. Instead, we should check out a working copy to that port's distpath, and then in the extract phase we should `svn export` it to the work area. |
| 188 | | |
| 189 | | Some checks will be needed in the fetch phase to ensure that an existing working copy: |
| 190 | | |
| 191 | | * has no modifications: check `svn status`. Ideally, we would try to clean up the working copy, for example by `svn revert`-ing modified or added or deleted files, and then in a second `svn status` run, delete any unversioned files. But it's already an improvement if we just discard the working copy if `svn status --ignore-externals` produces any output. |
| 192 | | * is from the right URL: check `svn info`: check if the "URL" is the one we want. If not, check that the "Repository Root" is a substring of the repository we want. If yes, try to `svn switch` to the URL and revision we want; if not, discard the working copy. |
| 193 | | |
| 194 | | * Difficulty: Easy |
| 195 | | * Languages: Tcl, C, bash |
| 196 | | * Contact: larryv |
| | 138 | ==== Managing and Fixing Qt Versions ==== #qt |
| | 139 | |
| | 140 | Fix issues in [query:status=assigned|new|reopened&port~=qt3|qt4|qt5 open tickets for Qt 3, Qt 4, and Qt 5], in particular allowing for concurrent installation of the various Qt versions. There are around 50 outstanding tickets for the various Qt versions, many of which would be resolved by installing all or enough of Qt* into the main install prefix subdirectories. Some involve patching and testing on multiple OSs. Some are probably invalid but need to be tested to determine validity. The end goal for this project is to allowing for concurrent installation of the various Qt versions, and then verifying and resolving as many issues as possible that weren't resolved by the concurrent changes. Requires knowledge of Portfile programming (Tcl), Qt programming (primarily C++), and Qt makefile programming (QMake); other programming knowledge that would be useful include shell (e.g., bash) and C. |
| | 141 | |
| | 142 | * Difficulty: Medium to Hard |
| | 143 | * Languages: Tcl, C++, QMake |
| | 144 | * Potential mentors: michaelld |
| | 145 | |
| | 146 | ==== Implement fakeroot functionality ==== #fakeroot |
| | 147 | |
| | 148 | Currently, MacPorts uses root privileges in the destroot phase. That should be replaced by a system that runs as the macports user but intercepts all operations that would require root privileges (chown/chmod/etc.) and record the resulting permissions in a database. |
| | 149 | |
| | 150 | The existing functionality of trace mode in darwintracelib1.0 could be leveraged for this task. |
| | 151 | |
| | 152 | * Difficulty: Medium |
| | 153 | * Languages: Tcl, C |
| | 154 | * Potential mentors: jeremyhu |
| | 180 | |
| | 181 | ==== Phase out dependency on Xcode ==== #xcode |
| | 182 | |
| | 183 | MacPorts currently requires a full Xcode installation, even though a lot of ports will install just fine with the Command Line Tools package only. Since we also have a number of ports that need Xcode to build, we cannot completely remove the Xcode dependency. Your task would be to provide a way for maintainers to easily identify ports that depend on Xcode and mark them as such, so MacPorts can warn users without Xcode installed that a port they want to install needs the full Xcode package. |
| | 184 | |
| | 185 | To achieve this, you can modify "trace mode", a `DYLD_INSERT_LIBRARIES`-based sandbox to track whether a port has accessed files belonging to the Xcode package. If it does, your modifications should cause a warning to be printed suggesting the port maintainers to add `use_xcode yes` to the Portfile (unless of course, it is already there). You should also implement an error message if a user without Xcode installed tries to install a port that has `use_xcode yes` set. |
| | 186 | |
| | 187 | * Difficulty: Medium |
| | 188 | * Languages: Tcl, C |
| | 189 | * Potential mentors: cal |
| | 190 | |
| | 191 | ==== Speed up trace mode ==== #tracemode |
| | 192 | |
| | 193 | Trace mode is a library preloading-based sandbox used to hide files that a port does not depend on or that are not part of a standard system's installation (such as `/usr/local`). This can avoid problems due to incompatible user-installed software and avoid "automagic" dependencies and increase the reproducibility of builds. |
| | 194 | |
| | 195 | Unfortunately, enabling trace mode adds a significant performance penalty to the build process. However, the trace mode code can certainly be optimized using appropriate cache data structures, such as a modified [http://en.wikipedia.org/wiki/Trie Trie]. Your task would be to identify the performance bottlenecks, draft appropriate caching data structures and implement them. |
| | 196 | |
| | 197 | * Difficulty: Medium to Hard |
| | 198 | * Programming languages: Tcl, C |
| | 199 | * Potential mentors: cal |
| | 200 | |
| | 201 | ==== Auto-detection of build dependencies ==== #dependencies-gen |
| | 202 | |
| | 203 | When creating a new portfile one of the problems is always the specification of the complete (and preferably minimal) list of build dependencies, especially when one starts with a complete install where most dependencies are already available. |
| | 204 | |
| | 205 | It is possible to invert the trace mode logic so that it detects all files a configure and/or build process accesses, in ${prefix} but outside of the port's build directory. This information can then be used to generate a dependency tree and information from the registry can then be used to simplify that tree so that it only lists direct dependencies. Can be combined with the above project. Consult mentor. |
| | 206 | |
| | 207 | * Difficulty: Medium to Easy |
| | 208 | * Programming languages: Tcl, C |
| | 209 | * Potential mentors: cal |
| | 210 | |
| | 211 | ==== Improve fetching from version control ==== #fetchtypes |
| | 212 | |
| | 213 | Make cvs/svn/git/hg/bzr fetch types checkout into the distfiles dir and then export into the work dir, to [[ticket:16373|avoid having to re-fetch]] after cleaning the work directory. |
| | 214 | "`fetch.type svn`" is inefficient in that it checks out a new working copy every time, directly to the work area. That would be like a normal port downloading the distfile every time. Instead, we should check out a working copy to that port's distpath, and then in the extract phase we should `svn export` it to the work area. |
| | 215 | |
| | 216 | Some checks will be needed in the fetch phase to ensure that an existing working copy: |
| | 217 | |
| | 218 | * has no modifications: check `svn status`. Ideally, we would try to clean up the working copy, for example by `svn revert`-ing modified or added or deleted files, and then in a second `svn status` run, delete any unversioned files. But it's already an improvement if we just discard the working copy if `svn status --ignore-externals` produces any output. |
| | 219 | * is from the right URL: check `svn info`: check if the "URL" is the one we want. If not, check that the "Repository Root" is a substring of the repository we want. If yes, try to `svn switch` to the URL and revision we want; if not, discard the working copy. |
| | 220 | |
| | 221 | * Difficulty: Easy |
| | 222 | * Languages: Tcl, C, bash |
| | 223 | * Contact: larryv |
