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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

ps://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 below >> >>

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

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

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

Re: Addressing Port submission failures on Travis

> On Dec 20, 2017, at 1:04 AM, Mojca Miklavec <mo...@macports.org> 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,

Re: Instructions for creating patches

copy, there is only one repo. > > unless they have credentials, they will not be able to push changes > back to the master/origin even if they choose not to branch and work > on master > > it should say something like build your branch Portfile, port lint > blah blah blah

Re: Qt5 port group

> On May 10, 2018, at 5:44 PM, Marcus Calhoun-Lopez > wrote: > I am certainly open to suggestions to how to improve the situation. > The only thing that comes to mind is having qt ports be able select a qt version variant that is mutually exclusive to the other qt

please take a second to check out this versioning plan for the devel versions of LibreCAD

Is this the smartest way to version these, or is there a better method to use? Thx, Ken

Re: [macports-ports] branch master updated: py-protobuf3: fix build on older systems

On 2018-05-25, at 8:38 AM, Ryan Schmidt wrote: > > On May 24, 2018, at 23:15, Ken wrote: > > > If this is supposed to help 10.6... > > >> +@@ -197,6 +197,8 @@ >> + v = float('.'.join(v.split('.')[:2])) >> + if v >= 10.12: >> + extra_compile_args.append('-std=c++11') >>

gcc5 potential fix

If anyone else can test > and see if it works for them as well, we can commit this fix for gcc5. Ken

Re: regex for finding all ports using the cxx11 1.0 PG and changing them en-masse to the cxx11 1.1 PG

Thanks for that, guys. > On May 18, 2018, at 2:18 PM, Marius Schamschula >> wrote: >> >> Drat. Autocorrect strikes again. The regex should be: >> >> >>

regex for finding all ports using the cxx11 1.0 PG and changing them en-masse to the cxx11 1.1 PG

It seems that there is no reason for a port to still be in the cxx11 1.0 PG. I stumble across them from time to time still. Do any of the regex-masters have an easy way to find all the cxx11 1.0 PG entries and change them all to 1.1 PG? Thanks, Ken

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 25, 2018, at 12:05 PM, Ryan Schmidt wrote: > > It's "broken" in that it links with libstdc++, even though MacPorts believes > it will link with libc++ on your system. The rev-upgrade code in previous > versions of MacPorts did not check for this kind of

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 26, 2018, at 9:49 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > > > On May 26, 2018, at 11:48, Ken Cunningham wrote: > >> Well I think you did the cmake finaggeling last time Not sure you could >> find a better way, but I wait to see..

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 26, 2018, at 12:27 PM, Ryan Schmidt wrote: > > The error occurs when there is a mismatch between which C++ standard library > a port says it uses (by setting configure.cxx_stdlib, or by leaving it set to > its default value) and which C++ standard library

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 26, 2018, at 9:40 AM, Ryan Schmidt wrote: > > Unfortunately, we have no way to tell Xcode to use one of our compilers. I > believe we need to create some kind of Xcode-specific file to tell it about > each of our compilers, then update the xcode portgroup

Re: MacPorts 2.5.0-beta1 now available for testing

Well I think you did the cmake finaggeling last time Not sure you could find a better way, but I wait to see... K Sent from my iPhone > On May 26, 2018, at 9:40 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > >> On May 26, 2018, at 11:15, Ken Cunningham wrote: >&

multiple ports with stdlibc++ mismatches (all on 10.13)...

pbzip2 is using libstdc++ (this installation is configured to use libc++) dylibbundler is using libstdc++ (this installation is configured to use libc++) lzma is using libstdc++ (this installation is configured to use libc++) SuiteSparse is using libstdc++ (this installation is configured to use

Re: understanding gcc's header choices and how to fix them

> On May 29, 2018, at 11:46 AM, Ryan Schmidt wrote: > > > On May 28, 2018, at 11:49, Joshua Root wrote: > >> On 2018-5-28 13:58 , Ken Cunningham wrote: >> Not 100% certain but I would think this is telling it where to install >> its headers (as opposed to

Re: multiple ports with stdlibc++ mismatches (all on 10.13)...

On 2018-05-31, at 5:53 PM, Joshua Root wrote: > Those that do provide or use C++ libraries need to be fixed to use the > C++ stdlib that they are being told to use. And indeed, that is the exact point of having this test and check ... to find and fix these broken ports. Ken

libjpeg-turbo vs jpeg

I have a new game port done, Endless Sky >. It requires "libjpeg-turbo" rather than “jpeg" and so I came across the mess with the conflict with jpeg:

understanding gcc's header choices and how to fix them

There have been some improvements to the headers for libgcc to better support the math issues found on 10.5 and 10.6 (the missing llrintf, etc that lead to all the std::math functions being disabled). These missing functions cause a lot of headaches building c++ software on these older systems.

Re: multiple ports with stdlibc++ mismatches (all on 10.13)...

On 2018-05-30, at 11:04 PM, Joshua Root wrote: > On 2018-5-31 15:39 , Ken Cunningham wrote: >> gcc5 is using libstdc++ (this installation is configured to use libc++) >> gcc6 is using libstdc++ (this installation is configured to use libc++) >> gcc7 is using libstdc

status of the webkit2-gtk-* ports

Yan12125 and I have been working on the webkit2-gtk-* ports, and now the webkit2-gtk port is at the latest stable release, and the webkit2-gtk-devel port is at the latest development release. This allows the latest and one-from latest versions of epiphany to build and function. However I need

Re: Ports still using protobuf-cpp

On 10.6.8, this has broken all the ports that used protobuf-cpp, as predicted, due to the thread_local thing. Normal ports can be fixed up by adding this (eg mosh): # force protobuf3-cpp into the no_threadlocal mode if { ${os.platform} eq "darwin" && ${os.major} < 11 } {

Re: Ports still using protobuf-cpp

hu, 26 Apr 2018 09:18:47 -0700 Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: >> On 10.6.8, this has broken all the ports that used protobuf-cpp, as >> predicted, due to the thread_local thing. > > Ah, I'd misinterpreted. I thought in the "mosh" discu

Re: Binary packages not rebuilding against updated libraries

On 2018-04-26, at 8:09 AM, Joshua Root wrote: > Detecting this situation and rebuilding locally is automatic. Actually > increasing the revision of the dependents so updated archives are made > available is not. There's next years GSOC project for you :> Ken

Re: Binary packages not rebuilding against updated libraries

> On Apr 25, 2018, at 22:48, Jan Stary wrote: > > The packages that were installed before get rebuilt > with port rev-upgrade, automatically, > without anyone touching their Portfile. Well the idea is that download a prebuilt packaged binary, not revupgrade and build them all

Re: Request for discussion: lowering the backlog of old Trac tickets.

At one point about two years ago I also suggested closing all tickets more than about six months old, for the exact same reasons. So I'm on board. There _is_ a vast storehouse of practical information in MacPorts trac. Whenever I get a build error I go there first, often before Google. But

Re: Strange behaviour of trace mode in MacPorts 2.4.3 / 10.13

It’s almost _always_ pkg-config that is responsible for these wacky errors. That has bit me dozens of times, including a week ago. Wasted hours. We should probably just make pkg-config a default dependency for _every_ build and save everyone a pile of heartburn. Ken > On Apr 29, 2018, at

Re: Gsoc 18 Project | Collect build statistics

> On Apr 28, 2018, at 5:06 PM, Vishnu wrote: > > am i supposed to install port tclsh ? > > There's no port named tclsh. > you should have it /opt/local/bin/port-tclsh but your path is probably calling /usr/bin/tclsh Ken

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

Re: set merger_configure_env question

> On Dec 30, 2017, at 11:00 AM, Marcus Calhoun-Lopez <mcalh...@macports.org> > wrote: > > On Sat, Dec 30, 2017 at 11:36 AM, Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: >> configure.env-append libIDL_cv_long_long_format=ll > I would respectfully

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

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

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

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

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

something is wrong with www.macports.org webpage

hacked? misconfigures?

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,

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

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

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 >

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

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 <ryandes...@macports.org> wrote: > >> On Feb 4, 2018, at 18:01, Ken Cunningham wrote: >> >>>

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 <ryandes...@macports.org> wrote: > > >> On Feb 4, 2018, at 18:09, Ken Cunningham wrote: >> >>> On Feb 4, 2018, at 7:03 PM, Ry

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

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

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

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

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

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

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

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: port "gohome" --> "A keychain cannot be found."

> On Jan 2, 2018, at 1:14 PM, Rainer Müller <rai...@macports.org> 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

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.

protobuf3-cpp now requires -std=c++11

It appears this latest update to protobuf3-cpp now requires c++11 enabled to build anything. AFAICT, every port that uses protobuf3-cpp (ostinato, libphonenumber-cpp, mosh, etc, etc, etc) will all have to be reworked to kick them into c++11 builds. This requires more than just: PortGroup

llvm-7.0 and clang-7.0 on SnowLeopard are working with minor adjustments

With minor modifications to the patches and Portfile, both of these install and appear to be working fine. I'll set up a PR for the minor changes needed. -- Ken $ port -v installed llvm-7.0 The following ports are currently installed: llvm-7.0 @7.0.0rc2_0 (active) platform='darwin 10'

viewing code while respecting defines

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) has a lot of #defines in it to modify code paths for various OS versions. It can get pretty mind-bending to try to

Re: feature request: a method to try a Port build against the buildbot farm BEFORE it is committed to the main macports repository

On 2018-07-08, at 7:59 AM, Rainer Müller wrote: > > There was a lengthy thread on this in April: > https://lists.macports.org/pipermail/macports-dev/2018-April/038023.html > > Rainer I had thought that one was mostly about using GitHub (which does CI on only a couple of systems). I'll go

feature request: a method to try a Port build against the buildbot farm BEFORE it is committed to the main macports repository

It would be very helpful to be able to try a Portfile build against the buildbot farm before committing it. We would get lots of info regarding breakage before the damage is done that way. I can see that at present there is no easy method to tweak the system to allow this. Ken

Re: request for port create command, to build a portfile from a URL

On 2018-03-06, at 7:19 AM, Joshua Root wrote: > > There's a fairly basic tool called portfile-gen in contrib. Improvements > are certainly welcome. That is indeed a step towards what I was thinking of. I'll look at this. Ken

Re: Changing default cxx_stdlib to libc++

> On Mar 11, 2018, at 06:06, db wrote: > >> On 11 Mar 2018, at 02:47, "Kenneth F. Cunningham" >> wrote: >>> On 2018-03-10, at 12:23 PM, db wrote: >>> Except for building from source for minor versions and revbumps, especially >>> large

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

Re: [macports-ports] branch master updated: atf: update to 0.21

> On Mar 8, 2018, at 08:21, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On Mar 8, 2018, at 10:13, Ken Cunningham wrote: >> >>> On Mar 7, 2018, at 11:56 PM, Ryan Schmidt wrote: >>> >>>> On Mar 2, 2018, at 01:58, Ken

Re: Changing default cxx_stdlib to libc++

Thank God. 10.6.8, agree. I use clang 3.9 as a good balance between capability and compatability, but might as well sort out how to use clang 5 as that is more consistent w older systems, and I nearly have thread_local working there on 10.6 Ken Sent from my iPhone > On Mar 8, 2018, at

Re: Changing default cxx_stdlib to libc++

On 2018-03-08, at 4:27 PM, Ryan Schmidt wrote: > How will users upgrade from libstdc++ to libc++? What subset of the > instructions on the LibcxxOnOlderSystems page would they have to follow? What > if they don't do that and stay on libstdc++? We do have to ponder the bootstrap toolchain

Re: [macports-ports] branch master updated: atf: update to 0.21

> On Mar 7, 2018, at 11:56 PM, Ryan Schmidt wrote: > > > On Mar 2, 2018, at 01:58, Ken wrote: > >> +github.setupjmmv atf 0.21 >> + >> +# github.tarball_from downloads or releases does not set the mastersite >> correctly >> +master_sites >>

Re: Changing default cxx_stdlib to libc++

> On Mar 9, 2018, at 06:18, Joshua Root wrote: > > We may have to create some bootstrap versions of toolchain ports in > order to achieve this, so that they can be automatically installed as > dependencies with no manual intervention. Maybe we could just force clang 3.4 to

Re: request for port create command, to build a portfile from a URL

On 2018-03-06, at 7:22 AM, G Alexander wrote: > I like the auto calculate hashes > > For grabbing something from url sounds like having a lot of switches, > > for archive type and depedencies > I was kinda hoping that the archive type might be figured out from the tail of the URL. All the

request for port create command, to build a portfile from a URL

It would be nice to have a command like port create URL that would download the URL, calc the checksums for it, and build a basic Portfile for it. It could ask for a category to use for the Port. In a more advance version, it could extract the URL and do some quick analysis on it. if

request for port peg command, to lock down a port at the currently installed version

It is fairly common for users to find an update to a port that won't build on their system for some reason. It would be nice to have a simple command, like port peg PORTNAME that stops the port from attempting to update until the peg is released. Such a command does exist in other package

Re: CI system for PR builds

> On Apr 8, 2018, at 03:49, Rainer Müller wrote: > > We need to stop investing > so much effort into legacy systems. True. Making current software build on ancient compliers is a waste of effort. Finish the plan to push all those systems to libc++, put forward a modern

Re: CI system for PR builds

On 2018-04-08, at 6:46 AM, Ryan Schmidt wrote: > Yes, I know you like to build your legacy MacPorts installs with a different > copy of curl. And yes, we have a ticket tracking that issue as well. It's my nature. I just can't understand why people would spend years working around a problem

Re: Releasing 2.4.3

On 2018-04-10, at 12:02 PM, Ryan Schmidt wrote: > > On Apr 10, 2018, at 13:55, Ken Cunningham wrote: > Mixing libc++ and libstdc++ results in a link failure. Mixing old libstdc++ > and new libstdc++ did not previously result in a link failure; it resulted in > a runt

Re: Build Failure on ports-10.6_x86_64_legacy: libpsl, mosquitto

You're not expected to fix it. It would be nice perhaps to make a ticket about it if you like, so someone who uses that OS cersion might dig in. Best, Ken > On Apr 4, 2018, at 07:36, Andrew Moore wrote: > > If I’m reading correctly the attached report from

<    1   2   3   4   5   6   7   8   >