GSOC Ideas

Thu Feb 7 13:11:54 UTC 2019

As part of the GSOC application, it would be good to update the “Projects” section of the wiki page [1].
Here are a few idea that I was able to come up with.
I would appreciate any feedback.

-Marcus

[1] https://trac.macports.org/wiki/SummerOfCode#Projects

 1. Update Orphaned Ports
     I originally became interested in MacPorts development because I wanted to install certain software, and the MacPorts version was (slightly) out of date.
     Fixing and/or updating ports is an excellent introduction to the MacPorts systems (phases, variants, PortGroups, etc.).
     It forces you to read the documentation (but only as an absolute last resort) and examine commit histories.
     This would not be the entire GSOC project, but it could be used as part of the application process and/or a supplement to the main project.

 2. Tweak qt5 PG
     Currently, the qt5 PG defines three procedures to declare dependencies on Qt components
     (https://github.com/macports/macports-ports/blob/000ec3f12e02aa6c3159bd1608cd8607eb9e18f0/_resources/port1.0/group/qt5-1.0.tcl#L572).
     These should almost certainly be `options`.

 3. Make blacklisting MacPorts compilers easier.
     Currently, the compiler_blacklist_versions PG makes blacklisting ranges of compilers very easy, but it only works for Xcode compilers.
     It would be nice, for example, to be able to have something like `compiler.blacklist-append {macports-clang < 6.0}`.
     See https://trac.macports.org/ticket/56093.

 4. Add support for x86_64h architecture.
     x86_64h is a lot like  x86_64, except it allows compiler to take advantage of the Haswell microarchitecture.
     Unlike other architectures in MacPorts, x86_64h and x86_64 libraries can be linked together.
     As a side note, GCC does not support `-arch x86_64h`, but Xcode and MacPort Clang do.
     See https://github.com/openssl/openssl/pull/6497 for a discussion on why OpenSSL did NOT want to add support for x86_64h.

 5. Allow for multiple runs of each phase.
     There are times when it is convenient to run configure/build/destroot more than once.
     For example:
     *) cargo depends on the port cargo-stage1, whose only purpose is to help build cargo.
         Instead, one could run configure/build and use the resulting binary without installing another port.
     *) fluidsynth depends on a subproject, which has no use beyond aiding the build process.
         The subproject does not inherit the MacPorts settings.
         It would be nice to configure/build the subproject properly (from a MacPorts point of view).
         See https://github.com/macports/macports-ports/pull/3583.
     *) 75% of the muniversal PG is to get multiple runs of the configure/build/destroot phases.

 6. Allow a variant to more elegantly become “undefaulted.”
     When it was decided that support for the FLTK toolkit should no longer be the default in octave, the (previously default) variant fltk was renamed fltk_toolkit.
     There is another port (I cannot remember which one) that hacks together another solution to avoid renaming a previously default variant.
     Is there a better solution?

 7. Find a way to make mass revision increases easier.
     There are times when upgrading a library means increasing the revision of ALL of its dependencies (e.g. readline, icu, and libgcc).
     Finding all of these ports can be tricky and error prone.
         -) Some ports do not have an explicit dependency.
         -) Some ports do not explicitly set a revision variable.
         -) If there are sub-ports, then there might be multiple revision variables.
     Personally, I have a script that partially automates this process, but it is far from ideal.
     Is there a better way?

 8. Find a solution to the longstanding issue of std::locale being broken in GCC.
     See https://trac.macports.org/ticket/15653

 9. Prevent `port reclaim` from removing build dependencies.
     See https://lists.macports.org/pipermail/macports-users/2019-January/thread.html#46344

10. Improve the finding of dependencies.
      Finding dependencies can sometimes be difficult:
       *) Read the project documentation, which is sometimes incomplete.
       *) Read the code, but dependencies can be quite well hidden within the build system or the code itself.
       *) Run the port command in trace mode, which is excellent, but not 100%.
       *) Wait for the bug reports.
      Can this be improved?
      See https://trac.macports.org/wiki/SummerOfCode#dependencies-gen.

11.Give Portfile better access to CFLAGS, CXXFLAGS, etc.
     Currently, CFLAGS and the like are set late in the process (arch flags added, -pipe added, etc.).
     Of course, there are good reasons for this.
     Unfortunately, this means that there is no Portfile access to these values.
     This causes some ugly workarounds such as duplication of code from the base or `configure.cmd printenv` and `configure.post_args {>> Makefile.macports.inc}`.
     Is there a way to give the Portfile access to most of these values?
     See https://lists.macports.org/pipermail/macports-dev/2018-November/thread.html#39694
     See https://github.com/macports/macports-base/blob/5e17a692f991a55a7f450e40ce47ab6fe0f2da57/src/port1.0/portconfigure.tcl#L1367

12. Simplify compilers and mpi PGs with recent base changes.
      Recently, significant changes were made in the base code concerning compiler selection.
      Is there a way to use these changes to simplify the PortGroups that manage compiler selection via variants?
      See https://github.com/macports/macports-base/pull/88
      See https://trac.macports.org/ticket/55139

13. Buildbot & Continuous Integration Improvements
      I am afraid these are well outside of my knowledge area, but here are a few issues that have arisen lately.
      *) https://lists.macports.org/pipermail/macports-dev/2018-November/039651.html
      *) https://lists.macports.org/pipermail/macports-dev/2018-April/thread.html#38023
      *) https://lists.macports.org/pipermail/macports-dev/2019-February/040070.html
      *) https://lists.macports.org/pipermail/macports-dev/2018-July/thread.html#39148