Hi Wilhelm - Thanks for the reply.
doxygen has no dependency on qt5. "doxygen +wizard" depends on qt4-mac,
and that's the only Qt dependency for doxygen, according to 'port', of
course. It is certainly possible that doxygen has been updated to find
and require Qt5 & that "stealth" change has not b
What you propose is what I'm doing in various GNU Radio ports, e.g.,
gr-ieee802-11. If ${configure.cxx_stdlib} is "libstdc++, then default to
some MacPorts provided GCC (right now, 4.9 ... I need to update these to
gcc6); else use the cxx11 PortGroup. It's not the best solution, but it
works well e
When using Mac OS X 10.7 and I try to get info on any port that uses the
Qt5 PortGroup, I get the error that "Port qt56-qtbase not found". A
little searching finds that in the qt5-1.0 PortGroup, the proc
"qt5.get_default_name" returns "qt56" for this OS version, which is then
used as the base for
I'm up for being a mentor again, for the correct student.
Do we have a MP GSoC website up yet? The best I can find is <
https://trac.macports.org/wiki/SummerOfCode >, which is for 2015.
Cheers! - MLD
On Mon, Feb 6, 2017, at 10:52 PM, Jackson Isaac wrote:
> Hello everyone,
>
> As you all might b
The new CppUnit has an interesting issue: #include'ing the header,
whether directly or indirectly, results in requiring linking to the
library, because there is a new static variable in the primary namespace
in the header.
I think this is poor programming because, as an example, I might
#include a
What both of you write is probably technically correct. These are
patches from elsewhere and, in my reading, make sense based on context.
Rev-bump? Maybe; not clear if that's really necessary. We can always do
that, but since it's Qt4 I'm inclined to not do so unless someone
complains. These fixes
Hi MP devs - A hopefully brief discussion of / query about c++ library
usage, with a little background. What I describe below works for me,
which makes me wonder if what I'm doing is nonstandard use of 'port' or
what's going on ...
GNU Radio devs were asked whether GR compiles using GCC7 cleanly,
e:
> On 21 June 2017 at 03:48, Michael Dickens wrote:
> > Hi MP devs - A hopefully brief discussion of / query about c++ library
> > usage, with a little background. What I describe below works for me,
> > which makes me wonder if what I'm doing is nonstandard use of '
I recently noticed that gcc7 had an update, and so I've started updating
it. I'll move it to the 7.1 release shortly. There's also a new gcc8
snapshot that I'll look into getting up for folks on the bleeding edge
to try out (as I'm often asked to do for UHD / Volk / GNU Radio).
The question comes
t;> Error: Can't install libgcc-devel because conflicting ports are
>>>> active: libgcc>>>> Error: Follow
>>>> https://guide.macports.org/#project.tickets to report
>>>> a bug.>>>> Error: Processing of port gcc7 failed
>&g
I'm new to the *GCC* ports, so I don't know why libgcc# is not matched
with gcc#. Seems like it would be possible to install libgcc# into
$prefix/lib/libgcc#/ , so that one could have all of the various gcc#'s
installed at the same time without conflicting. But, then I've never
tried & this certain
Hi Nicolas - qmake by itself will not "do the right thing", as you note,
for pretty much any 'port' setting (CC, CXX, *FLAGS).
If you use the qmake 1.0 PortGroup, then qmake should "do the right
thing". If you're using this PG & qmake is still not doing the right
thing, then the issue is likely the
I have an issue with SIP that needs to be addressed, that I'm not sure
how do execute in port via Portfiles. I have a solution, but it's kinda
a hack.
Background
---
Some SIP dependencies use sipconfig to glean the directory into which to
install generated SIP files [in Python: "import sipconfig";
On Thu, Jul 20, 2017, at 10:46 AM, Rainer Müller wrote:
> On 2017-07-19 23:09, Michael Dickens wrote:
> > I have an issue with SIP that needs to be addressed, that I'm not sure
> > how do execute in port via Portfiles. I have a solution, but it's kinda
> > a hack.
&
Hi Ken - I, for one, would strongly encourage you to use the GIT process
you mention. You still have to be careful to distinguish between
patchfiles and reinplace patches, but hopefully that's not too
difficult. Another benefit to using GIT is that if you messed up a fix,
you can always revert it &
What Mojca wrote is what I do too. Simple but very effective! - MLD
On Wed, Aug 30, 2017, at 12:37 PM, Ken Cunningham wrote:
> >
> >cd $(port work foo)
> >cd foo-version
> >sudo git init .
> >sudo git add -A
> >
> >git diff > /tmp/my-patches.diff
> >
> > And more or less ma
Another benefit to the "chmod" at the top-level "work" directory is that
you can then edit the ".macports.*.state" file -- e.g., to revert the
state back to "patched" so-as to force configuration again. Or you can
remove the build or destroot directory with
Reverted in <
https://github.com/macports/macports-ports/commit/44373e0fd9955702e9e2f6820b2cf595fec24c65
>. Thanks for testing & feedback. If/when the release is moved to
requiring C++11, I'll also create a subport for the last version that
doesn't, for bootstrap purposes per our discussion (assumi
Guessing that you've run into a local permissions issue. This happens
with any repo manager: if it can't access a required file, it can't do
squat! I regularly do "chmod -R u+rw ." from the top level of my local
repos to make sure at least -I- can access all of the files. That said,
glad you found
On Tue, Jan 30, 2018, at 11:08 AM, Ryan Schmidt wrote:
>
> On Jan 30, 2018, at 08:25, Michael Dickens wrote:
>
> > Michael Dickens (michaelld) pushed a commit to branch master
> > in repository macports-ports.
> >
> >
> > https://gi
Ah; got it. Yeah OK I see the issue. I'll fix that thx! - MLD
On Tue, Jan 30, 2018, at 11:46 AM, Ryan Schmidt wrote:
> What I mean is that your livecheck.regex specifically mentions version
> 2.11. If the project ever releases version 2.12, for example, the
> livecheck will no longer match.
Hi David (& MacPorts developers) - Yesterday, py*-numpy was added as a
dependency of Boost (in order to make sure boost.numpy is built knowingly),
which created a cyclic dependency: boost -> py27-numpy -> gcc7 -> cctools ->
llvm-5.0 -> cmake -> curl -> libpsl -> gtk-doc -> source-highlight -> bo
In the past, I've handled this situation by using the muniversal PortGroup, so
that the sizeof is correct for each build independent of the other. - MLD
On Thu, Mar 1, 2018, at 2:40 PM, Mojca Miklavec wrote:
> While checking some patches of a library I decided to try whether the
> library would b
.
I'm guessing that zziplib uses the uint*_t & int*_t internally, which if so
then it's safe to use +universal for this port without using muniversal or any
special trickery.
Hope this helps! - MLD
On Thu, Mar 1, 2018, at 4:27 PM, Mojca Miklavec wrote:
> On 1 March 2018 at 20:42,
Hi Ken - I think that's a great idea. In "GNU Radio" land, we have such a tool
for creating out-of-tree GR modules, called "gr_modtool"; it's great for
setting up the skeleton for such OOT GR scripts. The end-user still has to fill
in many "blanks", but this tool provides the starting point. I c
Good catch. Reverted. - MLD
On Sun, Mar 11, 2018, at 12:56 AM, Ryan Schmidt wrote:
>
> On Feb 28, 2018, at 14:15, Michael Dickens wrote:
>
> > Michael Dickens (michaelld) pushed a commit to branch master
> > in repository macports-ports.
> >
> >
> > htt
s all I need to do. Does that sound correct? -
MLD
On Wed, Mar 21, 2018, at 6:33 PM, Ryan Schmidt wrote:
> On Mar 21, 2018, at 16:46, Michael Dickens wrote:
> > +PortGroup cmake 1.0
>
> > +# do VPATH (out of source tree) build
> > +
> > +cmake.out_of_source yes
I like the idea, generally. The vast majority of my updates could be automated
in this manner. There will always be a few that need patching or tweaks to
existing patches, which will have to be done by hand. The only other "gotcha" I
wonder about is including buildbots for various target OSs [do
Good catch. I had forgot to do the --no-mirror & everything seemed OK. Fixed in
https://github.com/macports/macports-ports/commit/c4e604e95d59245727f39dc4495f653988e9d3f4
. - MLD
On Sun, Apr 1, 2018, at 4:00 PM, Ryan Schmidt wrote:
>
> On Apr 1, 2018, at 13:47, Michael Dic
My primary reason for not moving to cmake 1.1 in the various GR & other ports I
use is that it sets the default build type to "MacPorts", which has no real
meaning & actually conflicts with some of my ports' cmake scripts & so I have
to work around that (which isn't difficult; just takes time an
think that the Jack API and ABI are actually
upgrade-compatible beyond the internal versioning issue listed here. - MLD
On Fri, Apr 6, 2018, at 8:13 AM, Ryan Schmidt wrote:
>
> On Apr 6, 2018, at 06:49, Michael Dickens wrote:
>
> > Michael Dickens (michaelld) pushed a commit t
The issue being that if a port's configure checks for the build type (e.g., {{{
if(${CMAKE_BUILD_TYPE} STREQUAL "Release") then
...
elseif
}}}
and so forth, and if "MacPorts" is not in BUILD_TYPEs list -- no matter whether
it has settings available for use by CMake already --, then cmake errors ou
Agreed! I thought the design was very clever; used some CMake features I never
knew about. I works for the vast majority of ports ... but not 100% & hence the
need to options such as the cmake 1.0 PG. - MLD
On Fri, Apr 6, 2018, at 8:36 AM, Ryan Schmidt wrote:
> Ok, I understand. The person who d
Great discussion!
My preference for my Openmaintainer ports are probably more conservative /
controlling than those listed already. For any change except comment fixing and
rev-bumps due to dependency ABI / API changes, I prefer there to be a PR that I
can review before committing. I prefer a P
So ... what you're "voting" for here is that -any- change to a port be via a PR
or ticket with patch ... that only maintainers can touch ports they are named
on?
On Wed, Apr 25, 2018, at 6:49 PM, Jan Stary wrote:
> If you have an idea about a port,
> implement it (test it, etc) and propose it.
>
"back in the day" & IIRC: Octave required modern GNU grep to handle locale
correctly; the built-in grep wasn't guaranteed to do so. That was probably with
some 3.X series. With the 4.X series maybe it's no longer necessary; IDK. Worth
testing, IMHO. - MLD
On Sat, Jul 21, 2018, at 7:55 AM, Jan S
At least for me, the GitHub PG livecheck is failing for release/tags ... like,
all of them; it is not failing for commits. A quick search on the MP GIT master
history shows no changes to the GitHub PG ... so maybe it's just me? Or maybe
GitHub is messing with how it provides tarballs? Can anyon
OK thanks! - MLD
On Wed, Aug 15, 2018, at 1:51 PM, Christopher Jones wrote:
>
> https://trac.macports.org/ticket/56975
>
>> On 15 Aug 2018, at 6:37 pm, Michael Dickens
>> wrote:>>
>> At least for me, the GitHub PG livecheck is failing for release/tags
&g
I'll second that having a CoC isn't a bad idea. I like the shorter version <
https://www.contributor-covenant.org/version/1/4/code-of-conduct.html >, which
leaves room for our project to implement various parts as we see fit (the
PostgreSQL CoC is, in my opinion, a little too specific in some wa
I definitely agree that when a document enumerates examples -- even with the
"including but not limited to" -- it sets the stage for your scenario. Thus,
moving away from examples is probably wise. I, too, like the Ruby CoC: it's
short and concise, stating the basic principles rather than specif
Related, sort of: <
https://www.newyorker.com/science/elements/after-years-of-abusive-e-mails-the-creator-of-linux-steps-aside
>
In my experience, we in MacPorts-land don't have the obvious Linux issue. I
hope others don't experience the MacPorts project (developers, users,
commenters) as abus
Hi Mark - Do they have the same basic description, dependencies, homepage, and
build requirements? If so, then a subport could work. If any of these are
significantly different, then I'd recommend not doing a subport. My US$0.02
worth ... - MLD
On Sat, Oct 6, 2018, at 3:41 PM, Mark Brethen wrot
You can do whatever you want in a subport, and it is executed just for that
subport. You can have different subports in the same file with entirely
different dependencies, descriptions, livecheck, build, etc; I don't recommend
doing this, but if there's justification then one can do it. - MLD
O
In my opinion: A single rev-bump is required when changes to the overall
Portfile require it -- whether a single commit or multiple commits in a PR. The
overall goal of a rev-bump is to force the port to be updated; it is a
developer necessity & it's value is really not for the user's convenienc
I'll second Chris' note of thanks for MP folks keeping the PR queue short.
Since MP folks (especially Perry) have started stepping up to this task, I too
have been trying harder to do my part.
Now my US$0.02 worth and all IMHO about PR commit timeouts & why. - MLD
-Any- non-urgent fix should go
OSX sometimes doesn't provide useful features, or has issues. I love the idea
of the `snowleopardfixes` port to provide and fix for Snow Leopard. I'd support
expanding the concept to other missing features such as this `clock_gettime`
for ports installing on OSX that doesn't provide this functio
Re: <
https://github.com/macports/macports-base/commit/7921b2e05e9a4c9cda6efedee496affb305dcc07
>:
{{{
Date: December 29, 2017 at 10:54:09 AM EST
Author: Andrew L. Moore slew...@gmail.com
Committed by Mojca Miklavec mo...@macports.org
portextract: Create symlink if no $worksrcpath
If expected
hmidt wrote:
>
>
> On Dec 3, 2018, at 09:55, Michael Dickens wrote:
>
> > Re: <
> > https://github.com/macports/macports-base/commit/7921b2e05e9a4c9cda6efedee496affb305dcc07
> > >:
> > {{{
> > Date: December 29, 2017 at 10:54:09 A
On Dec 3, 2018, at 19:35, Michael Dickens wrote:
> >
> >> Here's the error (just do "sudo port extract cmake-devel"; it results in
> >> this error on every OS I tested, from 10.5 to 10.14):
> >> {{{
> >> Error: Fai
Ah yes; very good! Thanks for that fix; it should be removed with the next MP
release, yes? - MLD
On Wed, Dec 5, 2018, at 5:05 AM, Ryan Schmidt wrote:
> On Dec 4, 2018, at 12:03, Michael Dickens wrote:
> > Or, even more simply, just remove the post-extract all together. I don't
I'm in agreement here about keeping "revision 0" lines & will start
implementing this in my ports as they get updates. - MLD
On Sun, Dec 23, 2018, at 5:54 AM, Mojca Miklavec wrote:
> Dear Ken,
>
> On Sat, 22 Dec 2018 at 16:49, Ken Cunningham wrote:
> >
> > I would like to propose we stop asking
I've been trying to get Boost 1.69.0 working, without much luck yet because the
default installed library names as installed by MacPorts are changed from
"libboost_COMP-mt.dylib" to "libboost_COMP-mt-ARCH.dylib", where "COMP" is the
component name (e.g., "system", "thread") and "ARCH" is the abb
My vote: All in 1! (and 1 for all!)
On Sun, Jan 20, 2019, at 1:45 PM, Mark Anderson wrote:
> So, I want to change my email on all of my ports. Should I do them all
> in one big PR which is what my gut says, or should I do a separate one
> for each? It'd be the only change I'd make in this pass.>
OK yes we -offer- multiple versions, but only one version can be installed at a
time right now. And, when using "--layout==tagged" I'd bet that the resulting
ABI name changes for each installed variant, which means that all ports that
depend on Boost would have to be rebuilt when switching betwe
I'm trying to update NumPy to 1.61.1, with some success ... but have come up
with something odd with respect to the distutils/fcompiler/gnu.py provided
within NumPy: the "rpath" setting that I fixed a little over 2 years ago has
reared its ugly head!
The original code at the time was (NumPy 1.1
So from your list below as I've labeled them, only (3) works in my testing with
GCC8 as the pass-through compiler between the SciPy script creating this code &
the linker. I have not tested any other GCC version, but I'm guessing it's the
linker that's called that determines whether the -rpath f
Ken and I are discussing off-list too :)
gfortran is interpreting the '-Wl,-rpath' flag provided to it. In our testing
both "-Wl,-rpath,PATH" and "-Wl,-rpath -Wl,PATH" work, but "-Wl,-rpath=PATH"
does not work. Doesn't seem to matter if PATH or "PATH" (quoted or not).
It could be that gfortran8
Yet another interesting oddity came up in my debugging today trying to fix
CMake to build correctly on OSX 10.5 PPC(32). The issue is in the use of
std::lround, which is defined for c++11 and newer only, and, was possibly not
included as part of c++11 in GCC[4-6] ... it is apparently included in
shed pretty straight forwardly. We'll see & more as
I find it! - MLD
On Tue, Feb 5, 2019, at 12:07 AM, Joshua Root wrote:
> On 2019-2-5 13:59 , Michael Dickens wrote:
> > The interesting strangeness is that the clang++ compilers (both Apple and
> > MP) do not generate error
It looks like on OSX 10.6 (and, thus possibly elsewhere) that llvm-7.0 and
clang-7.0 create a circular dependency ... see the attached info. Not sure how
to work around this, but it is quite a PITA to do the equivalent of "sudo port
upgrade outdated" manually port by port ... Hoping someone can
I'm trying rebuilding the PortIndex ... but, otherwise no the port tree is at
the current GIT master and clean. I'm investigating ... - MLD
On Fri, Feb 8, 2019, at 11:40 AM, Chris Jones wrote:
> Hi,
>
> Clearly clang-7.0 and llvm-.7.0 cannot depend on clang-7.0 as a build
> dependency, that wil
Updated; rebuilt the PortIndex. No different. I find the following very
curious. "cmake" depends on itself circularly, which just can't be good;
and, the internal cmake dependency has somewhat different dependencies
compared with the outer one. It also has direct dependencies on clang-
7.0 and llvm
On Fri, Feb 8, 2019, at 3:02 PM, Christopher Jones wrote:
>> On 8 Feb 2019, at 7:43 pm, Michael Dickens
>> wrote:>>
>> Updated; rebuilt the PortIndex. No different. I find the following
>> very curious. "cmake" depends on itself circularly, which just c
OK some more sleuthing turns up that the issue was not the cxx11 PG, but
rather this line in the cmake Portfile:{{{
configure.cxx_stdlib libc++
}}}
before this line, the compiler is 'gcc-4.2', while after it is
'macports-clang-7.0' ... I'll keep poking, but I'm about done
with the rabbit hole ... -
wrote:
> On 8 Feb 2019, at 8:55 pm, Michael Dickens
> wrote:>> OK some more sleuthing turns up that the
> issue was not the cxx11 PG,
>> but rather this line in the cmake Portfile:>> {{{
>> configure.cxx_stdlib libc++
>> }}}
>> before this line, the
Adding in some debug printouts inside portconfigure.tcl, I think what's
happening is that when "libc++" is specified, somewhere inside
portconfigure.tcl the possible compilers to used gets pared down. Since
I'm not specifying one by default, and there is no blacklist or
whitelist, the fallback list
I just moved one of my build computers from OSX 10.10 to OSX 10.9, and I see
the same issue with Clang / LLVM 7.0. It seems to impact just Clang / LLVM 6.0
and 7.0 thus far, but it still exists; this is a completely separate install
from my 10.6 -- different computer and partition. I didn't seem
clang-7.0 is not installed yet on these systems ...
On Mon, Feb 11, 2019, at 11:28 AM, Ken Cunningham wrote:
> Please try deactivating clang-7.0 and then see what it says.
>
> the clang & llvm ports do conditional blacklisting depending on what is
> installed.
>
> The ports build on all systems
awesome! looking forward to having this issue behind me! I'll check out your
changes this afternoon ... - MLD
On Mon, Feb 11, 2019, at 11:37 AM, Ken Cunningham wrote:
> Someone, maybe me, forgot to blacklist clang 7.0 when building clang 7.0.
>
> It's a 10 second fix in the portfile; I'll take
I'm wondering what the correct blacklist is to get compilers that support
thread local storage.
I've found some Portfiles that state just:
{{{
compiler.blacklist-append {clang < 800.0.38}
}}}
which isn't enough since I know that the old Apple GCC and LLVM versions from
4.2 and older won't work .
OK wow that's quite the analysis! I'm going to go with just incorporating the
c++11 1.1 PG ... it'll work for now, and once "we" get around to dealing with
the changes to base from PR #88, it'll be a "universal" change to all Portfiles
that use c++11 PGs ... so we'd be good to go! Thanks! - MLD
wer OSX. - MLD
On Wed, Feb 13, 2019, at 1:41 PM, Michael Dickens wrote:
> OK wow that's quite the analysis! I'm going to go with just
> incorporating the c++11 1.1 PG ... it'll work for now, and once "we" get
> around to dealing with the changes to base from PR #88
CMake has the same dilemma.
I'm using Qt4 on macOS 10.14 latest & see no issues on a retina display
excepting that the "retina" concept isn't supported. IIRC we've added tweaks to
allow the user to select the default rendering engine, and that took care of
all of the issues I've heard of or see
Do we have a portgroup or whatever to select a compiler for c11 compliance? In
my testing using the c++11 1.1 PG isn't sufficient ... which might mean that
the c++11 compiler compliance selection isn't correct (but I doubt it); or that
c11 compiler compliance selection is different that that for
On my build computers, I have OSX 10.5 PPC and Intel 10.6 through 10.14; I'm
still working on 10.4 PPC and 10.5 Intel (I don't think I have the partition
space for 10.4 Intel, even if I wanted to install it, which I'm not sure I do).
I am regularly struggling to get Qt5 to update and sometimes e
Thank you, Ryan, for that info. I'll have to poke at the Qt5 PortGroup more &
see what it says about OSX 10.12 and 10.13 since that's where my current issues
are.
A quick followup from yesterday for this issue on OSX 10.13: I was surprised
that "port" did indeed "update" -all- of Qt5 from 5.12
On Fri, Apr 5, 2019, at 6:33 PM, Ryan Schmidt wrote:
> I am slightly concerned about this. The MacPorts base version is
> available to Portfiles, and Portfiles do occasionally need to do
> different things depending on the MacPorts base version. For example,
> the behavior of *.env options was c
I'm all for moving to this ISO, if someone wants to do this work. I already do
so in my ports for the version of most devel versions & some "release" versions
&& for comments too. - MLD
On Mon, Apr 8, 2019, at 1:42 AM, Mojca Miklavec wrote:
> On Mon, 8 Apr 2019 at 07:35, Joshua Root wrote:
> >
>
See < https://trac.macports.org/ticket/58338 > with title "lots-o-ports: decide
on common variant name to build documentation: +docs or +doc".
There are approximately 128 ports that use +doc or +docs as the variant to
build documentation. Of those, approximately 75 use +docs, while the rest --
I'd hope that there's a way to robustly move from one variant to the other
without the user having to engage with "port" to do so. I would hope that we
can avoid forcing the user to explicitly deactivate one and activate the other
variant.
I can think of a way to do this where we would end up w
> On Apr 15, 2019, at 7:42 AM, Michael Dickens wrote:
> >
> > Michael Dickens (michaelld) pushed a commit to branch master
> > in repository macports-ports.
> >
> >
> > https://github.com/macports/macports-ports/commit/44a0f481c71f1b7c72203943c7dfa241dd62d2f
Somehow I missed this commit ... after a quick review: YES; nicely done Marcus!
I'll echo Chris' question: can someone comment as to when the next MP release
will be so that we can start using this feature? Thx! - MLD
On Thu, Apr 18, 2019, at 5:20 AM, Chris Jones wrote:
> Hi,
>
> I would like t
Hi MacPorts folks - SWIG 4.0.0 has been released after much ado <
https://sourceforge.net/p/swig/news/2019/04/swig-400-released/ >. I'm positive
that this release fixes a bunch of bugs from the prior 3.0.12 release, as well
as adds a bunch of new useful features! But also as with any release the
Why not leave the build directory alone & let the cmake 1.1 PG handle it? Most
CMake-based ports can handle out-of-source building these days, and that's the
default for the cmake 1.1 PG, and the default setting here should work for the
vast majority of cmake-based ports.
To your query: You sho
Hi Fred - My thoughts follow. This will likely be my only reply to your post or
reply here since it's heading toward being off-topic & honestly comes down much
more to personal preference than any technical requirement; it's more along the
lines of a "culture war" such as "Mac versus PC", "iPhon
Just remember that "${destroot}" will not exist until the "destroot" phase
unless it is created in the Portfile script. If you need a different build
directory than that provided by the CMake PG, then you can in the Portfile
create some other directory & my advice would be to place it in the top
We're working on updating Boost to 1.70.0 <
https://github.com/macports/macports-ports/pull/4243 > ... we'd value others
participating, BTW! Thus far many ports work out of the box with it (current
Boost in MacPorts is 1.66.0, so there are some significant bug fixes and API
changes to deal with
s well.
Further thoughts? - MLD
On Fri, May 24, 2019, at 2:57 AM, Ryan Schmidt wrote:
>
>
> On May 19, 2019, at 10:13, Michael Dickens wrote:
>
> > I'm looking for advice on how to move forward with Boost 1.70.0's CMake
> > find scripts: do we just not install them
Stealth update ... fixed just now in
https://trac.macports.org/changeset/4c9cf8ada448a44cf3964f67278f77c27b72a7c9/macports-ports
On Wed, Nov 6, 2019, at 7:41 AM, Gregg Green wrote:
> Getting this error on macOS 10.13.6
>
> port install mariadb-10.2
> ---> Computing dependencies for mariadb-10.
Nice catch! Let me go about fixing that tpyo up! (yes, that was intentional ...)
On Tue, Apr 14, 2020, at 11:09 AM, Frank Schima wrote:
> Hi Michael,
>
>
>> On Apr 14, 2020, at 8:37 AM, Michael Dickens wrote:
>>
>> Michael Dickens (michaelld) pushed a commit to
There has been some discussion about the recent change Apple made for macOS
11.0beta7 for ARM Mac only (-not- Intel Mac at this time); we in MP-land had
some on this PR < https://github.com/macports/macports-ports/pull/8328 >. As
pointed out, a better venue for discussion would be these lists.
ntirely work with those built using
12.2beta? H
Thx! - MLD
On Tue, Sep 22, 2020, at 2:58 PM, Ryan Schmidt wrote:
>
>
> On Sep 22, 2020, at 13:29, Michael Dickens wrote:
>
> > % codesign -v - --ignore-resources
> > /opt/local/Library/Frameworks/Python.
Let's try this again from my MP email so that it gets to lists ... sorry for
duplicate emails!
I've finally gotten to the point of working out a hack solution.
One can -not- modify '/usr/bin' without a lot of effort. But, one can modify
'/Applications/Xcode[-beta].app/Contents/Developer/Toolcha
g of it off the top of my head.
- MLD
On Fri, Sep 25, 2020, at 10:52 AM, Michael Dickens wrote:
> Can't do both "exec" and then other stuff. If we remove the "exec" and
> then add in the codesign ... maybe ... I'll test that once I get this
> versio
macports-base.
Thx! - MLD
On Fri, Sep 25, 2020, at 11:04 AM, Ken Cunningham wrote:
>
>
> > 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're in luck. The latest Xcode 12.2 beta 2 seems to work with MacPorts without
modification on either end. Whew! Now back to getting ports installed and fixed
on ARM64! - MLD
On Fri, Sep 25, 2020, at 9:05 PM, Ryan Schmidt wrote:
>
>
> On Sep 25, 2020, at 10:31, Michael
Beta Xcode is at "/Applications/Xcode-beta.app" ... so, no, we can't hard code
that precisely. That said, it wouldn't be difficult to have this setting as a
preference in a .conf file, if it isn't already. That way it -can- be changed
for those of us who regularly run beta software. - MLD
On Fr
You're welcome! Although the level of my participation in MacPorts ebbs and
flows, I always greatly value what MacPorts provides for me -- my work and
hobbies -- and look to make things better when I can find the time to do so &
where the issue aligns with my talents / expertise. Cheers! - MLD
Very cool! Does this Clang provide Fortran compiling yet? - MLD
On Tue, Nov 24, 2020, at 12:47 PM, Ken Cunningham wrote:
> So the latest build of llvm etc did build through and install on Apple Silicon
>
> That is a milestone of sorts I think.
>
> This allows openmp, and the first alternative co
In MacPorts, "boost" is currently at 1.71.0. There are traditionally 3 Boost
releases per year: late April, mid August, and early December. The current
release of 1.75.0 was on December 11, 2020 <
https://www.boost.org/users/history/version_1_75_0.html >.
Boost is a challenging port to get upda
1 - 100 of 102 matches
Mail list logo
