Tiger Virtual Machine on VirtualBox

I know some of you are interested in such things, at times… debugging MacPorts, trying out a port, etc. A Tiger VM more or less works, with a few touchy parts that may or may not improve over time, on the current version of VirtualBox.

Re: [macports-ports] branch master updated: mosh: 1.3.0, switch to CommonCrypto

so this sorta gets back to your question about support for older systems, and is a pretty typical example of same. sounds like you could write up an openssl variant for it, default to that variant on suitable systems, and nobody would likely complain about that. But you might have to do it and

Re: GSoC Proposal

Have you seen how homebrew does this? I imagine he means something like that: Every submission has to be submitted to the 10.10 - 10.12 bots first, to see if it builds. Every submission is suggested / required to have at least a minimal test `myport --version` to make sure something actually

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

On 2017-03-28, at 2:18 AM, Mojca Miklavec wrote: > > It makes absolutely no sense that I try to use a compiler that has > never been designed or tested to produce binaries for PPC. It had always been a design goal for llvm to produce workable PPC code, but although close (lots of things do

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

It's been a few months since I went down this rabbit hole, but IIRC, it worked a little better to build clang on ppc directly. 10.5 intel fails to build PPC correctly due to the runtime library issues you stumbled across. The highest i have been able to go is clang-3.6 on ppc so far (building it

anyone in a mood to reject this hedgewars submission?

I’ve been trying to make macports more relevant to average users by bringing all the top ‘net games in. Some of them are a bit messy. Hedgewars is one of the top 10. It could have a better build script. It’s a game, though. The mods I made make it work correctly on Snow Leopard through Sierra,

Re: Removal of llvm-3.5 and llvm-3.6

roken ghc. > > On Sun, Jan 29, 2017 at 2:57 PM, Brandon Allbery <allber...@gmail.com> > wrote: > >> >> On Sun, Jan 29, 2017 at 2:51 PM, Ken Cunningham < >> ken.cunningham.web...@gmail.com> wrote: >> >>> > GHC still uses 3.5. I want to change that,

Re: Handling C++11

Well, the entire c++ library on the buildbot would have to be rebuilt against libgcc's libstdc++ for this to work -- all of octave's deps and deps of deps would need to be built the same as octave, of course, and so everything else too. The whole machine has to be configured the same way (which is

Re: Handling C++11

Octave builds and runs great on older systems right now when they are upgraded to libc++ per the current instructions. $ port -v installed octave The following ports are currently installed: octave @4.2.0_1+accelerate+app+docs+fltk+gfortran+graphicsmagick+qt4+sound platform='darwin 10'

Re: installing an older version of a port in the github era -- an answer

So, this turns out to be a lot easier than I originally thought it would be, and probably is no more difficult than svn was. This may not be the most efficient way of doing it, but it's fairly easy to understand, and it works for me. Here are (perhaps too many) steps regarding how to do it.

review request - glbinding - new C++ bindings for OpenGL

glbinding is a c++ binding for OpenGL that some OpenGL ports, eg widelands, are using for debugging at present and moving towards for general use. this is the current version as of today. appears to work without issues. All examples build and work correctly. would be needed for the devel+debug

Re: port requires c++1y -> use cxx11 portgroup?

> > > The main thing you get is that, without that portgroup, it will attempt to > build on older OS X and fail. It also supports the > https://trac.macports.org/wiki/LibcxxOnOlderSystems > workflow for those > users who have done it to

port requires c++1y -> use cxx11 portgroup?

The pingus port I put up last night (and which Ryan so kindly fixed while I was sleeping for a missing dependency and an error on case-sensitive file systems - gotta love those buildbots for finding these things - and thanks for that) requires the c++1y standard to build. Builds will fail on

Re: ports using scons build system

> It seems to me that with scons, it's up to each project to write their build > system however they want, so there isn't much standardization with regard to > how the compiler and flags are specified. > OK. Thanks, everyone. - Ken

ports using scons build system

Would anyone like to point me towards a port that uses the scons build system properly in Macports? I have an idea how to go about importing all the build environment variables, but I don’t want to go to all the trouble only to find out there is a proper, sanctioned method that I’ll then have

<    3   4   5   6   7   8