Re: Is it time for a libc_fixes library yet?

On Jul 4, 2017, at 09:12, Ken Cunningham wrote: >> Your library offers multiple functions... getline, strndup, etc. >> >> What happens if a software package provides, for example, a compatibility >> implementation of getline but not strndup? Can your library be used in this >> case or will tha

Re: should depends_lib really mean depends_lib-append ??

On Jul 4, 2017, at 19:53, Ken Cunningham wrote: > This feels like something that has likely been discussed before > > Now that PortGroups have important depend_lib-append, etc, in them, we don't > want Portfiles to reset these by accidentally using depends_lib and trashing > them, and yet

Re: Buildbot now fails to build wine dependencies

I did notice one bug with my initial patch; dependencies.tcl needs to print "" instead of nothing when there are no active variants. Not hard to fix. - Josh

Re: Buildbot now fails to build wine dependencies

On 2017-7-5 09:02 , Clemens Lang wrote: Hey, On Wed, Jul 05, 2017 at 07:18:59AM +1000, Joshua Root wrote: So really we need two pieces of information: the canonical_active_variants to use with the fail cache, and the variants that should be actually be requested. Yes. How about this? Clos

should depends_lib really mean depends_lib-append ??

This feels like something that has likely been discussed before Now that PortGroups have important depend_lib-append, etc, in them, we don't want Portfiles to reset these by accidentally using depends_lib and trashing them, and yet this is easily done: See

Re: Build Machine(s) & Java

On Jul 3, 2017, at 13:29, Mohamed Issa wrote: > Do the build machines have Java installed? As it stands right now, any > changes to the Bazel port (or others like it) will cause build failures. So > I'm wondering what can be done to avoid that. I haven't installed any separate Java on the buil

Re: Buildbot now fails to build wine dependencies

Hey, On Wed, Jul 05, 2017 at 07:18:59AM +1000, Joshua Root wrote: > So really we need two pieces of information: the > canonical_active_variants to use with the fail cache, and the variants > that should be actually be requested. Yes. > How about this? Close, but not fully there, since neither

Re: Buildbot now fails to build wine dependencies

Hey, On Tue, Jul 04, 2017 at 10:00:16PM +0200, Clemens Lang wrote: > > I am attaching a patch to only print active variants that are not > > enabled by default (or disabled default variants). To me the result > > looks like what we want to have: > > > > $ tools/dependencies.tcl wine | grep -E 'gl

Re: Buildbot now fails to build wine dependencies

On 2017-7-5 06:00 , Clemens Lang wrote: Hi, On Tue, Jul 04, 2017 at 04:23:13PM +0200, Rainer Müller wrote: I still don't understand why we pass *default* variants to dependencies at all. As I see it, the problem would go away if we would not request default variants explicitly... @Clemens, as

Re: Dropping recommendation to install system headers / command line tools

On Jul 04 03:10:38, ryandes...@macports.org wrote: > Last I checked, graphite2 would not build if CLTools were not installed: > https://trac.macports.org/ticket/49325 On a related note: a comment in this ticket says that xcode-select -p does not show whether you have the command l

Re: Buildbot now fails to build wine dependencies

Hi, On Tue, Jul 04, 2017 at 04:23:13PM +0200, Rainer Müller wrote: > I still don't understand why we pass *default* variants to > dependencies at all. As I see it, the problem would go away if we > would not request default variants explicitly... > > @Clemens, > as you originally added this to mp

Re: Is it time for a libc_fixes library yet?

> > > Perfect would be if I just wrote it into the clang code directly. I am almost > to the point where I could do that, actually. I know where it would go, I > think. > Well, another fairly easy option would be to bring down the newer libc from 10.7 and port it back into 10.4 to 10.6, with

Re: Buildbot now fails to build wine dependencies

On 2017-07-04 07:11, Mojca Miklavec wrote: > One question: does a clean installation of "gtk3 +quartz" still work > now? It depends on both glib2 and cairo, so I would expect problems or > at least some weird non-determinism. I see no problem with that. Only the explicitly specified +quartz is pas

Re: Is it time for a libc_fixes library yet?

> > Your library offers multiple functions... getline, strndup, etc. > > What happens if a software package provides, for example, a compatibility > implementation of getline but not strndup? Can your library be used in this > case or will that also "cause trouble", as you put it above? Very

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

Thanks -- these kinds of nuances are tricky. Will alter that and update. Ken On 2017-07-04, at 1:29 AM, Ryan Schmidt wrote: > >> On Jul 3, 2017, at 14:46, Marius Schamschula wrote: >> >> Marius Schamschula (Schamschula) pushed a commit to branch master >> in repository macports-ports. >>

Re: [macports-base] 01/02: portconfigure: Put a space between -isysroot and the path

Ugg. Done. To github.com:macports/macports-base.git 677dda56..440fc6c3 master -> master We may need to hack around this based on compiler version if clang ever becomes stricter here, but hopefully that won't become the case. > On Jul 4, 2017, at 01:17, Ryan Schmidt wrote: > > >> On Jul

Re: Dropping recommendation to install system headers / command line tools

> On Jul 4, 2017, at 01:10, Ryan Schmidt wrote: > > > On Jul 3, 2017, at 23:21, Jeremy Huddleston Sequoia wrote: > >> base currently outputs a warning if system headers are not installed. I >> modified the warning a few months ago when I improved our support for >> building against SDKs, an

Re: Is it time for a libc_fixes library yet?

On Jul 3, 2017, at 12:07, Ken Cunningham wrote: > As we have said before (last year) this library could be automatically linked > in by base. That would cause trouble with the ports that have already patched > in a def, tho. Your library offers multiple functions... getline, strndup, etc. Wha

Re: [macports-ports] branch master updated: snowleopardfixes: new port to deal with missing functions in Snow Leopard

> On Jul 3, 2017, at 14:46, Marius Schamschula wrote: > > Marius Schamschula (Schamschula) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/3efea307091e06b1176c8e9c1f771dd1efdea179 > >

Re: [macports-ports] 01/02: New PortGroup snowleopard_fixes

> On Jul 3, 2017, at 14:59, Marius Schamschula wrote: > > Marius Schamschula (Schamschula) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/273304d02313f76225a1d5db7be911bf5e2b34f6 > >

Re: [macports-base] 01/02: portconfigure: Put a space between -isysroot and the path

> On Jul 3, 2017, at 23:04, Jeremy Huddleston Sequoia > wrote: > > Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master > in repository macports-base. > > https://github.com/macports/macports-base/commit/ef5ecfee6f4324e1b76109e01dd96184221d312f >

Re: Dropping recommendation to install system headers / command line tools

On Jul 3, 2017, at 23:21, Jeremy Huddleston Sequoia wrote: > base currently outputs a warning if system headers are not installed. I > modified the warning a few months ago when I improved our support for > building against SDKs, and it now reads: > > Warning: System headers do not appear t