On Nov 12, 2015, at 6:01 AM, Mojca Miklavec wrote: > On Wed, Nov 11, 2015 at 12:15 PM, Ryan Schmidt wrote: >> >> Another option: It should be possible to write code to detect whether any >> files in a destroot use a C++ library, and if so, MacPorts could include the >> C++ library name in the archive filename, otherwise don't. At archive fetch >> time, MacPorts wouldn't know whether a port uses C++ or not, but it could >> try to fetch both filenames and use whichever one exists. > > Just one problem: let's assume that the package mirrors end up with a > package built against stdlibc++, but not in one built against libc++ > (presumably because there was a build error). How would the client > know whether to fetch the package without libc++ in the name (assuming > it doen't contain any C++ code) or whether to build one itself? This > would only work if all libstdc++ archives would contain libstdc++ in > the name and the files without any "name extension" would be > guaranteed to be portable.
Right, this would only work if the C++ library name is in every package name. And that would look silly for the majority of ports, which don't use C++ at all. So this idea of mine isn't working. > Plus one additional concern. There is a chance that we would have to > use (or at least deliberately decide to use) clang-3.4 as the default > compiler rather than gcc 4.2 on the system with libc++. Then users of > libc++/clang-3.4 would get code compiled with gcc 4.2 when fetching > binaries. I'm not saying this would necessarily lead to any problems, > but ... Since you're talking about gcc 4.2, you're talking about Snow Leopard and earlier. gcc 4.2 cannot be used with libc++. According to https://trac.macports.org/wiki/LibcxxOnOlderSystems, the bootstrapping procedure for those old systems does involve changing default_compilers so that clang-3.4 is used. So those steps would be done on user systems, and also on the buildbot builders. Doing it on the buildbot builders is a one-time thing that would be no problem. Once we get to the point of inviting users to switch to this, we would want to have this automated. For example, might offer a libc++ flavor of the MacPorts installer that would do it for the user. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
