Hi Werner,
On Sep 8, 2018, at 09:08, Werner LEMBERG wrote: > macports newbie here :-) Welcome! > I'm running a Lion box and I'm running macports from git, which works > just fine. I've followed the advice on LibcxxOnOlderSystems and did > > cxx_stdlib libc++ > buildfromsource always . If you enjoy troubleshooting this, that's fine, but if you just want a system that works, use a newer version of macOS; you'll encounter fewer problems with MacPorts. > Attached you can see the list of software that I've installed so far. > In particular, I've installed `gcc8' and set it up as the default gcc > compiler, which I think is a good choice later on for lilypond-devel, > which doesn't like to be compiled with clang, AFAIK. As Chris mentioned, ports use a compiler of their choosing, not of yours. Ports that don't work with a particular compiler will specify that, as the lilypond-devel port does specify that it does not build with clang, llvm-gcc, or old Apple gcc. In fact, it takes the unusual and not-recommended step of completely discarding MacPorts base's list of preferred compilers and substituting its own list, which begins with MacPorts gcc6, so that's the compiler it will use. Probably gcc6 was the latest stable version when that list was last updated, so it would be reasonable to add gcc7 and gcc8 to the list. The best solution would be to fix lilypond so that it builds with clang, but that's something to be discussed with the developers of lilypond. > As the > maintainer of FreeType and ttfautohint I'm also curious whether my > stuff works correctly – there are some glitches here and there which I > want to fix eventually with macport push requests as soon as I'm more > acquainted with the system. > > Note that I'm an old GNU/Linux user; I only work on the Mac for > software testing. > > Now to my problems. I stumbled across various issues for which I > can't find an explanation or solution in the net. Some of them should > probably be directed directly to the tracker I guess... > > * The concept of `subports' is not mentioned in `man port'. Where is > it described? I can more or less deduce now how it works, but a > formal description would be nice. Unfortunately we don't have documentation on subports yet. https://trac.macports.org/ticket/36957 requests it, and the comments there describe subports a little. > * I'm missing the ability to say > > port select --set emacs emacs23 . > > I see that there is https://trac.macports.org/ticket/56949, but even > then it would be nice to have this since Lion comes with its own > emacs binary. If you want different versions of a port to be selectable with the `port select` mechanism, file a ticket in our issue tracker requesting that, assigning it to the maintainer of those ports. However, you've found #56949 which requests the deletion of the emacs22 and emacs23 ports so the issue is moot. If you install the emacs port, it will install /opt/local/bin/emacs; assuming /opt/local/bin precedes /usr/bin in your PATH, as it will by default after you install MacPorts, the emacs port's emacs binary will be used instead of Lion's older emacs binary. > * It's impossible to guess the difference between the `emacs' and > `emacs-app' port from the output of `port info'. The description of > the former should mention that it is TTY only, while the latter uses > the GUI. Additionally, `emacs --help' contains a bunch of options > for controlling the (X11) display, which are completely useless of > course if Emacs can only be run on the terminal... Please file bug reports against those ports if changes are needed. > * Saying > > port install poppler > > returns > > ---> Computing dependencies for poppler > The following dependencies will be installed: > clang-3.7 > clang-3.9 > clang-4.0 > clang-5.0 > libomp > llvm-3.7 > llvm-3.9 > llvm-4.0 > llvm-5.0 . > > For me, this looks like a bad joke! *Four* compilers are necessary > for poppler? I agree this is highly undesirable. It seems to me like it should be possible to significantly reduce that list, but I have not analyzed the problem in depth. Certainly, I think we have bugs in our compiler selection process. Especially on systems older than OS X Mavericks, while installing ports, you may see warnings to the effect that all compilers were blacklisted, but the build succeeds anyway. Anytime that happens, there is obviously an error in the compiler selection process. The compilers in question were blacklisted because they were thought not to work for this situation, but if the build then succeeded, obviously at least one of them does work and shouldn't have been blacklisted. Some of this may be down to individual ports setting compiler.blacklist, compiler.fallback or compiler.whitelist incorrectly, and fixes would be needed in those individual ports. But some of it may also be due to the default compiler selection process implemented by MacPorts base. Unfortunately due to the different capabilities of different operating systems and C++ standard libraries, the rules implemented in MacPorts base are rather complex, and therefore difficult to read through and understand. An overhaul of the MacPorts base compiler selection process was proposed here: https://github.com/macports/macports-base/pull/88 You might try recompiling MacPorts base from that PR to see if its new compiler selection process results in any improvements for this problem. > Additionally, it seems that since clang 3.8 it is no > longer necessary to have a separate `libomp' package at all, cf. > > https://openmp.llvm.org/ . I don't have any information about that. Our llvm/clang ports are maintained by our longtime expert contributor Jeremy Huddleston Sequoia and I trust his judgement on what those ports do. > Theoretically, my already installed gcc8 should compile this package > just fine, right? Why doesn't `port' consider it? Looking into > poppler's Portfile I don't see any compilers blacklisted. Like most of our ports, the gcc ports are offered by MacPorts primarily for users to use outside of MacPorts. There are some exceptions (such as ports that need a Java or Fortran compiler), but for the most part MacPorts will not use gcc ports to compile other ports. MacPorts takes its cue from Apple, which abandoned gcc as of version 4.3 in favor of clang. Using gcc ports to compile C code would probably work, though we don't believe it would offer any advantages over using clang, except for projects that are using nonstandard GNU-specific C code, and in those cases our preference is to fix the code to be standards compliant. Using gcc ports to compile C++ code is out of the question due to the C++ standard library mismatch, and poppler does use C++ code. > Please advise how to escape this dependency hell... > > * Where can I get a concise and up-to-date description of portfiles? > `portfiles.7' seems to be heavily out of date... What would you like to know? Portfiles are Tcl files (Tcl 8.5, specifically), with MacPorts additions. Tcl is described at https://www.tcl.tk and the MacPorts additions are described in `man portfile` and at https://guide.macports.org . If portfile.7 or the guide are out of date (and I have no doubt they are), let us know in what ways (by filing bug reports) so that someone can fix them, or you can fork our repositories, make the needed changes and send pull requests. The source code of the manpages is in asciidoc format in the macports-base repository. The source code of the guide is in docbook xml format in the macports-guide repository, but we have work in process to convert those sources to asciidoc, which we think will be easier to edit, so if the xml looks intimidating now, you could wait until after the conversion if you have contributions you want to make there.
