Everyone, please use the new list addresses at lists.macports.org, not the old
macosforge addresses that were deprecated in 2016.
On Jun 23, 2020, at 01:40, Vincent Habchi wrote:
> Wouldn’t it be possible to somehow set up a new hardware machine with
> MacPorts installed and give all
os.arch is arm64
(16:39:32 Tue Jun 23 2020 jeremy@airbear ttys000 arm64)
[617] ~ $ uname -m
arm64
(16:39:33 Tue Jun 23 2020 jeremy@airbear ttys000 arm64)
[618] ~ $ uname -p
arm
> On Jun 23, 2020, at 4:33 PM, Joshua Root wrote:
>
> Do you mean arm64 is what `uname -p` prints, or what
>
Do you mean arm64 is what `uname -p` prints, or what
$tcl_platform(machine) contains, or both?
On 2020-6-24 08:48 , Jeremy Sequoia via macports-dev wrote:
> It is arm64.
>
>> On Jun 22, 2020, at 9:50 PM, Ryan Schmidt wrote:
>>
>> Now that Apple has announced that Macs will have ARM processors
Yes. Installing the Xcode.app beta with support for Apple Silicon Macs and
adding +universal to your default variants will be a good first step. Note
that you will need to explicitly set the universal arches in macports.conf
right now (unless you are running on a DTK) since the value is based
It is arm64.
> On Jun 22, 2020, at 9:50 PM, Ryan Schmidt wrote:
>
> Now that Apple has announced that Macs will have ARM processors [1], what is
> the proper value for ${os.arch} on such systems?
>
> MacPorts base currently knows two values of ${os.arch}: "powerpc" is used on
> all 32-bit
On Tue, Jun 23, 2020 at 1:06 AM Mojca Miklavec wrote:
> I would say that we happily accept a pull request that "just bumps"
> all dependents of perl5[.x].
> Then all the ports will magically work with 5.30.
>
> I seriously mean that.
>
I would tend to say that this is now also more true for
>
> If that is actually what is being done in this thread (I think it is, but
> I can't tell for sure), to perl5.28 and python38, let's make that clear.
But my question was, is that declaration simply a consensus among humans to
simply put port:perl5.28 and port:python38 in the portfiles? Or is
> On Jun 23, 2020, at 00:48, Ryan Schmidt wrote:
>
> You yourself have suggested multiple times that we should move more towards
> always using MacPorts compilers on older systems even for ports that don't
> require it because it's less easier for the maintainer to be able to assume a
>
On Jun 23, 2020, at 00:48, Ryan Schmidt wrote:
>> Feel free to set the bar, if you care to. And hopefully, don’t move it too
>> often…IMHO.
>
> I'm not sure what you mean.
Exactly what I stated with...
If MP would pick one perl and one python that everyone is meant to use, declare
it,
On 2020-6-23 17:14 , Ryan Schmidt wrote:
> On Jun 23, 2020, at 01:44, Joshua Root wrote:
>
>> On 2020-6-23 16:36 , Joshua Root wrote:
>>> The value of os.arch is intended to match `uname -p`.
>>
>> And assuming macOS 11 hasn't changed uname in this respect, it looks
>> like it should be "arm".
On Mon, Jun 22, 2020 at 01:26:54PM -0700, Michael wrote:
>
> On 2020-06-22, at 1:12 PM, Dr M J Carter
> wrote:
>
> > Rats: you beat me to it. I'll restrict myself to reminiscing about
> > dylibs having allegedly been invented (by Sun?) out of embarrassment,
> > on finding hello.c was bloated,
On Jun 23, 2020, at 00:57, Ken Cunningham wrote:
> On Jun 22, 2020, at 8:32 PM, Ryan Schmidt wrote:
>
>> I can't corroborate that claim, but of course we are interested in reducing
>> bloat in MacPorts and welcome any suggestions or improvements toward that
>> end.
>
> I’m surprised — that
On Jun 23, 2020, at 01:44, Joshua Root wrote:
> On 2020-6-23 16:36 , Joshua Root wrote:
>> The value of os.arch is intended to match `uname -p`.
>
> And assuming macOS 11 hasn't changed uname in this respect, it looks
> like it should be "arm". [1]
>
> - Josh
>
> [1]
>
I'd think the promotion of implicit-function-declaration is something you'd
be able to work on and fix in the x86 architecture too, and that seems to
be the major first step here.
On Tue, Jun 23, 2020 at 1:41 AM Vincent Habchi wrote:
>
> > On 22 Jun 2020, at 22:19, Jeremy Huddleston Sequoia <
>
On 2020-6-23 16:36 , Joshua Root wrote:
> The value of os.arch is intended to match `uname -p`.
And assuming macOS 11 hasn't changed uname in this respect, it looks
like it should be "arm". [1]
- Josh
[1]
> On 22 Jun 2020, at 22:19, Jeremy Huddleston Sequoia
> wrote:
>
> I just pushed some changes to base/master and dports/master to better support
> macOS 11 and Apple Silicon, but there's quite a bit of work ahead of us.
[…]
> Please reach out if you have any questions or concerns.
We’re
On 2020-6-23 14:50 , Ryan Schmidt wrote:
> Now that Apple has announced that Macs will have ARM processors [1], what is
> the proper value for ${os.arch} on such systems?
>
> MacPorts base currently knows two values of ${os.arch}: "powerpc" is used on
> all 32-bit and 64-bit PowerPC systems
Ryan,
> Now that Apple has announced that Macs will have ARM processors [1], what is
> the proper value for ${os.arch} on such systems?
It should be noted that, apparently (I didn’t follow the keynote), the Apple
staff never referred to the new arch as “ARM”, but used “Apple silicon”.
So why
18 matches
Mail list logo
