On Jan 17, 2013, at 11:24, Clemens Lang <c...@macports.org> wrote: > On Wed, Jan 16, 2013 at 08:06:15PM -0800, Jeremy Huddleston Sequoia wrote: >> We may need to figure out a way to deal with this ABI compatibility >> issue in base … is there currently a way to query what >> configure.compiler was for another installed port? > > Are you saying there is no way to have clang and gcc (from both Xcode > and MacPorts) generate ABI-compatible binaries (compatible with each > other, but also with the host's ABI)?
Not at all. > If that is true getting this right > would be a major effort. Wouldn't that also mean we had to avoid linking > against any OS-provided (C++?) library at any cost? No. I'm saying that if a library uses libc++ and exports C++ objects, then its client needs to use libc++ as well. Similarly, if a library uses libstdc++ and exports C++ objects, then its client needs to use libstdc++ as well. > On Wed, Jan 16, 2013 at 11:44:17PM -0600, Ryan Schmidt wrote: >> There's a lot of information available at install time that's not >> recorded anywhere that might be useful later. Compiler used, Xcode >> version, OS X version and build number, number of CPUs, amount of >> memory, number of build jobs... We could record information like this, >> and provide a command to easily retrieve all the information, and ask >> users to include it with bug reports. But it would be a bit of work to >> implement, for a hypothetical future benefit. :/ > > The hypothetical future benefit is what makes me think whether > implementing this is time well spent. Most of that information can also > be generated on the fly (e.g., using a port report-bug command?) instead > of storing this in the package. No, because the machine used to build a project may not be the one installing it. > There's other information we might want to record, though: E.g. the list > of packages (and their versions) installed when a package was built > might be useful. True, but that may be more data than we're willing to store. > On Wed, Jan 16, 2013 at 10:42:04PM -0800, Jeremy Huddleston Sequoia wrote: >> This sounds like a good GSOC project. > > I think we have other areas in base where time could be spent with more > helpful outcome (e.g., dependency management and computation, > pre-computing all actions instead of doing them one-by-one, designing a > proper interface between port1.0 and macports1.0 (like there apparently > used to be))). Yes, there is plenty of room for improvement. --Jeremy _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users