Re: several messages

On 2020-7-5 14:08 , Fred Wright wrote: > > Since having those defined differently would only be expected in cases > where the build target is a range of OS versions, and since MacPorts has > no concept of "OS version universality" and hence always targets one > specific OS version, once would expe

Re: Google Magenta Portfiles Help Request for new py-note-seq port

On 2020-7-5 06:35 , Jason Liu wrote: > If upstream doesn't have a useful version number, you need to make > one up. It should monotonically increase over time. It should change > whenever the upstream source code you are installing from changes. > > > For ports I've submitted which do

Re: Google Magenta Portfiles Help Request for new py-note-seq port

On 2020-7-5 07:16 , Steven Smith wrote: >> REQUIRED_PACKAGES contains: 'numba == 0.48.0' >> >> That's not the version installed by the py-numba port. > > I don’t believe that this is causing the problem because replacing this > line with: > >>     'numba >= 0.48.0',  # temporary fix for librosa i

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

Hi, Your optional patch looks on a quick scan ok to me. To be clear, you are proposing adding this to the llvm ports, to patch the version of the headers installed by that, right ? Chris > On 5 Jul 2020, at 6:33 am, Ken Cunningham > wrote: > > As software using c++17 is upon us, we have a

Re: Google Magenta Portfiles Help Request for new py-note-seq port

On Jul 5, 2020, at 03:01, Joshua Root wrote: > On 2020-7-5 06:35 , Jason Liu wrote: >>If upstream doesn't have a useful version number, you need to make >>one up. It should monotonically increase over time. It should change >>whenever the upstream source code you are installing from ch

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

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.12, and then all those systems could comfortably implement c++17, and > no problem. Otherwise we have to i

Re: Some questions regarding MacPorts legacy support package

On Jul 4, 2020, at 15:44, Jason Liu wrote: > Question 2: > > A related question is that in MacportsLegacySupport.h, you guys use version > numbers such as 101300, 1070, etc. instead of the constants that are defined > in AvailabilityMacros.h, such as MAC_OS_X_VERSION_10_13, > MAC_OS_X_VERSI

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

> On Jul 5, 2020, at 02:24, Chris Jones wrote: > > Hi, > > Your optional patch looks on a quick scan ok to me. I hope so. I think someone like Ionic might easily do better. It should throw std::exception but I had trouble with that. Older versions of this threw std::logic_error and that was

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.12, and then all those systems could comfor

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: Google Magenta Portfiles Help Request for new py-note-seq port

On 2020-7-5 19:54 , Ryan Schmidt wrote: > On Jul 5, 2020, at 03:01, Joshua Root wrote: > >> On 2020-7-5 06:35 , Jason Liu wrote: >>>If upstream doesn't have a useful version number, you need to make >>>one up. It should monotonically increase over time. It should change >>>whenever the

Re: Some questions regarding MacPorts legacy support package

> > This will be — something new. Nobody actually knows how well this will > work. > Then I guess we're all going to find out the answer in the course of adding this new piece, huh? :P > It probably might best be something optionally used rather than a default > in legacysupport, as the opportun

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 in

Re: several messages

On Sun, Jul 5, 2020 at 12:08 AM Fred Wright wrote: > > On Wed, 3 Jun 2020, Jason Liu wrote: > > [...] > > A solution I found which some projects (e.g. Qemu) have implemented > > basically replaces the new AppKit constants with the old AppKit ones > using > > *#define* directives if the OS version

Deepmind Tree Bazel Build Portfile Help Request

I’m preparing a PR for the Google Magenta project >, and am running into this issue for the “dm-tree” dependent package with the bazel build. The command `port -dv test py37-dm-tree` hangs during the bazel build. I can’t even Ctl-