I don't want to discuss this at great length, but I'll answer these questions:
On Sep 16, 2019, at 02:22, René J.V. Bertin wrote: > On Sunday September 15 2019 20:25:59 Ryan Schmidt wrote: > >> Setting such options on the command line is intended as a debugging >> technique only. > > I cannot agree completely with that. What if you want to build all your ports > with maximum optimisation (including -march=native and -mdynamic-no-pic)? There is no feature in MacPorts for that. Individual ports can offer a variant to do that if that would be of particular benefit to that port. For example the gdal port offers a +perf variant. We should standardize on a name for such a variant. I don't know if we've already done so. > What about `configureccache`, that cannot possible be defended as a debugging > technique (and by definition ccache won't help with code that has the be > recompiled each time because you keep changing it). There should be no need for you to specify anything ccache-related on the command line. You can enable ccache globally in macports.conf. Individual ports can disable it if they are not compatible with it. > Comparable systems on Linux all have a way to define a way to define the > default compiler options (and compiler choice), just like MacPorts has a way > to define default variants. Evidently MacPorts has made different design choices. Just because a person building software could supply an option to the build that would affect it in some way does not mean that MacPorts will provide a way for the user to access that option. It is up to the port maintainer to make good choices about what build options are exposed to users via variants and which ones will be hidden in the portfile. > Where is the code anyway that handles the reset when processing of a new port > starts? Maybe the reset itself could be made dependent on a switch, such that > it'd be on by default but can be toggled to "sticky" behaviour instead? I don't know.
