Hi, > I wonder what to do with "missing" build time dependencies as found by > running trace mode, which are optional though.
As you already guessed that really depends on which files are referenced. > Quick example to let you actually grasp what I'm talking about: > > apache2 configure + build phase: > /opt/local/bin/elinks => port:elinks > /opt/local/bin/gawk => port:gawk > /opt/local/bin/grep => port:grep > /opt/local/bin/links => port:links > /opt/local/bin/lynx => port:lynx > /opt/local/bin/pkg-config => port:pkg-config > /opt/local/bin/ranlib => port:cctools > /opt/local/bin/rsync => port:rsync > /opt/local/bin/ar => port:cctools > /opt/local/bin/nm => port:cctools > /opt/local/include/mach-o/loader.h => port:cctools-headers > > configure, the build process and installing worked fine, but I still wonder > if there is any "policy" on handling this. > > For gawk, grep and maybe rsync I'd do nothing, as awk, grep and rsync are > provided by OS X directly. So unless the build fails, I'd ignore them. I agree. The same applies to ranlib, ar, and nm. They are provided by the Command Line Tools. Even though MacPorts' versions of these tools are used when they are installed (without trace mode), we should rather stick to the system versions -- especially as long as we use system compilers and the rest of the system toolchain. Same for cctools-headers. In most cases, the files installed by cctools and cctools-headers don't differ from the system versions, and we can thus just ignore whether they are being used from MacPorts or not. In some rare cases, the different headers actually caused problems. > pkg-config on the other hand is quite another issue and should to my mind be > added as a build dependency. I agree. It really depends on how apache2 uses it, though. Apparently it builds fine without pkg-config, but then again pkg-config is a small tool and most MacPorts users have it installed anyway. > The third category is cctools with ranlib, as and whatnot and cctools-headers: > even though they are provided by the system as well, do we want to rather > rely on the MacPorts versions or the system versions? I'm not sure/decided on > this point. See above. > The other tools links, lynx, elinks fall into another category I have really > no idea how to handle: while they seem to certainly be optional, shouldn't we > make apache2 happy by providing them? Or is that useless bloating? I'd say that's useless bloating. Ideally, to ensure reproducible builds, apache2 wouldn't even try using them, usually using some configuration flag like --disable-elinks or --without-elinks. -- Clemens Lang _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
