Re: #55884: mandoc @1.14.3: not using the right compiler

On 2018-02-27, at 11:52 PM, Jan Stary wrote: > The ticket is closed, so I will continue here. > >> Actually it's not specific to the universal variant. Rather, the problem >> is that the port is not UsingTheRightCompiler. > > mandoc's ./configure sets CC to whatever make(1) thinks CC is: > CC=`

elegant deps for a gtk theme?

I have a nice gtk2 / gtk3 theme that mimics sierra. For dependencies, if you are using this theme with gtk2, you need gtk2-murrine installed. gtk3 works as is. There aren't too many port themes to copy ideas from. adwaita lis

need someone with steely git-fu to resolve a minor conflict in PR #740

I have tried several times to resolve the minor conflict in this PR and I just keep messing it up. It looks super trivial, but ... https://github.com/macports/macports-ports/pull/740 Please, if you do fix it, tell me what you did so I don't have to ask this particular silly question again. Tha

thread_local with clang-5.0 on 10.6 (and lower) -- works , but slight issue with libc++ that I would appreciate some help with.

thread_local is a c++11 feature that newer software is increasingly using. It is available with gcc 4.8+, and with clang since about clang-3.5. On macOS (darwin) it requires system supports that arrived in 10.7. My goal is to get thread_local with clang-5.0 and newer on 10.6 (and 10.5). Turns

Re: Search for a MacPorts Mascot: looking for talented artists

On 2018-02-21, at 12:36 PM, Dave Horsfall wrote: > On Wed, 21 Feb 2018, Mojca Miklavec wrote: > >> During the GSOC meeting in Mountain View we had some fruitful evening >> discussions where we were heavily criticised for not having our own happy >> fluffy animal mascot (like a flying platypus?

Re: [macports-ports] 01/02: pugixml: update to v1.8.1

On 2018-02-13, at 4:54 AM, Ryan Schmidt wrote: >> >> -github.setupzeux pugixml 1.7 v >> -github.tarball_from releases >> +github.setupzeux pugixml 1.8.1 v > > Why no longer use the release download? If a developer goes to the effort of > providing a release download, we should

system -notty what is it for?

I noted here https://github.com/macports/macports-base/blob/master/src/pextlib1.0/system.c an option for system called “-notty” Searching macports-ports seems to show no ports use this. What would that option be us

Re: cxx11 portgroup: C++11, C++14, C++17

> On Feb 4, 2018, at 9:36 PM, Ryan Schmidt wrote: > > We should think about how this will work if and when it is integrated into > MacPorts base and not a portgroup. I think starting with configure.cc_std and > configure.cxx_std might work well. > I’m trying to really understand your appr

Re: cxx11 portgroup: C++11, C++14, C++17

Somewhere in the tickets Marcus has this at least 1/2 done... K Sent from my iPhone > On Feb 4, 2018, at 7:14 PM, Ryan Schmidt wrote: > > >> On Feb 4, 2018, at 18:09, Ken Cunningham wrote: >> >>> On Feb 4, 2018, at 7:03 PM, Ryan Schmidt wrote: >>&

Re: cxx11 portgroup: C++11, C++14, C++17

Please not more portgroups, tho. How about we just move up that clang floor as time goes by? K Sent from my iPhone > On Feb 4, 2018, at 7:03 PM, Ryan Schmidt wrote: > >> On Feb 4, 2018, at 18:01, Ken Cunningham wrote: >> >>> On Feb 4, 2018, at 6:56 PM, Ryan

Re: cxx11 portgroup: C++11, C++14, C++17

By providing a current clang, like 5.0, all these are covered I believe. The PG is really misnamedshould be "modern compiler" PG or similar. K Sent from my iPhone > On Feb 4, 2018, at 6:56 PM, Ryan Schmidt wrote: > > The cxx11 portgroup is fine for C++11, but what do we want to do about

cxx11 1.0 PG -> mass change to cxx11 1.1 ?

I think it's time to consider a mass change of any ports that remain on the old cxx11 1.0 PG to the new cxx11 1.1 PG. Any thoughts? Ken

Re: [macports-ports] branch master updated: apiextractor: mark obsolete

Thanks Frank! Best, K On 2018-01-29, at 10:59 AM, wrote: > Hi Ken, > > > Please follow the guidelines for obsoleting a port: > > https://guide.macports.org/#development.obsolete-portgroup > > You have not specified the replacement port and have too many lines in > Portfile. > > If there

Re: Redistributable binaries for 10.5 or 10.6 from C++11 sources

On 2018-01-14, at 12:33 PM, Mojca Miklavec wrote: > > I used to build for 10.6/x86_64, 10.6/i386 & ppc on the same 64-bit > Snow Leopard VM. Doing C++11 cross-compilations for PPC is likely to > be mission impossible, so I'll need to find a proper PPC, but let's > see if I can get it working nati

Re: Redistributable binaries for 10.5 or 10.6 from C++11 sources

On 2018-01-14, at 12:33 PM, Mojca Miklavec wrote: > On 13 January 2018 at 18:03, Ken Cunningham wrote: >> I know it can be done. TenFourFox does it. It builds with Macports >> infrastructure, required parts to support c++11 are moved into the >> application bundle, and t

something is wrong with www.macports.org webpage

hacked? misconfigures?

Re: Redistributable binaries for 10.5 or 10.6 from C++11 sources

I know it can be done. TenFourFox does it. It builds with Macports infrastructure, required parts to support c++11 are moved into the application bundle, and there are scripts that appear to update the install names as you describe. There is a description in the "building tenfourfox" page.

Re: a no-homepage homepage for ports with dead homepages

On 2018-01-12, at 2:12 AM, Rainer Müller wrote: > > Nit pick: I would have called it NoHomepage (small letter p), as the > compound form seems to be more common than two words and it is used this > way as Portfile option and in the wiki page itself. Done. I always seem to want to CamelCase syll

Re: a no-homepage homepage for ports with dead homepages

On 2018-01-11, at 9:37 AM, Ken Cunningham wrote: > > But if I can find a saved one at archive.org, that would be better, to be > sure. > > K I've been prospecting MacPorts errors reported by repology <https://repology.org/maintainer/nomaintainer%40macports.org/proble

Re: a no-homepage homepage for ports with dead homepages

On 2018-01-11, at 9:30 AM, Jan Stary wrote: > > Voila, that's its homepage then. > Well now we're back to where I started :> But if I can find a saved one at archive.org, that would be better, to be sure. K

Re: Python 2.7 – allow another db version beside 4.8

On 2018-01-11, at 12:28 AM, Jan Stary wrote: > > > Does anyone now? If my port requires (say) python (any python), > what is the right way to say that? (In some cases, having > /usr/bin/python is just fine.) > MacPorts tries to undertake the principle of reproducible builds

Re: a no-homepage homepage for ports with dead homepages

On 2018-01-11, at 12:24 AM, Jan Stary wrote: > > For ports that don't have a homepage, the simplest thing imho > is not to declare one in the Portfile. a: not possible $ port lint ---> Verifying Portfile for aee Error: Missing required variable: homepage b: IMHO not desirable > If the sourc

a no-homepage homepage for ports with dead homepages

I like this idea from gentoo, for a homepage we can use when old homepages disappear, eg port "aee". We might do something like this as well, perhaps. It assumes the source has been mirrored somewhere reachable. Unless I find out we already have one t

Re: port "gohome" --> "A keychain cannot be found."

> On Jan 2, 2018, at 3:01 PM, Frank Schima wrote: > > > I can completely reproduce this. I think this must be a base bug because the > open command works by itself. I have never seen this before because I always > have Safari running on my computers. > > Ken, would you file a ticket about

Re: port "gohome" --> "A keychain cannot be found."

> On Jan 2, 2018, at 1:14 PM, Rainer Müller wrote: > > On 01/02/2018 08:52 PM, Ken Cunningham wrote: >> Often, but oddly not always, when I try to use >> >> port gohome PORTNAME >> >> it opens Safari but then brings up a modal dialog box with the ab

port "gohome" --> "A keychain cannot be found."

Often, but oddly not always, when I try to use port gohome PORTNAME it opens Safari but then brings up a modal dialog box with the above message, requiring Safari to be force-quit. If you click the option button “Reset To Defaults” it offers to erase all your Safari passwords, etc. I haven’t

Re: compiler selection on PPC

On 2017-12-06, at 12:19 PM, Ken Cunningham wrote: > There have been a number of tickets over the past two years that relate to > compiler selection on PPC systems. > > Basically, on PPC, if the default compiler (gcc 4.2 on 10.5, or apple-gcc42 > on Tiger) does not work to bu

Re: [macports-ports] 01/02: meson-1.0: new PortGroup

> On Dec 30, 2017, at 11:52 PM, Ryan Schmidt wrote: > >> +# Meson's install_name currently seems to be broken, so workarounds might >> be needed to make ports actually work. >> +# See: https://github.com/mesonbuild/meson/issues/2121 > > Yeah something is going to have to get fixed there. I do

Re: set merger_configure_env question

> On Dec 30, 2017, at 11:00 AM, Marcus Calhoun-Lopez > wrote: > > On Sat, Dec 30, 2017 at 11:36 AM, Ken Cunningham > wrote: >> configure.env-append libIDL_cv_long_long_format=ll > I would respectfully suggest that this is not a good fix. > As much as possible, we w

Re: set merger_configure_env question

> On Dec 30, 2017, at 9:20 AM, Marcus Calhoun-Lopez > wrote: > >> # Required when cross-compiling. >> foreach arch ${configure.universal_archs} { >>lappend merger_configure_env(${arch}) libIDL_cv_long_long_format=ll >> } Turns out none of these shenanigans are needed. Looks like simpl

set merger_configure_env question

Trying to build libidl+universal on 10.5 fails. I’m set up to build it universal, with universal_archs as i386 and x86_64. It uses the muniversal portgroup, which I don’t know tons about. It fails because an environment variable doesn’t get set properly during the x86_64 build: checking for ac

Re: [macports-ports] branch master updated: supertuxkart: allow build on 10.7 and 10.8

On 2017-12-25, at 6:07 PM, Ryan Schmidt wrote: > > This doesn't match now. The error message says it needs 10.7 or later, but > the port allows installation on 10.6 or later. Which is it? > > If it builds on 10.6, does it need the 10.7 SDK to do so? If so, the port > should enforce that. See

Re: use_autogen

can you add environment variables to "use_autoconf"? some of these autogen.sh scripts automatically run configure if you don't set one. K > On Dec 23, 2017, at 7:38 AM, Ryan Schmidt wrote: > > Should we add a "use_autogen" (or "use_autogen_sh") option to MacPorts base? > > We already have "u

Re: Question about meson and boost libraries

On 2017-12-22, at 11:51 AM, Mojca Miklavec wrote: > > meson recently changed something in that respect, but I don't fully > understand how that rpath-stuff works, so something needs to be fixed > in either case). It takes a moment to grok it. Here is a 1 minute summary of all you need to know

Re: Question about meson and boost libraries

On 2017-12-22, at 10:14 AM, Benjamin Redelings wrote: > Hi, > > I'm new to macports. I'm the author or the bali-phy software, and I'm > working on updating the ancient Portfile for it. The software has changed a > lot since someone wrote the original Portfile years ago, and I was complet

Re: Addressing Port submission failures on Travis

> On Dec 20, 2017, at 1:04 AM, Mojca Miklavec wrote: > >> On 20 December 2017 at 09:04, Ken Cunningham wrote: >> keep the master branch up to date, but leave your PR branch alone until it's >> merged, then delete the branch. > > Indeed, that's th

Re: Addressing Port submission failures on Travis

keep the master branch up to date, but leave your PR branch alone until it's merged, then delete the branch. > On Dec 19, 2017, at 11:54 PM, Andrew L. Moore wrote: > > I’m thinking that rebasing against my GitHub fork of MacPorts is what sent my > pull request into a tail spin (second question

Re: I did something stupid and now can't uninstall a port

On 2017-12-19, at 6:51 PM, Joshua Root wrote: > > Well, that's unfortunate. We probably shouldn't allow port names that > parseFullPortSpec doesn't recognise as such. (Or add a syntax to > explicitly specify name,version,revision,variants separately and > unambiguously.) > > This particular case

Re: I did something stupid and now can't uninstall a port

n 12/19/2017 08:24 PM, Ken Cunningham wrote: >> I have a port I'm working on, with a gui subport: >> >> sheepshaver >> sheepshaver-gui >> >> I accidentally made a typo installing the subport, and I typed this: >> >> sudo port -v install

I did something stupid and now can't uninstall a port

I have a port I'm working on, with a gui subport: sheepshaver sheepshaver-gui I accidentally made a typo installing the subport, and I typed this: sudo port -v install subport=sheepshaver=gui now I have a port installed like this: $ port -v installed | grep sheep sheepshaver=gui @20171215_0

Re: Installing a Python wheel (whl) file using a port - Tensorflow

https://github.com/Homebrew/homebrew-core/blob/master/Formula/libtensorflow.rb On 2017-12-18, at 2:09 PM, Enrico Maria Crisostomo wrote: > Thanks Ken. > > Actually I checked brew and they haven't got a formula for TensorFlow (at > least at the moment). > > On 18 December 2017 at 22:57:42, Cu

Re: Installing a Python wheel (whl) file using a port - Tensorflow

FYI, I recall homebrew has tensorflow, so you might get some hints looking at their formula. Marius was taking this on a few months ago as well, so might have some thoughts. Ken On 2017-12-18, at 1:52 PM, Enrico Maria Crisostomo wrote: > Hi, > > I’m trying to create a port for TensorFlow and

Re: trace mode fails with sh: /usr/bin/tar: No such file or directory

> On Dec 17, 2017, at 12:52 PM, Joshua Root wrote: > > On 2017-12-18 07:18 , Ken Cunningham wrote: >> I haven’t been able to use trace mode to test port installs because of >> the following error. Am I doing something wrong? > > Aside from running master? :) >

trace mode fails with sh: /usr/bin/tar: No such file or directory

I haven’t been able to use trace mode to test port installs because of the following error. Am I doing something wrong? $ sudo port -vst install poco ---> Fetching distfiles for poco ---> poco-1.6.0-all.tar.bz2 does not exist in /opt/local/var/macports/distfiles/poco ---> Attempting to fetc

Re: compiler selection on PPC

> On Dec 17, 2017, at 12:02 AM, Jeremy Huddleston Sequoia > wrote: > > > >> On Dec 6, 2017, at 20:09, Ken Cunningham >> wrote: >> >> >>> On 2017-12-06, at 12:19 PM, Ken Cunningham wrote: >>> >>> There have been a numb

Re: Build Failure on ports-10.6_i386_legacy: ocaml, py27-certifi, py27-mistune, py27-scandir, py27-tz, py27-zmq, root6, xrootd

I get the proper error message, as far as MacPorts allows at present: $ sudo port -v install ocaml ---> Computing dependencies for ocaml. ---> Fetching distfiles for ocaml Error: ocaml @4.05.0 requires OS X 10.7 or later. Error: Failed to fetch ocaml: incompatible OS X version Error: See /opt/l

Re: [macports-ports] branch master updated: multiple ports: update maintainer

On 2017-12-13, at 8:29 AM, Ryan Schmidt wrote: >> -maintainers slor.net:james gmail.com:ken.cunningham.webuse >> openmaintainer >> +maintainers {kencu @kencu} openmaintainer > > Should James have been removed here? In your other changes, you're just > updating your own

Re: [macports-ports] branch master updated: minetest: new port

> On Dec 10, 2017, at 4:54 PM, Ryan Schmidt wrote: > >> +# also need the minetest game >> + >> +post-extract { >> + system -W ${worksrcpath} "curl --output minetest-game.tar.gz >> https://codeload.github.com/minetest/minetest_game/tar.gz/${version}"; >> + system -W ${worksrcpath} "tar xvf mine

Re: [macports-ports] branch master updated: minetest: disable postgresql on 10.7

I knew you were going to say that :) Just didn't want to have to revbump everyone so soon :( Sent from my iPhone > On Dec 10, 2017, at 10:13 AM, Ryan Schmidt wrote: > > >> On Dec 9, 2017, at 16:14, Ken wrote: >> >> Ken (kencu) pushed a commit to branch master >> in repository macports-ports.

Re: [macports-ports] branch master updated: irrlicht: new port

> On Dec 9, 2017, at 7:59 AM, Ryan Schmidt wrote: > >> +set flist [glob ${worksrcpath}/include/*.h] >> +foreach f $flist { >> +file copy -force $f >> ${destroot}${prefix}/Library/Frameworks/IrrFramework.framework/Versions/A/Headers >> +} > > Note that it's simpler to use

Re: does cmake really need to blacklist macports-clang >= 3.8?

> > But come to think of it, if the commandline configure.compiler override is > not a glitch in my local install it also means that this concern is moot. > As an aside, I make extensive use of the command line configure.compiler override and also the default_compiler setting in macports.conf

Re: [macports-ports] branch master updated: irrlicht: fix build on case-sensitive file systems

will put in a reminder to do so thanks, K > On Dec 9, 2017, at 8:50 AM, Ryan Schmidt wrote: > > > On Dec 9, 2017, at 10:07, Ryan Schmidt wrote: > >> I tried it myself and what I get is: >> >> Error: Failed to extract irrlicht: error renaming: target >> "/opt/local/var/macports/build/_Users_r

Re: [macports-ports] branch master updated: irrlicht: new port

will look into these. thanks > On Dec 9, 2017, at 7:59 AM, Ryan Schmidt wrote: > > >> On Dec 8, 2017, at 18:03, Ken wrote: >> >> Ken (kencu) pushed a commit to branch master >> in repository macports-ports. >> >> >> https://github.com/macports/macports-ports/commit/1be703755e82b668905993ab9a

Re: [macports-ports] branch master updated: irrlicht: fix build on case-sensitive file systems

I tried "move" first but kept getting a weird error that I could not understant or fix. Gobbelygook showed up in the new filename. ? Ken > On Dec 9, 2017, at 7:51 AM, Ryan Schmidt wrote: > > >> On Dec 8, 2017, at 18:38, Ken wrote: >> >> Ken (kencu) pushed a commit to branch master >> in rep

Re: MacPorts Meeting 2018

Would be nice to go. My wife is from not too far from there - near Pordenone, Italy. We were there for quite a bit of the summer this year. Very hot August. Realistically, though, not too likely to be able to come to this one. March break here in Canada is usually for desperately heading to sun

Re: [macports-ports] 03/06: cxx11 PG: do not force the use of depends_lib-append

I have suggested in the the past that depends_* could be a synonym for depends_*-append. That would solve this easily. we could have a depends_*-reset if anyone really wants that (dont see it ever being used, but ...) K > On Dec 8, 2017, at 4:28 AM, Ryan Schmidt wrote: > > >> On Dec 8, 2017

Re: compiler selection on PPC

On 2017-12-06, at 12:19 PM, Ken Cunningham wrote: > There have been a number of tickets over the past two years that relate to > compiler selection on PPC systems. > > Basically, on PPC, if the default compiler (gcc 4.2 on 10.5, or apple-gcc42 > on Tiger) does not work to bu

compiler selection on PPC

There have been a number of tickets over the past two years that relate to compiler selection on PPC systems. Basically, on PPC, if the default compiler (gcc 4.2 on 10.5, or apple-gcc42 on Tiger) does not work to build a port, the only other compiler that should be then used is gcc6. Maybe some

Re: Too many compilers needed for C++11

llvm-3.7 is to support ld64 and cctools - I think those stay with llvm-3.7 for bootstrap reasons. clang/llvm 5.0 is the current cxx11 1.1 compiler, so that is what is being called up. clang-3.9 should not be needed. I don't think it is. neither should clang/llvm-4.0 - not sure what is calling f

Re: [macports-ports] branch master updated: PG snowleopard_fixes: don't require depends_lib-append

On 2017-12-04, at 10:07 AM, Ryan Schmidt wrote: > > My question was: does the header belong in cxxflags only? I assumed it should > also go in cflags. If that's wrong... why? > Oh, right. Yes, I think you're correct. The header, if needed, would be needed for C code as well. Good catch. I gu

Re: [macports-ports] branch master updated: PG snowleopard_fixes: don't require depends_lib-append

On 2017-12-04, at 9:26 AM, Ryan Schmidt wrote: >> +if {${snowleopard_fixes.addheader} eq "yes"} { >> +configure.cxxflags-append -include >> ${prefix}/include/snowleopardfixes.h >> +} > > > Is the header only needed for C++ code? Not for C code? > The header is almost never ne

Re: help with generating a diff with svn for libcxx

libcxx/commit/b2e9337b06425b4af554651d5f2fa65615eb009f.diff> Happy to learn the " right way" when anyone has time. Thanks, K On 2017-12-03, at 12:28 PM, Ken Cunningham wrote: > I'm getting stuck generating a diff file for the changes made in revison > 307461 of libcxx, so I can backpor

help with generating a diff with svn for libcxx

I'm getting stuck generating a diff file for the changes made in revison 307461 of libcxx, so I can backport that into llvm-4.0 to fix the build of libcxx for PowerPC. I have checked out the llvm, libcxx, and libcxxabi sources

Re: homebrew's top 1000 requested installs

rough and enabled, as that is about #10 on the list. Stuff like that. Ken On 2017-11-29, at 10:34 AM, Craig Treleaven wrote: >> On Nov 29, 2017, at 11:42 AM, Ken Cunningham >> wrote: >> >> in case anyone is curious what people are requesting. >> MacPorts

homebrew's top 1000 requested installs

in case anyone is curious what people are requesting. MacPorts has almost all of these, I thought, glancing down the list. https://brew.sh/analytics/install-on-request/ Ken

Re: [MacPorts] #55365: ttfautohint @1.7: new port

Sorry. Small hiccup slipped past me. Fixing it now. Ken > On Nov 23, 2017, at 4:49 PM, MacPorts wrote: > > #55365: ttfautohint @1.7: new port > --+--- > Reporter: tuffnatty| Owner: ken-cunningham-web

Re: add git dependency to github portgroup?

On 2017-11-20, at 9:21 AM, Joshua Root wrote: > On 2017-11-21 04:02 , Ken Cunningham wrote: >> A recent commit of Dave's made me wonder if should we add a callback >> dependency for something like >> >> depends_build-appendbin:git:git >> >>

add git dependency to github portgroup?

A recent commit of Dave's made me wonder if should we add a callback dependency for something like depends_build-appendbin:git:git to the github portgroup? I looked in there, expecting to see one, but didn't.

Re: haskell base library >= 4.8 ?

ave changed, and ours says 2014.something.) Ken > On Nov 20, 2017, at 4:46 AM, Rainer Müller wrote: > >> On 2017-11-20 01:06, Ken Cunningham wrote: >> I'm updating hedgewars, and there is a build error (see below). The >> hedgewars devs say this means the base lib

haskell base library >= 4.8 ?

Hi all, I'm updating hedgewars, and there is a build error (see below). The hedgewars devs say this means the base library is too old, and needs to be >= 4.8. I don't actually know what version of the haskell base library we have at present, or how to update it (if we can). Any ideas how that

Re: how to build against an older SDK - library not found for -lcrt1.10.6.o

On 2017-11-15, at 8:49 AM, Ryan Schmidt wrote: > > > You don't need to do that manually. Just set "configure.sdk_version 10.4"; > MacPorts then adds the right -isysroot flags for you. > thanks. I will look into doing just that. And by the way, I'd like to have a chat one day with the fellow

Re: how to build against an older SDK - library not found for -lcrt1.10.6.o

> > > Are you also using a 10.4 deployment target? > > - Josh I think that might be it. If you don't pass -macosx-version-min to the linker, it assumes 10.6. I'll work on that. Thanks, Ken

how to build against an older SDK - library not found for -lcrt1.10.6.o

Hi, smart people. I'm trying to write up a Portfile (for TenFourFox) that requires building against an older SDK (10.4u) and I'm on 10.6 Intel. It's easy enough to pass in the sysroot configure.cxxflags-append -isysroot ${developer_dir}/SDKs/MacOSX10.4u.sdk configure.cflags-app

Re: gimp on HS

On 2017-11-13, at 9:16 AM, Rainer Müller wrote: > > regenerated with our patched version. The bug report [1] against > intltool never received any attention from upstream. > [1] https://bugs.launchpad.net/intltool/+bug/1197875 It's always amazing to me how anything less than an obsequious note

Re: [macports-ports] branch master updated: util-linux: add snowleopardfixes

This ticket this fix came from predated the snowleopard_fixes portgroup. You're quite correct - since the portgroup was committed, that would be the proper fix now. -- K On Fri, Nov 10, 2017 at 5:59 PM, Ryan Schmidt wrote: > > On Oct 19, 2017, at 08:57, Kurt Hindenburg wrote: > > > Kurt Hindenb

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 2:20 PM, Joshua Root wrote: > > > Looks more like it was made to support programs using gnulib, which > apparently provides its own setlocale implementation. I would probably > have tried including the gettext header last before undefining the macro. > > The intent of having t

Re: Help needed: fix build issue with xdxf_makedict in older platforms

> > Unfortunately that did not work for me, the port fails at the configure phase: > > -- The C compiler identification is Clang 5.0.0 > -- The CXX compiler identification is Clang 5.0.0 > -- Check for working C compiler: /opt/local/bin/clang-mp-5.0 > -- Check for working C compiler: /opt/local/b

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 2:13 AM, Joshua Root wrote: > > > There is an indirect dependency via glib2. The issue really is the macro > in the gettext header causing unintended changes to the C++ headers. > > - Josh totally get it now. It builds easily with libc++, but fails with libstdc++ or macport

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 12:30 AM, Ken Cunningham wrote: > > >> >> -- Found libintl: /opt/local/lib/libintl.dylib my error - blurry eyes. like josh said, this is provided by gettext. perhaps gettext is the real missing dep.

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 12:27 AM, Ken Cunningham wrote: > > -- Found libintl: /opt/local/lib/libintl.dylib > > so perhaps there is a missing dep for port:libiconv > > Ken > > No, seems you have that dep there. Maybe it's the newer compiler... I'll include

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-07, at 12:03 AM, Ken Cunningham wrote: > > On 2017-11-06, at 11:35 PM, Leonardo Brondani Schenkel wrote: > >> Hello all, >> >> I recently introduced a new port, xdxf_makedict, which built successfully on >> my box (macOS 10.13) on first try. Howev

Re: Help needed: fix build issue with xdxf_makedict in older platforms

On 2017-11-06, at 11:35 PM, Leonardo Brondani Schenkel wrote: > Hello all, > > I recently introduced a new port, xdxf_makedict, which built successfully on > my box (macOS 10.13) on first try. However, after it got merged I started > getting notifications from the buildbots about build failure

Re: [macports-ports] branch master updated: cmake: require C++11 for both release and devel.

On 2017-11-06, at 7:13 PM, Ryan Schmidt wrote: > Wow, this really sucks. It means that on Mountain Lion and earlier, cmake now > depends on clang-5.0, clang-4.0, clang-3.9, clang-3.8, and clang-3.7, and on > Lion and earlier, also clang-3.4. It also says all compilers are blacklisted > so I'm

interesting tool - deploymate - scans software for MacOS SDK needs

I thought I would mention a tool I came across recently that might be of some use to people on this list who are sometimes tasked with making software runnable on older systems. Deploymate scans source code for SDK dependencies, and will list certain MacOS SDK cal

Re: Question about compiler blacklisting (llvm-gcc for wxWidgets)

> On Nov 2, 2017, at 12:20 PM, Ryan Schmidt wrote: > The part where it allows a port to be compiled with MacPorts libstdc++. Why > is this ok? Didn't we used to have the problem that C++ software compiled > with gcc would crash because it used new gcc libstdc++ but a library it used > was us

Re: Question about compiler blacklisting (llvm-gcc for wxWidgets)

I know it's not the party line, but IMHO to minimize hassles supporting these older systems we might well just flush them all to build everything with clang-4.0 or 5.0, to match the newer systems. Then most all systems would see similar or identical errors. I'm not too clear on why it's worth

Re: [macports-ports] branch master updated (27855f9 -> 8d04fcb)

I suggested that to the OP, but no response... It is admittedly a bit tedious to clone his entire repo to fix it for him, and the lure to do it right in the browser is strong when it takes but 5 seconds to fix on the web interface -- Are we sure we don't want to enable the 'squash and merge' op

Re: Request for Feedback

I'm interested, and greatly appreciate your effort in taking this issue on! I hope we can reach a consensus on this. K > On Oct 21, 2017, at 10:11 PM, Marcus Calhoun-Lopez > wrote: > > I have created a new PortGroup to test possible changes to the base > code concerning compiler selection. >

Re: [macports-ports] branch master updated: ffmpeg: force gcc6 on PPC

> > > The issue in doing that is that C++ ports will possibly be build > inconsistently because macports-gcc6 will use the MacPorts-provided runtimes > from libgcc which are not compatible with the host's libstdc++ (used by > gcc42). > > If you want to use gcc6 for a full build of MacPorts on

Re: [macports-ports] branch master updated: ffmpeg: force gcc6 on PPC

> On Oct 20, 2017, at 7:39 PM, Ryan Schmidt wrote: > > I guess my question was: is there something unique about ffmpeg that makes it > require gcc6 on PowerPC, as opposed to one of the alternatives MacPorts would > choose, or is MacPorts choosing inappropriate alternatives for all ports on >

Re: [macports-ports] branch master updated: ffmpeg: force gcc6 on PPC

; >> https://github.com/macports/macports-ports/commit/e1f1b6b20678fed08e81f8a65ea0062f59a1f64c >> >> The following commit(s) were added to refs/heads/master by this push: >> >> new e1f1b6b ffmpeg: force gcc6 on PPC >> >> e1f1b6b is described belo

Re: https fetch error on older (<10.9) OSX releases due to rejected protocol

Please see I Ken On 2017-10-18, at 12:39 PM, Christopher Jones wrote: > Hi, > > I just just been looking into a build failure on older OS in one set of > python ports, pyXY-bleach, that is a dependency of a port I maintain. > > It looks lik

Re: [macports-ports] branch master updated: macports-notifier: update to more recent version

On 2017-10-16, at 12:41 PM, Ryan Schmidt wrote: > However you have an Xcode-based build system, and I'm not certain how best to > supply variables to it at build time. I added this port recently, with exactly that potential use in mind: $ port search mulle mulle-xcode-settings @1.2.5 (devel)

Re: perl module expert needed...

> On Oct 13, 2017, at 10:46 PM, Joshua Root wrote: > > > They're on CPAN: > > > > > What help do you need? > > - Josh I got bogged down in cpan2port and thought someone might have done lots of

perl module expert needed...

There is a rather fancy genome sequencing port submitted that is hung up on a few missing perl modules, if anyone can help Checking Required Perl Modules: XML::Compile::SOAP11 missing. Used for downloading sequence databases from RSAT XML::Compile::WSDL11

license question

I'm fixing up a submission for a piece of software called `profanity`. I think the license should be {GPL-3+ OpenSSLException} but I don't exactly know what OpenSSLException means. Do I have it right? Thanks. Ken Here is the blurb. = Profanity Copyright (C) 2012 - 2017 James Booth P

Re: [macports-ports] branch master updated: fish: fix build on Tiger

Thanks, will do. I was originally going to range it — then realized I was already at the bottom of the OS pile, and darwin 8 was as low as we can go :> It gives me such odd satisfaction to keep these old machines in current software … reduce, reuse, recycle, all that. Ken > On Oct 7, 2017, a

Re: virtual machine for 10.5 intel ?

Thanks for the ideas, Ken On 2017-10-03, at 12:49 AM, Mojca Miklavec wrote: > On 3 October 2017 at 05:01, Ken Cunningham wrote: >> if anyone would care to enlighten me on the best approach to making a VM for >> 10.5 intel, I would appreciate it. This is the only system I have t

virtual machine for 10.5 intel ?

if anyone would care to enlighten me on the best approach to making a VM for 10.5 intel, I would appreciate it. This is the only system I have that I can’t presently see a way to virtualize. Thanks, Ken

Re: buildbot force build a variant?

Ah, thanks very much for pointing out the ticket. I see now. I will stop trying things :> Ken On 2017-09-30, at 10:17 PM, Mojca Miklavec wrote: > > 30. sep. 2017 9:20 PM "Ken Cunningham" wrote: > I'd like to force a build of webkit2-gtk +quartz on 15 & 16

<    2   3   4   5   6   7   8   >