Changes between Initial Version and Version 1 of Ticket #41796, comment 4


Ignore:
Timestamp:
Dec 13, 2013, 6:14:31 PM (11 years ago)
Author:
gallafent
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #41796, comment 4

    initial v1  
    22> … there's no particularly good or particularly well-supported reason why a user should ever change `macosx_deployment_target` within MacPorts.
    33
    4 I think there are good reasons to want to build packages which can be used on older versions of Mac OS, and even though there's a variable defined in the Portfile reference which does achieve this effect when set in the global config file!
     4I think there are good reasons to want to build packages which can be used on older versions of Mac OS, and there's a variable defined in the Portfile reference which does appear to achieve this effect when set in the global config file with some success!
    55
    6 If it is really the case, I'd suggest that macosx_deployment_target should be removed as a MacPorts variable. How can it be useful in any particular portfile if it is not useful when used globally? I am not actually suggesting that this is done, though, since that would make it harder for me to do what I'm doing (!), just wondering what the use-case is that means it is still there in macports!
     6If it is really the case that this should actually not be attempted under any circumstances, I'd suggest that macosx_deployment_target should be removed as a MacPorts variable. How can it be useful in any particular portfile if it is not useful when used globally? I am not actually suggesting that this is done, though, since that would make it harder for me to do what I'm doing (!), just wondering what the use-case is that means it is still there in macports (or is its presence just historical?).
    77
    88Something which catches the attempted use of binary packages when in fact the user's macports.conf means (through macosx_deployment_target or any of the other (many, as you say) configurations which would mean they “don't match”) and prevents their use (or just tells the user that she ''must'' add the {{{buildfromsource always}}} in order to use whichever option it is, would be useful, I think. Should I open an enhancement ticket to suggest this away from these various other reports?