where to find darwintest.h and the rest of the Apple darwin testing infrastructure?

I’m trying to upgrade the testing for legacy-support, and I thought I might try to bring in some of Apple’s existing testing files, eg > for the new futimens

Re: Factors determining binary archivability --> OpenSSL 3.0 is coming along with a new license

OpenSSL 3.0 has a new, more compatible license. It is coming along. Alpha5 released July 16. https://www.mail-archive.com/openssl-users@openssl.org/msg88452.html

if we are going to support universal arm/x86_64 ports, we'll likely need a multi-architecture gcc again

I’m not sure if the MacPorts plan is to support universal arm/x86_64 builds, but I can imagine that for some years we might want to consider doing that. The last gcc version we had that supported multiarchitecture building was apple-gcc42 (Intel, PPC). We might have built a suitable newer

Re: port "cask" -- installing prebuilt binaries

So this issue seems still active, but without a decided plan here, people are just starting to PR their favourite approach, which is of course exactly what we are tring to avoid. The idea of identifying them by a variant suffers from the fact that these are obviously not variants, they are

Re: port "cask" -- installing prebuilt binaries

> On Oct 2, 2020, at 8:02 AM, Ken Cunningham > wrote: > > Chris says put them in a category. Logical, but I don't know if most users > would note that when trying to install them, as it is not perhaps obvious > enough these are different beasts. Also, it it is d

Re: How to abort a macports portfile on an error condition?

hey, thanks Ryan for taking care of this little detail. K On 2020-10-03, at 11:48 AM, Ken Cunningham wrote: > Martin, I'm trying to understand how this is happening to you. > > you should not need to be doing that in your Portfile, and users should never > need to make

Re: Hardcoding Xcode.app

and if we're coding this in somewhere to get all systems, it's this: xcode-select -print-path I already fixed that particular thing in base once, so somewhere in base this is already being called... Ken On 2020-10-09, at 1:14 PM, Andrew Janke wrote: > Just one data point here, but as a

Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

We’d need: 1. the ability to install and keep a toolchain on the buildbot in some fashion I’m very in favour of this, if possible, but I can see that it is not trivial to implement — I think all the OS versions < about 10.12 should use clang-9.0 to build everything, and save us all a lot of

Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

> On Oct 15, 2020, at 9:32 PM, Ken Cunningham > wrote: > > 2. an “openmp” PortGroup that all ports that want openmp could subscribe to, > that forces an openmp setup that works for various systems. > > Not overly hard, I think. or maybe the compiler.openmp settin

Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

> It's correct that I would rather people didn't blacklist compilers that are > capable of building a port. It wastes user and buildbot time and wears out > the buildbot SSDs unnecessarily. Half (more?) of the tickets on MP are from trying to build port X with ancient xcode clang Y. When those

Re: New py-cryptography and old macOS versions

> How to properly handle a case when a new version explicitly drops support for > older macOS? I suggest don't change anything, and see how MacPorts' enhanced build systems, legacysupport, etc, handle it first... K

Re: OpenMP on MacOS Clang

Is this report saying that Xcode clangs will use openmp now with the -Xclang -fopenmp flags added? That would be very interesting news, if so, I think. If that is true, do we know what version of Xcode clang can use openmp? The open-source (macports) clangs have accepted -fopenmp for some years

Re: port release candidate versioning question

thanks to all for the helpful responses. I will try to get it right off the mark. K > On Aug 17, 2020, at 12:40, Ryan Schmidt wrote: > > > >> On Aug 17, 2020, at 13:39, Arno Hautala wrote: >> >>> On 17 Aug 2020, at 14:35, Arno Hautala wrote: >>> >>> To verify this, and to test other

port release candidate versioning question

This sounds like a dumb question, that I should already know the answer to, but apparently I don’t seem to: I would like to make sure this works the way I think it works before I do it. When I make a new port clang-11 with version 11-rc1 and then follow-up with versions 11-rc2, 11-rc3, etc

Re: Need help with troubleshooting Blender PR

Most ports that try to figure out the SDKROOT on their own don't do it right, so you should always force the port to use MacPorts ${configure.sdkroot} if there is a configure option to do so. There is an idiosyncrasy in MacPorts base wherein if the SDKROOT is "/" then MacPorts base leaves

Re: Need help with troubleshooting Blender PR

On 2020-08-29, at 1:42 AM, Ryan Schmidt wrote: > > Is there a ticket about this? This is the ticket > > The place to fix it would be in src/port1.0/portconfigure.tcl in proc > portconfigure::configure_get_sdkroot, changing some or possibly all

FYI -- Parallels 16 now supports BigSur as a VM on older systems

Like Catalina, Parallels will install BigSur as a VM even on older systems. https://kb.parallels.com/en/125105 for those of you who might have parallels but no current system to run BigSur Ken

Re: FYI -- Parallels 16 now supports BigSur as a VM on older systems

ah, apologies — after a while, the installation in the end failed, I’m afraid. I was a bit too trusting of the literature and initial installation steps. Ken > On Aug 20, 2020, at 9:33 PM, Ken Cunningham > wrote: > > Like Catalina, Parallels will install BigSur as a VM e

Re: supertuxkart non-redistributable?

> On Aug 25, 2020, at 4:09 AM, Joshua Root wrote: > > On 2020-8-25 19:42 , Eric F (iEFdev) wrote: >> Fedora, who usually are very restricted about things, have this take: >> >>> “ However, we consider that the OpenSSL library is a system library, >> as defined by the GPL, *on Fedora* and

Re: supertuxkart non-redistributable?

Wikipedia got the libressl license totally wrong then, which I have not found is not usually the case: Apache License 1.0, 4-clause BSD License, ISC License, and some are public domain anyway, we're stuck for so many ports due

supertuxkart non-redistributable?

Just curious what makes this port non-redistributable…. it’s likely a pain for users to have to build it. Ken

Re: supertuxkart non-redistributable?

> On 8/24/20 7:30 PM, Ken Cunningham wrote: > > Just curious what makes this port non-redistributable…. > > > > it’s likely a pain for users to have to build it. > > > > Ken > > > A quick check shows: > > > "supertuxkart" is not dist

Re: supertuxkart non-redistributable?

> On Aug 24, 2020, at 7:13 PM, Joshua Root wrote: > > > Doesn't supertuxkart itself depend on curl? > > - Josh Oh, yes, of course you are right. It does. Is that what makes it non-distributable? Even though it doesn’t link against openssl? Ken

Re: port "cask" -- installing prebuilt binaries

consider: $ port variants macvim Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'. MacVim has the variants:    big: Build big feature set * conflicts with huge    cscope: Enable source code browsing with cscope [+]huge: Build huge

Re: port "cask" -- installing prebuilt binaries

I mean, you can maybe describe the “feature set” of the prebuilt binary in the variant description and forbid all the other variants… Can’t you? No doubt, with sufficient effort, we could take something inherently simple and make a complicated and undecipherable version of it. PS: Maybe

Re: port "cask" -- installing prebuilt binaries

On 2020-08-14 11:48 p.m., Lothar Haeger wrote: Am 15.08.2020 um 01:11 schrieb Ken Cunningham : so -- what would a user typing Obviously that variant would conflict with all other variants, much like +ruby21 conflicts with +ruby22. So the user would type sudo port -v install macvim

Re: port "cask" -- installing prebuilt binaries

Doesn't the port `ghc` do exactly this? https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile#L31-L33 The variant name is: +prebuilt throwaway bootstrap compiler only, totally different issue

Re: Apple ARM binary codesign issue

Would it not be easier to add that codesign line in the existing script that the cctools port writes to wrap those tools for the +xcode variant of cctools, perhaps? (well, NB cctools is not presently wrapping install_name_tool for the +xcode variant, but that looks like an oversight trivially

Re: Apple ARM binary codesign issue

> On Sep 25, 2020, at 7:55 AM, Michael Dickens wrote: > > Also: many build scripts call /usr/bin/strip directly or xcrun strip ... so > that would bypass our MP efforts ... we'd have to patch up all of those ports > to coerce them into running the MP strip ... that seems like a lot of work!

Re: Apple ARM binary codesign issue

On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote: > > To me it seems unrealistic for Apple to suggest that an infinite number of > open source projects, many of whose developers have never seen a Mac, should > now add code to their build systems to codesign things on macOS. Apple made a >

Re: Apple ARM binary codesign issue

On 2020-09-22, at 11:58 AM, Ryan Schmidt wrote: > > I hope that Apple fixes their toolchain to work without such intervention. > I believe this may ultimately come under the category of "intended behaviour". I can understand why they would want these changes to invalidate the signature. I

Re: port "cask" -- installing prebuilt binaries

Ok. So contenders for the metadata identifying non-buildable binary-only ports we have: name suffix (like the hs- ports had) category only variant as identifier We have spent far too long on this nonsense. Some admin pick one, then lets move on. K

Re: How to abort a macports portfile on an error condition?

Martin, I'm trying to understand how this is happening to you. you should not need to be doing that in your Portfile, and users should never need to make that symlink. The linuxdoc-tools port has this: depends_build bin:latex:texlive \ path:bin/perl:perl5 But it seems that

Re: upgrading self-built MacPorts and version management

I started a page about installing MacPorts on Ubuntu, if you have any contributions to suggest. I actually do use this for simple things at present. https://trac.macports.org/wiki/InstallingMacPortsOnUbuntuLinux K

Re: does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

The file is here, it seems: https://gitlab.gnome.org/GNOME/libhttpseverywhere/-/blob/master/data/default.rulesets

Re: does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

as far as I can see, the one from the website and the one in the ports tree are identical: $ ls -la /Users/Shared/Downloads/default.rulesets.1 ./www/libhttpseverywhere/files/default.rulesets -rw-r--r-- 1 root admin 6992700 20 Jul 12:11 ./www/libhttpseverywhere/files/default.rulesets

Re: does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

e13c70b8a1abfece834d12fc9d0fb/data/default.rulesets >> <https://gitlab.gnome.org/GNOME/libhttpseverywhere/-/blob/9c43785fe5ce13c70b8a1abfece834d12fc9d0fb/data/default.rulesets> >> >>> On 23 Oct 2020, at 7:22 pm, Ken Cunningham >>> wrote: >>> >>> The file is here, it seems: >>> >>> https://gitlab.gnome.org/GNOME/libhttpseverywhere/-/blob/master/data/default.rulesets >>> >>> >>> >

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 3:36 PM, Ryan Schmidt wrote: > > > > On Oct 24, 2020, at 11:46, Ken Cunningham wrote: > >> So instead of this method, I will look into running lsearch on *.env, and >> see if I can sort out how to add some entries if something is alre

how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

It's easy to prepend or append to PATH in a Portfile, but I'm having difficulty seeing how to modify, rather than overwrite, DYLD_LIBRARY_PATH. Usually you just want to set it, but now that it might or might not be set in legacysupport 1.1, I was hoping to just modify rather than overwrite it.

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 8:52 AM, Joshua Root wrote: > > On 2020-10-25 02:18 , Ken Cunningham wrote: >> It's easy to prepend or append to PATH in a Portfile, but I'm having >> difficulty seeing how to modify, rather than overwrite, DYLD_LIBRARY_PATH. >> >

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 9:46 AM, Ken Cunningham > wrote: > > configure.env-append"DYLD_LIBRARY_PATH=${prefix}/lib/lilbgcc" > configure.env-append“DYLD_LIBRARY_PATH=${workpath}/build” > > but I found the second one just obliterates the first on

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 9:50 AM, Ken Cunningham > wrote: > > > >> On Oct 24, 2020, at 9:46 AM, Ken Cunningham > <mailto:ken.cunningham.web...@gmail.com>> wrote: >> >> configure.env-append"DYLD_LIBRARY_PATH=${prefix}/lib/lilbgcc&

does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

The ports tree is getting bloaty as it is, but is is fairly egregious bloat… ls -la total 13680 drwxr-xr-x 5 root wheel 160 22 Oct 18:46 . drwxr-xr-x 4 root wheel 128 23 Aug 15:39 .. -rw-r--r-- 1 root wheel 6992700 23 Aug 15:39 default.rulesets -rw-r--r-- 1 root wheel 664

Re: port "cask" -- installing prebuilt binaries

> >> From the user's perspective, how does that differ from a port that's > > available as a binary archive? I presume the idea is that it directly uses > > a precompiled binary from the upstream source, but from the user's > > perspective, does it really matter whether it was a binary from

port "cask" -- installing prebuilt binaries

there seems to be demand for replicating the “binary only” installers of homebrew cask. we have a few ports that do that now, and I see more and more coming in. I have used homebrew cask from time to time to see what it’s up to. It is convenient at times. I also downloaded a lot of things that

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 12:28 PM, Herby G wrote: > > > so far, name-suffix is winning on all fronts...with no downsides yet. > > I don't plan on pushing the issue, but I have to say that I don't agree. > I originally suggested both, and got no purchase on either, so had to push one of them

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 4:13 PM, Ken Cunningham > wrote: > > We need a new name. No trickery with categories is acceptable here. Picture the ticket: hello, user. Uhm before I can help you, does port list echo categories:binary and installed | grep macvim say “binary” ? No —wa

Re: port "cask" -- installing prebuilt binaries

st of binary ports in a > clean way when browsing ports in the MacPorts website, it makes it easier to > do things like add an icon to signify binary only if a given port is in the > "binary" category, and not make possibly mistaken assumptions off of the name. > > On Thu, Aug

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 1:42 PM, Jason Liu wrote: > > All that said, one more question. As I now understand it, the idea is to > download a binary-only installer (from the publisher’s web site) and launch > it. Someone still has to answer any and all dialogs that such installers > always

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 2:34 PM, Herby G wrote: > > > If we decide to go ahead with this, and if we decide to primarily use a > > category to mark these, we will need a plan for how to manage a name > > collision conflict when there are two ports that install the same software, > > one by

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 8:23 AM, Arno Hautala wrote: > >> On 6 Aug 2020, at 10:10, Ken Cunningham >> wrote: >> >> How about I float a suggestion? We could append "_binary" to the name. >> Otherwise leave the categories, notes, etc as they are n

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 10:50 AM, Herby G wrote: > a "binary"/"binary_only" (or a new MacPorts specific name for these) as a > *category*, just as we have the "aqua" category > in this way, binary-only apps can continue to be represented in respected > categories with "binary" as their

Re: port "cask" -- installing prebuilt binaries

category-only identifier is less clear and less obvious harder to remember how to search for name conflicts with a non-binary version (eg for newer systems that can build it) so far, name-suffix is winning on all fronts...with no downsides yet. K

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 12:16 PM, Craig Treleaven wrote: > > > Personally, I don’t see any compelling reason why the MacPorts project should > want to go in this direction. The first paragraph on our homepage says: Actually, I’m perfectly happy with a blanket “NO” on all this, if that is the

Re: port "cask" -- installing prebuilt binaries

yes, it's variant names that can't have + and - in them. Momentarily crossed that wire. K > On Aug 7, 2020, at 00:01, Ryan Schmidt wrote: > > > >> On Aug 6, 2020, at 09:10, Ken Cunningham wrote: >> >> So a port that installs the Zoom teleconferencing a

Re: port "cask" -- installing prebuilt binaries

A few more issues: Handling supported_archs in binary-only ports. What if binary comes only as a universal binary, but the user asks for only one arch? We want that one binary to satisfy all the situations it can. Handling universal requests. What if user asks for universal? If binary comes

Re: port "cask" -- installing prebuilt binaries

On 2020-08-07, at 12:10 AM, Ryan Schmidt wrote: > > > On Aug 6, 2020, at 21:20, Ruben Di Battista wrote: > >> If they've been built somewhere by the upstream developer, shouldn't we be >> able to build them too and hence instead of providing them as binaries we >> would fix the ports in

Re: update to icu has again broken all the macports-clang compilers

the macports-clang compilers actually have no need for macports' libxml2 I believe, the libxml2 provided by the system is sufficient, and libxml2 itself is optionally used by one tiny component that is not relevant to a bootstrap compiler... I have disabled libxml2 in various llvm-related

update to icu has again broken all the macports-clang compilers

not exactly sure how I'm going to get around this just yet have to find some compiler that still works somewhere -- gcc? to rebuild libxmls2 and then again rebuild libxml2 +universal once some clang works again... configure:3623: $? = 1 configure:3643: checking whether the C compiler works

Re: update to icu has again broken all the macports-clang compilers

On 2020-08-12, at 7:37 AM, Ken Cunningham wrote: > not exactly sure how I'm going to get around this just yet > > have to find some compiler that still works somewhere -- gcc? to rebuild > libxmls2 and then again rebuild libxml2 +universal once some clang works > again... >

Re: update to icu has again broken all the macports-clang compilers

On 2020-08-12, at 7:55 AM, Joshua Root wrote: > On 2020-8-13 00:37 , Ken Cunningham wrote: >> not exactly sure how I'm going to get around this just yet >> >> have to find some compiler that still works somewhere -- gcc? to rebuild >> libxmls2 and then again rebu

Re: port "cask" -- installing prebuilt binaries

nope, variant is just wrong in all ways. K

port example that extracts pkg

I'm working on something that comes as a 50MB pkg installer that installs into /usr/local. I'd like to extract all the files from the pkg and destroot them properly instead. Anyone know of a good example of an existing port that does something like this nicely? Thanks, Ken

Re: port "cask" -- installing prebuilt binaries

All valid points. I thought we had more-or-less got past the “should we” and moved on to the “how should we”, I am not necessarily championing this, but people are submitting these, and there is demand.here are nearly 4000 cask installer formulae on brew now. If similar binary-only ports are

Re: port example that extracts pkg

there are actually not too many examples in the ports tree of this: fuse/osxfuse/Portfile security/1password-cli/Portfile and perhaps science/SDRplay/Portfile science/SDRplay3/Portfile osxfuse seems to be doing it well, and I'll use that one for an example, for any others that come along with

Re: port "cask" -- installing prebuilt binaries

I wasn't imagining a variant for binary-only installs. If a port can be built, we should build it. But for things we can't build, (like Zoom or Microsoft Word) installing a binary is the only option and some ports of this type seem to be what people are submitting recently. This is fine --

Re: port "cask" -- installing prebuilt binaries

> Sure, let's repeat this a few more times until everyone *really* got that. :-) That's exactly why the indicator should not be a variant. Variant indicates an option to install one way or the other, and a given port on a given system will not have such an option. K

Re: port "cask" -- installing prebuilt binaries

How about I float a suggestion? We could append "_binary" to the name. Otherwise leave the categories, notes, etc as they are now. So a port that installs the Zoom teleconferencing application would be called "zoom_binary". (We can't use "zoom-binary" because variants us the + and - to do

Re: Some questions regarding MacPorts legacy support package

> On Jul 5, 2020, at 3:03 PM, Jason Liu wrote: > > > Other than using the __MACPORTS_LEGACY_SUPPORT_APPKIT__ macro, is there some > way of making it optional? It will have to be specifically disabled by default, and then turned out optionally with some new legacysupport toggle that I/we

Re: our "sudo port install gnome" metaport is not working -- GNOME needs help

Yeah -- maybe pointless. Dave is going over other things instead, and I'm sure he'll get to whatever it is in due course of time. "sudo port install gnome" is broken, but no doubt that'll be fixed in time. K

Re: Some questions regarding MacPorts legacy support package

> Some questions regarding MacPorts legacy support package > > Jason Liu jasonliu at umich.edu  >

Re: several messages

oh, btw Fred, your impression of MAC_OS_X_VERSION_MAX_ALLOWED is not quite right. It doesn't indicate removed features. It indicates the SDK version you are currently building with, so you know what API you can use. This is always confusing, which is why we use what we do in legacysupport, in

clang, c++17, std::optional, and libc++.dylib

As software using c++17 is upon us, we have a slight problem with std::optional. clang has supported std::optional for some time, and clang-9.0, at least, appears to support std::optional right back to the ancient systems. however, there is one small part of std::optional, std::optional::value,

Re: several messages

> several messages > > Fred Wright fw at fwright.net  > > Sun Jul 5 04:08:09 UTC 2020 > > Previous message (by thread): Some questions regarding MacPorts legacy

Re: clang, c++17, std::optional, and libc++.dylib

> > Chris > >> On 5 Jul 2020, at 6:33 am, Ken Cunningham >> wrote: >> >> As software using c++17 is upon us, we have a slight problem with >> std::optional. >> >> clang has supported std::optional for some time, and clang-9.0, at

Re: our "sudo port install gnome" metaport is not working -- GNOME needs help

On 2020-07-01, at 11:21 PM, Ryan Schmidt wrote: > Is this build failure with some modifications you've made to these ports? I'll start with the most important bit -- I think the gnome metaport is a flagship port for Macports, and it won't install. I recommended it today to some new

our "sudo port install gnome" metaport is not working -- GNOME needs help

this I think “sudo port install gnome" is a popular metaport, but it’s presently broken initially polari won’t build, but that’s because gjs won’t build, but that’s because we don’t have mozjs68 … and then who knows... I wonder if interested people might dive in and give Dave a hand — GNOME is

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

> 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 has always been near point #1 on every homebrew vs.

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

> 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 >

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

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,

Re: macos as vm guest

> after my development mac mini died (and the time backup appeared to be > corrupt) i had to buy another mac. > now i have a 2013 imac that can run catalina, but sometimes i also need 10.11 > for older hardware and software, and 10.13 for compatibilty with our other > macs. > > i would like

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

On 2020-06-27, at 6:27 AM, Daniel J. Luke wrote: > On Jun 22, 2020, at 11:20 PM, Ryan Schmidt wrote: >> On Jun 22, 2020, at 14:34, Daniel J. Luke wrote: >>> We should just have one perl5 port that tracks the current release. >> >> You say this every year (or at least often). > > I say this

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

> On Jun 23, 2020, at 12:48 AM, Ryan Schmidt wrote: > > My ports are slightly out of date but I don't see a choking amount of > dependencies for curl on High Sierra: > > $ port rdeps curl > The following ports are dependencies of curl @7.70.0_0+ssl: > xz >lbzip2 >libiconv >

randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

A simple used-to-be-quick build of "curl" now requires two different perls installed. Perhaps unavoidable in some cases, but if you look around the web, this is in fact the #1 complaint about MacPorts: bloat. It might be an idea for the admins to "set" the perl version all ports will use

polly as default on llvm...

does any one have any insight into why polly has always been a non-default variant of our llvm? It is a routine add on for all the llvm builds elsewhere, builds broadly, and I was going to just wrap it in and delete the variant, or at least make it a default variant, unless there's a reason

Re: Call for designers for our ports website

Just FYI Homebrew has always been opt-out for stats. Nobody seems to have a problem with that sufficient to make them change that policy. We'll never know if that is why they seem to have 10 x the users on their stats page. K

Re: Call for designers for our ports website

> On Jun 12, 2020, at 6:03 PM, Saagar Jha wrote: > > I believe the lack of change there is almost certainly a matter of the > project’s personal stance rather than “nobody having a problem with it”. "sufficient to make them change that policy" > Personally, I would be fairly disappointed if

Re: Call for designers for our ports website

sorry —we’re 835 openssl installs. wrong drop-down. K > On Jun 13, 2020, at 8:56 AM, Ken Cunningham > wrote: > > No doubt it caused some tempest. > > I was wrong, homebrew’s published stats say they have 5 million openssl > installs this year <https://formulae.brew.s

Re: Call for designers for our ports website

t;> >> Personally, I would be fairly disappointed if MacPorts went opt-in as such >> policies suffer from statistical issues in addition to the obvious >> privacy-related ones. >> >> Saagar Jha >> >>> On Jun 12, 2020, at 16:48, Ken

Re: Need some advice regarding patches for old AppKit compatibility

> does that sentence mean that the MacPorts legacy support package itself needs > GNU make, or does it mean that any portfile that uses the legacysupport > PortGroup needs to add GNU make as a build dependency? That line, and a lot of the other stuff added recently to the front page, is quite

Re: Help with UsingTheRightCompiler

> build.args CC="${configure.cpp} [get_canonical_archflags cc]" Try this perhaps: build.args CC="${configure.cxx} [get_canonical_archflags cxx]" There are other methods some might prefer besides this. BTW, the software has this issue because the author threw a c++ include file into

PRs now going back 18 months -- let's close the clearly dead ones

There are ancient PRs that are never going to be committed in the queue. This is just noise, and prevents us from keeping things moving. The people who opened them seem attached to them, but they are clearly dead and need to be closed. If in agreement, can one of the admins close the 50 oldest

Re: PRs now going back 18 months -- let's close the clearly dead ones

e to close them when they are accidentally fixed by some commit. K > On Jul 25, 2020, at 23:20, Ryan Schmidt wrote: > > > >> On Jul 25, 2020, at 15:38, Ken Cunningham wrote: >> >> There are ancient PRs that are never going to be committed in the queue. >>

how to install and use a newer libc++ on older systems 10.7 to 10.12

You may have noticed that current software sometimes requires newer libc++ features than the installed system libc++.dylib version can support. The libcxx port has the capability to install a newer libc++.dylib, currently the libc++ that matches llvm-5.0, which is quite recent in terms of OS

Re: Help with UsingTheRightCompiler

> Hi developers! > > > I’m trying to get the new Portfile ncplot to UseTheRightCompiler. It uses a > primitive Makefile but not a configure file. So I added the makefile 1.0 > portgroup. However, I get a build error when I do. Can anyone help? > > Error is: > > :info:build In file included

Re: Help with UsingTheRightCompiler

> You have to use clang++ if you are calling in c++ includes. > > Then it will work. Having read over the other comments, and in case that wan’t clear — if you use /usr/bin/clang++ your build will automatically find the c++ includes, and you don’t need to do any of those suggestions with

Re: clang, c++17, std::optional, and libc++.dylib

> > Then all systems from 10.5 to current can use c++17 std::optional, and > disaster averted until the next crisis. > The next crisis will likely be std::filesystem, and there is no inlining that, btw. K

Re: clang, c++17, std::optional, and libc++.dylib

> On Jul 5, 2020, at 03:13, Ryan Schmidt wrote: > >> On Jul 5, 2020, at 00:33, Ken Cunningham wrote: >> >> It is quite simple (I think) to inline a function implementing >> bad_optional_access into the header. That could be used for 10.7 >> to 10.

Re: Qt and Apple Silicon

> My MythTV ports depend heavily on Qt but I’m not up to speed on that > project’s plans wrt the new Apple-silicon (ASi) Macs. AIUI, our current Qt5 > port is X86_64 only. Is or will Qt5 be compatible with ASi? Do we need to > port Qt6 to become compatible? Any rough timetable? > > If I’ve

cctools xcode variant conflicts with universal -- why?

We will want to be able to use the cctools +xcode variant of cctools when building universal with x86_64 & arm64 it would seem. The xcode variant is just a wrapper script that calls the cctools tool in Xcode; it was marked as conflicting with the universal variant in 2018. I’m trying to

<    1   2   3   4   5   6   7   8   >