On 2016-11-09, at 6:18 AM, René J.V. Bertin wrote:
> On Wednesday November 09 2016 13:01:42 Christopher Jones wrote:
>
>> In my view, no it is not practical. Pull requests are to pull one branch,
>> all diffs, from one to another. This is why I maintain the sooner people get
>> use to the ide
On 2016-11-12, at 9:39 AM, Vincent Habchi wrote:
> Folks,
>
> I have a private version of the llvm-3.9/Portfile (I just narrowed down the
> targets to PowerPC and X86 rather than build everyone of them which squanders
> time). But now I can’t git pull —rebase, I get an error message.
>
> Of
ma for?
>
> P.S: You can compress long log files to attach them.
It's used for Myst Online.
Description: libHSPlasma is a library for reading files used by the
Plasma game engine (created by Headspin, acquired by Cyan Worlds), such as
those in the games Myst V: End of Ages and
How do we use an in-progress port like this? i.e. --
sudo port selfupdate; port search hedgewars
returns nothing.
Oh, by the way -- it takes about 15,000 process Id's to update from 2.3.5 to
2.4.0, according to the Pid column in activity monitor.
On 2017-02-14, at 5:44 PM, Ken Cunningham
wro
My ... (if 2 bits is 25 cents, then 0.2 bits is 2.5 cents, ... ok, call it
inflation) 0.2 bits on this subject:
In the past, I attempted to write stuff with man page macros. I could not find
any actual docs on the macros or how to use them.
I found that there was no consistent style or rules fr
On 2017-06-13, at 4:20 PM, Joshua Root wrote:
> On 2017-6-14 08:18 , Christopher Jones wrote:
>> Had a look into this. The ROOT source never explicitly opens /dev/random in
>> read/write mode. Only read only.
>> However, it also uses a number of external library calls, like std::rand(),
>> and
Speaking of /dev/random, I did a little reading up on Yarrow today after
checking the man page.
Yarrow was effectively replaced by Fortuna, and Fortuna was published,
according to wikipedia, in 2003. Even the PDF paper describing it has a date of
2010. Linux got Fortuna in 2005.
This machine c
On 2017-07-05, at 6:16 AM, Jan Stary wrote:
> On Jul 05 08:38:16, a...@alum.wpi.edu wrote:
> https://trac.macports.org/wiki/FAQ#defaultprefix
> https://trac.macports.org/wiki/FAQ#usrlocal
>
> Can I install software in /usr/local while using MacPorts?
> No. ...
>
>
>> The issue is
An XML file dump:
This XML file does not appear to have any style information associated with
it. The document tree is shown below.
window["_gaUserPrefs"] = { ioo : function() { return true; } }
The MacPorts Project -- Home
...
On 2018-01-13, at 9:13 AM, Eitan Adler wrote:
>
> On 13 J
On 2018-02-23, at 9:49 PM, Helmut K. C. Tessarek wrote:
>
> Just because somebody knows svn, it doesn't mean that they don't have to
> learn git. A C programmer also has to learn how to write thread safe
> programs. They can't and won't get that concept from the standard "Hello
> world" example.
On 2018-02-24, at 5:57 AM, Clemens Lang wrote:
> Overall, I think we should install JDK 8 where possible. If we need
> compatibility with older versions, we should make sure to pass -target
> 1.7 when compiling.
And -target 1.5 or 1.5 machines :-).
(seriously, I have to bring one back to life ..
On 2018-03-12, at 1:35 PM, Ryan Schmidt wrote:
>
> We have a separate system, using Travis CI, for doing test builds of updates
> that have been submitted as pull requests but have not yet been merged into
> the repository master branch. But most maintainers that are committers don't
> submit
On 2018-03-08, at 9:32 AM, Ken Cunningham
wrote:
> Thank God.
>
> 10.6.8, agree.
So PPC machines will not get this upgrade?
---
Entertaining minecraft videos
http://YouTube.com/keybounce
On 2018-03-12, at 2:33 PM, Ryan Schmidt wrote:
>
> On Mar 12, 2018, at 16:31, Michael wrote:
>>
>> How about documenting the procedure to submit changes by poll requests,
>
> There's lots of documentation about how to submit a pull request, such as:
>
&g
On 2018-03-12, at 4:15 PM, Kenneth F. Cunningham
wrote:
>
> On 2018-03-12, at 4:26 PM, Kenneth F. Cunningham wrote:
>>
>>
>> It _could_ be done in 10.5 Intel, but that makes not much sense. Nobody
>> should be running 10.5 intel anyway, and if we made the libc++ switch in
>> 10.5 intel we'
On 2018-03-19, at 10:03 AM, Perry E. Metzger wrote:
> So my understanding (and I might be mangling it) is that the issue
> here is that there are two x86_64 registers that are reasonable
> candidates for pointing at thread local data, and Windows has picked
> a different one from macOS. The resu
Can someone give me a quick description of ABI 4 versus ABI 5? Google gives me
a document about plants.
On 2018-03-29, at 7:21 AM, Ryan Schmidt wrote:
>
> On Mar 28, 2018, at 07:24, Mojca Miklavec wrote:
>
>>> I know it is nice to see all packages for a port in one place and it is
>>> easier to check what has already been built. But hopefully we would have
>>> this information on individual port
On 2018-03-29, at 8:13 PM, Ryan Schmidt wrote:
> The mirrors don't run MacPorts; they use rsync.
rsync cannot detect renames?
---
Entertaining minecraft videos
http://YouTube.com/keybounce
On 2018-04-07, at 5:04 PM, Rainer Müller wrote:
> For distfiles, it would be possibile to apply a trick with a union mount
> to create a local overlay that allows writing new files:
>
> mount -t nfs -o ro,union mirror:.../distfiles \
>/opt/local/var/macports/distfiles
> hdiutil create -o /tm
I took a look at the change log, and saw there is a command, port diagnose
bash-3.2# port -v diagnose
Error: process_cmd failed: dsAttrTypeNative:shell: /bin/bash
launchctl: Couldn't
stat("/System/Library/LaunchDaemons/com.apple.DirectoryServicesLocal.plist"):
No such file or directory
nothing f
On 2018-04-26, at 5:01 PM, Ryan Schmidt wrote:
> To do this, I was first required to stash or commit my unfinished work. I
> used git stash, followed by git checkout my-other-branch. After finishing
> work there, I returned to my original branch with git checkout
> my-original-branch, and res
On 2018-09-03, at 3:54 AM, Jan Stary wrote:
>> - after running `selfupdate`, MacPorts could ask the user if they
>> next want to upgradeall their outdated ports.
>
> No. This insistence on the latest bugs is a disease.
> I want the version I have, which I know to work, unless I have
> a re
On 2018-09-10, at 9:15 AM, Jan Stary wrote:
> On Sep 10 08:24:39, ken.cunningham.web...@gmail.com wrote:
>> I don't know if I asked this correctly, and it's not macports-specific, but
>> I don't know where else to ask.
>>
>> Some of the code I'm trying to tweak (llvm-N, webkit2-gtk-N, etc) ha
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, to 3MBytes iirc, by printf() dragging
> in half the known universe at l
If I wanted to run a vm of something at 10.12 or newer, on a host running
10.9.5, is it doable?
If not: How well does 10.9.5 run as a guest on newer OS's?
Keep in mind: 10.9.5 was really the last "low security sandbox", and newer OS's
restrict things. 10.9.5 was the last "old audio model" syste
On 2020-06-25, at 3:03 PM, Ralph Seichter wrote:
> * macpo...@parvis.nl:
>
>> i would like these 10.11 and 10.13 as vm guest under 10.15.
>
> Why as a VM guest? Have you considered installing and booting different
> macOS versions on separate partitions of the same machine? You can even
> ins
On 2020-06-25, at 3:52 PM, Perry Lee wrote:
> On Thu, Jun 25, 2020, at 3:32 PM, Michael wrote:
>> (Apple's software license says I can run it on Mac hardware, right? It
>> doesn't say that it has to be the raw OS, does it?)
>
> From the software license agreem
> On Jun 25, 2020, at 20:50, Ryan Schmidt wrote:
>
> If you meant that older systems can't read APFS volumes, that's true. Sierra
> and later can read APFS, High Sierra and later converts your boot volume to
> APFS if it's an SSD, Mojave and later converts your boot volume to APFS no
> matter w
Attempting to install supertux complains on libomp.
Logfile shows compiler complaints about atomic and variable templates.
> :info:build In file included from
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/work/openmp-
Ok, lets say I wanted to use a 2014 laptop running 10.9.5 as the host -- which
VM would let me run a 10.12 and a 10.14 guest?
Bonus points if it can run a 10.7 (lion) guest.
Triple bonus if it can run either a PPC guest, or a 10.6 running rosetta :-)
(That's *NOT* a joke, some software never up
On 2020-12-06, at 7:46 PM, Joshua Root wrote:
> On 2020-12-7 13:21 , Michael wrote:
>> Ok, lets say I wanted to use a 2014 laptop running 10.9.5 as the host --
>> which VM would let me run a 10.12 and a 10.14 guest?
>>
>> Bonus points if it can run a 10.7 (lion)
I am still on a 10.9.5 system, and I am consistently seeing messages from
sandbox in the system log that a certain program, that uses a helper program,
cannot receive some messages because of a signing problem.
Would this be helped by using adhoc local signing when installing?
(nb: This is fire
On 2022-04-17, at 8:50 AM, Christopher Nielsen wrote:
> So they proceeded to open the side cover, flashlight in hand, and immediately
> noticed a problem: There was a small pool of green cooling fluid.
... and as I see this, I'm thinking back to a simpson's episode, where Moe
bought a top of
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
ting as a mentor for GSoC 2017 with The MacPorts Project.
>
> Call out for mentors and admin from GSoC 2015:
> Jeremy, Clemens,
>
> Would you like to be the admin/backup admin again this year ?
>
> Clemens, Lawrence, Michael, Rainer,
>
> There are some of your ideas i
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
com/macports/macports-ports/commit/5698d9483b44984a826d0f41154a4381b7957223#diff-853d965c334d38035ad973a33b412b69>
>
> That is from July last year though - There have been no significant
> changes since then. I don't know why Michael would only seem this now ?
>
> Anyway, not
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
1 - 100 of 150 matches
Mail list logo
