Missing (build) dependencies as found through trace mode.

Clemens Lang cal at macports.org
Tue Jul 1 05:36:13 PDT 2014


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


More information about the macports-dev mailing list