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. 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 ... Mojca _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
