On Nov 29, 2013, at 05:40, Peter Danecek wrote:
>
> On Nov 29, 2013, at 9:06 , Ryan Schmidt wrote:
>
>>> +# testing only
>>> +depends_run-append port:py${python.version}-nose \
>>> +port:py${python.version}-pep8 \
>>> +port:
Hi,
On 3 Dec 2013, at 11:43pm, Ryan Schmidt wrote:
>
> On Dec 3, 2013, at 16:23, Christopher Jones wrote:
>
>> Part of the problem, for me, is MacPorts insists on all OSX versions using
>> the same set of port versions. There is no way, I think, of having different
>> versions on different O
On Dec 3, 2013, at 16:23, Christopher Jones wrote:
> Part of the problem, for me, is MacPorts insists on all OSX versions using
> the same set of port versions. There is no way, I think, of having different
> versions on different OSX releases. Note this is quite different to say the
> Linux w
On Tue, Dec 03, 2013 at 03:55:08PM -0600, Ryan Schmidt wrote:
> First we would need to write more code in base that could identify
> when ports are installed with a different C++ runtime than that
> selected in macports.conf, and rebuild those ports. Users will not
> know they need to rebuild ports
Hi,
On 3 Dec 2013, at 9:55pm, Ryan Schmidt wrote:
>
> On Dec 3, 2013, at 13:48, Christopher Jones wrote:
>
>> For that last one, it is not necessary to have Apple make that decision.
>> macPorts could decide to release the current trunk, and force the use of
>> libc++ on systems older than O
On Dec 3, 2013, at 16:16, mk-macpo...@techno.ms wrote:
> when trying to set up a new port I ran into a strange thing with cmake:
> ---
> :info:configure -- Configuring done
> :info:configure CMake Error: The inter-target dependency graph contains the
> following strongly connected component (cyc
Hi,
when trying to set up a new port I ran into a strange thing with cmake:
---
:info:configure -- Configuring done
:info:configure CMake Error: The inter-target dependency graph contains the
following strongly connected component (cycle):
:info:configure "server" of type SHARED_LIBRARY
:info:c
On Dec 3, 2013, at 13:48, Christopher Jones wrote:
> For that last one, it is not necessary to have Apple make that decision.
> macPorts could decide to release the current trunk, and force the use of
> libc++ on systems older than OSX10.9. This of course would force all users to
> recompile a
Hi,
On 3 Dec 2013, at 8:13pm, Clemens Lang wrote:
> On Tue, Dec 03, 2013 at 07:48:48PM +, Christopher Jones wrote:
>> For that last one, it is not necessary to have Apple make that
>> decision. macPorts could decide to release the current trunk, and
>> force the use of libc++ on systems olde
On Tue, Dec 03, 2013 at 07:48:48PM +, Christopher Jones wrote:
> For that last one, it is not necessary to have Apple make that
> decision. macPorts could decide to release the current trunk, and
> force the use of libc++ on systems older than OSX10.9. This of course
> would force all users to
On Tue, Dec 03, 2013 at 01:59:35PM -0500, Eric Gallager wrote:
> What about using the libcxx and libcxxabi ports for libc++? Is there
> any way to make that work?
Only if we rebuilt all ports against libcxx/libcxxabi. We could do that,
but we could also just rebuild everything against the host lib
Hi,
> Under the constraints we have I think its the best solution possible.
> Alternatives would be
>
> - Mark the port as broken on systems < darwin13 :(
> - Build a private copy of all dependencies of rethinkdb against
> macports libstdc++. Since that includes boost and a couple of other
>
What about using the libcxx and libcxxabi ports for libc++? Is there any
way to make that work?
On Tue, Dec 3, 2013 at 1:38 PM, Clemens Lang wrote:
> On Tue, Dec 03, 2013 at 05:00:25PM +, Christopher Jones wrote:
> > Is this really a good idea though. My recollection is, whilst not as
> > b
On Tue, Dec 03, 2013 at 05:00:25PM +, Christopher Jones wrote:
> Is this really a good idea though. My recollection is, whilst not as
> bad as mixing libc++ and libstdc++ runtimes, mixing the two different
> libstd++ runtimes can still lead to problems…. ?
Under the constraints we have I think
Hi,
> To follow up: the ML buildbot just succeeded building rethinkdb using
> FSF GCC 4.8 (obviously using MacPorts libstdc++). I guess the binaries
> will now use both
> - /opt/local/lib/libstdc++.dylib and
> - /usr/lib/libstdc++.dylib,
> but I suppose that will cause a lot less problems than m
On Tue, Dec 03, 2013 at 03:09:10PM +0100, Clemens Lang wrote:
> does anybody know how I can compile C++11 code on Mountain Lion and
> lower without using libc++?
>
> The problem I face is that rethinkdb uses std::move (and probably other
> features) from C++11. To do this, it checks for the clang
Hi,
I am not an expert, but based on the discussion in
https://trac.macports.org/ticket/39975
my understanding is there is no easy way to enable c++11 on systems
older than 10.9 using the current MacPorts release. You need to use the
libc++ runtime by default everywhere, not, libstdc++, and t
Hi,
does anybody know how I can compile C++11 code on Mountain Lion and
lower without using libc++?
The problem I face is that rethinkdb uses std::move (and probably other
features) from C++11. To do this, it checks for the clang compiler and
passes -stdlib=libc++ in CXXFLAGS if it detects clang
18 matches
Mail list logo
