On Apr 15, 2015, at 3:45 AM, Mojca Miklavec wrote: > (b) I've been suggesting for a long time already that we should set up > three new buildbots to build packages against libc++ on 10.6-10.8. The > lack of a buildbot is a showstopper for me, preventing me from > globally switching to libc++ (on an old OS). And as more and more > software is now shifting to C++11, the situation will just get much > worse with time. If we start supporting libc++ in such a way that: > - buildbots will build packages against libc++ > - users will be able to download a pre-configured MacPorts dmg > (including the proper configuration) > then it will no longer be a problem for users to switch to libc++. Of
And I think I've replied a couple times that, assuming you're wanting binary packages from these new buildbot builders to be uploaded to packages.macports.org, then before we can set that up, MacPorts base needs to be enhanced so that there is differentiation in the package filenames for the C++ library being used (e.g. add "libc++" or "libstdc++" to the package filename). But not all ports need that differentiation (i.e. those that don't use C++ don't need it). We can either add the differentiation to all package filenames, understanding that this will result in unnecessary duplication of files server-side, or we can try to find a way to identify which ports need the differentiation. Certainly noarch ports don't need it, but other ports are trickier. It's easy enough when creating the package (e.g. use `otool -L` to see if any files in the destroot link with /usr/lib/libc++.1.dylib or /usr/lib/libstdc++.6.dylib) but how would it work when trying to download a package to inst all? One solution would be for MacPorts to try two package filenames: look for the file with the C++ library differentiation, and if not found, then look again without it. That's not ideal but could work. Another option is that the port must use some new keyword to indicate that it uses or does not use C++, but it would be very easy for a portfile author to forget to do this or to do it wrong. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
