On 29.04.2015 06:55 AM, Ryan Schmidt wrote: > > On Apr 28, 2015, at 11:39 PM, Mihai Moldovan wrote: > >> On 14.04.2015 07:44 AM, Mojca Miklavec wrote: >>> Could something like that be added to the compiler_blacklist PortGroup? I >>> believe that pure C++11 projects need consistent handling and it would be >>> very handy to allow a keyword like "compiler.c++11" or >>> "compiler.<something> c++11" to replace all of the logic above inside a >>> port. >> >> I've now added a new PortGroup called cxx11, which does the blacklisting >> and stdlib checking. > > Thanks. That was my first thought as well... but what happens next when ports > want to require C++14, or some other future standard? Should it be able to > accommodate that as well?
As far as I can tell, C++14 should be supported by libc++. It'll require clang >= 3.4, though. I'm not sure what makes more sense. Do we want a general "cxx" PortGroup with options for C++11, C++14, C++... or a new PortGroup for every standard? Probably the former? "A future standard" like C++1z... meh. "grep" for C++1z in this thread and you'll understand why that's inducing quite some headache. For a future standard, the pre-installed libc++ probably won't cut it, so we're running into big trouble. Best not to think about it for now... >> Extending compiler_blacklist_versions looked too complicated, as its logic >> is contained in multiple procs and one option_proc. > > Right, I would not add this to that portgroup; it is a different concept. Well, dunno. It's actually *using* compiler_blacklist_versions, so it's at least somewhat related. This said, yes, what cxx11 does is using the compiler_blacklist_versions API/the functionality, it doesn't care about implementation details, so it is decoupled from the PortGroup. Mihai
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
