Opened 9 months ago
Last modified 9 months ago
#69379 new enhancement
storing port configuration settings under the workdir
Reported by: | RJVB (René Bertin) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | |
Keywords: | Cc: | ||
Port: |
Description
As a port maintainer/dev I am probably not alone in invoking the different build phases separately and repeatedly. In that context I've been running into a convenience issue that didn't exist before.
It's become more and more rare that recent ports build with the system compiler on my older OS version, so logic has been added to get ports to use a recent enough compiler. In my own ports that need this I add some of my own logic that will cause the most recent installed and sufficient compiler to be selected (IMHO the most justifiable approach) but even that is not always what I want because clang has long history of getting slower and more resource-hungry with every release. I can't remember any names but the past few weeks I've encountered at least 1 port that seems to have portfile code that is conditional on the selected compiler version.
Long story short: in the vast majority of cases the port configure
phase will set up everything so that subsequent build or destroot attempts don't need to specify anything except the port name and requested variants. I think it would be nice to store the most common additional relevant commandline arguments too during the configure step, and restore them before parsing the Portfile. In my case that would be configure.compiler
and configureccache
.
This would make it a bit easier (= less typing) to continue working on getting a port to build from a different (e.g. remote) terminal.
It should also allow to configure several ports and then run a combined port -np build A [+Avariants] B [+bVariants]
each with the intended definition for at least configure.compiler
rather than having to specify it for each port. (In my experience you cannot just set configure.compiler
at the end of the commandline and hope it will apply to all ports to be processed.)
As I said above, it's a minor issue of pure convenience but it shouldn't be too hard to implement and could use the existing statefile mechanisms.
Replying to RJVB:
In fact, any port that selects a compiler version even if only through the blacklisting feature would benefit from the suggested mechanism, esp. with build systems that can invoke a re-configuration when (re)starting a build if they detect a change to one of the build definition files.