svn commit: r383466 - in head/x11-toolkits/wxgtk30: . files

Dmitry Marakasov amdmi3 at amdmi3.ru
Fri Apr 10 19:15:36 UTC 2015


* Alexey Dokuchaev (danfe at FreeBSD.org) wrote:

> > >>   x11-toolkits/wxgtk30: Support c++11 over c++0x, plus DragonFly
> > >>   
> > >>   The wxgtk30 port will use TR1 headers if the capability is detected.
> > >>   These TR1 functions were experimental and not included in the same form
> > >>   in the final c++11 standard.  This patch forcibly disabled TR1 support,
> > >>   which requires the explicit setting of -std=c++11 in CXXFLAGS>
> > >>   
> > >>   A private "exp-run" was performed, all 62 ports dependent on wxgtk2
> > >>   successfully built before and after after the patch was applied on two
> > >>   separate runs (FreeBSD 10 amd64 jail).
> > > 
> > > You should test on all supported FreeBSD branches and all tier1
> > > architectures. You've broken (all?) dependent ports on 8.x and 9.x.
> > 
> > I had just finished a bulk build on DragonFly that uses gcc 4.7 and I
> > see 15 failures through a rough grep log.  I think it's caused by older
> > clang/gcc using an older c++ std, while the latest versions are on
> > -std=c++11.  Adding this cxxflag will likely fix most of them (success
> > with wxguitar, sooperlooper failed elsewhere)
> 
> On the other hand, many of these dependent ports actually do not require
> dreaded c++11 (or c++0x) support.  It would be very unfortunate to force
> it on all of them just because wxgtk30 guys do not know how to develop
> software [1].  Can we bring wxgtk30 back to sanity, please?
> 
> ./danfe
> 
> [1] Forcing c++11 on a popular GUI toolkit in 2015 is bad beyond evil.

It turns out that wxgtk is really tied to c++11: one of my ports fail with

/usr/local/include/wx-3.0/wx/strvararg.h:350:13: error: 'is_enum' in namespace 'std' does not name a type
     typedef std::is_enum<T> is_enum;

is_enum is c++11 thing: http://en.cppreference.com/w/cpp/types/is_enum

so there's no problem with the port and all claims should be
redirected to upstream.

There is a problem with c++11 incompatible consumers though, and I
see at least 2 such ports now.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru      http://amdmi3.ru


More information about the svn-ports-all mailing list