Ken Moffat wrote: > On Thu, Dec 01, 2011 at 03:59:41AM +0100, Aleksandar Kuktin wrote: >> I have a tip to share regarding the dependency checking currently >> going on. >> >> While I do not know what exactly is the way editors check for >> dependencies of packages, there is a way to fast track them, if your >> main method is to build and wait to see which is the combination that >> does not fail - a horrendous experience. >> >> Now, dependencies are checked by the configure script, which itself is >> generated from configure.ac (I am not sure what is the position of >> configure.in in all this..). >> >> Therefore, one can gain a lot of information on which packages are >> required by inspecting the configure* files. >> >> Say, like this: >> grep -h -v '^[[:space:]]*dnl' <package_dir>/configure* | \ >> grep -v '^[[:space:]]*#' | grep --color -i req >> > > The grep looks handy, thanks! Personally, I mostly build *before* > I double-check the dependencies. Then, from my logs I note the > things it checks for as regular names (e.g. for xorg-server xmlto > xsltproc etc) and then list the names of the other things where it > uses pkg-config, e.g. PIXMAN, UDEV, DBUS, ...). Most packages use > impenetrable names, e.g. libdmx checks for DMX. I then use vim to > read the configure script and find that in that case it looks for > x11 xext xextproto dmxproto >= 2.2.99.1. Mostly, but not > always,identifying which package produces a particular .pc file is > fairly obvious. > > The reason I take this approach is that packages which build with > the look and feel of a different OS (firefox is an example) are full > of dependencies that we on linux will never see. > > Actually, waiting for a failure is not too bad on a good package - > it might take a couple of minutes to run through configure, then it > will balk at the first failure. Much nicer than building for a long > time and then failing to link!
I agree with Ken. The grep looks useful. Additionally, each editor develops his own techniques. I look at the configure.ac in vim as well as the logged output of ./configure. The problem is that the configure is not always complete. When building from scratch, sometimes a common capability is missing from configure that only shows up in the make. One of the harder parts is figuring out which dependencies are really required vs optional. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
