On 2018-02-28 08:52, Jan Stary wrote: > The ticket is closed, so I will continue here. > >> Actually it's not specific to the universal variant. Rather, the problem >> is that the port is not UsingTheRightCompiler. > > mandoc's ./configure sets CC to whatever make(1) thinks CC is: > CC=`printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -` > Why exactly is it "not the right compiler"?
As env -i clears the environment, how is this supposed to work at all? This does not respect CC in the environment, which is what MacPorts usually does. $ export CC=foo $ printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf - cc > Maybe I don't get the whole premise: > > If not instructed otherwise, most software builds C code using "cc" or > "gcc". But "/usr/bin/cc" and "/usr/bin/gcc" are not specific > compilers; they're symlinks to some suitable default compiler, but it > varies based on Xcode version. Users might also have created > a "/opt/local/bin/gcc" symlink, pointing to any installed compiler, by > using "port select --set gcc". So we cannot rely on "cc" oc "gcc" > being any particular compiler. > > Yes, we cannot, and that's OK because we should not, _by_default_. > This is a UNIX system compiling C code. Call 'cc'. Duh. > > It's true that /usr/bin/cc is a symlink to some suitable default compiler. > So call that, thus calling a suitable default compiler, _by_default_. You are already assuming that 'cc' is /usr/bin/cc. If anyone has a /opt/local/bin/cc, it might be a different compiler. In general, we do not want to use what the user selected as their preferred compiler, but what MacPorts selected to compile this port. This is more important for binary names such as cpp or c++, which are actually modified by 'port select gcc'. > Yes, there are ports that do need to call some particular compiler, > but it's those ports' job then to find and use that. Unfortunately, it is not that easy. Ports need to respect what is set in the environment. Using the right compiler is especially important when compiling C++, as that also controls which standard library will be linked. Historically, Apple used to ship gcc, llvm-gcc, and clang and on some macOS version. >> I had my MacPorts configured to error out if `cc` is used >> using the method described at UsingTheRightCompiler#testing. > > Why would you do that? > > Mandoc is extremely portable. I have yet to see a UNIX system where > it does not build. Except here: of course it "breaks" if you explicitly > make it impossible to run 'cc', which is the right compiler. This setup is a good idea for developers to catch ports that are not respecting the environment variables for compiler selection. > BTW, this is how configure.cc is described in the guide: > > configure.cc > Set CC compiler flags for selecting a C compiler. > Default: ??? > Example: > > "compiler flags for selecting a compiler"? Looks like an old copy & paste mistake to me. I committed a fix. [1] Ryan was even faster to notice than me typing this mail. :-) >> Perhaps the portfile code that set `CC` >> that was removed in [14f7de9e9ad521cce6389678675706e8593b9834/macports- >> ports] was needed after all. > > It is only "needed" if you make it artificially impossible > to call 'cc' (or whatever the port ./configures to be CC). > > So: because ports must not call 'cc' on your system, > let's complicate the mandoc Portfile for everyone. Build systems are supposed to follow CC in the environment. The whole point of options like configure.cc is that they are respected when building the port. As an alternative to pass compiler in environment variables would be generating wrapper scripts that use the right compiler as selected by MacPorts. This is the way other projects like Fink do it. Then the usual names cc/gcc/clang/... will always end up at the intended binary by putting them to the front of PATH. However, this is a long-standing issue and I am not aware anyone was working on this. Therefore, build systems still need to be patched to honor CC from the environment. Rainer [1] https://github.com/macports/macports-guide/commit/5a6f3a7f7ca016f22f8ac7aa0f497860680302de