2

I have a C++ library that uses autoconf that I have been maintaining for 15 years. I'm now getting it to run with CI and have discovered that I need to do a better job documenting its requirements. With a python program I do this using a file called requirements.txt which is used by setuptools during packaging, and I can also use in the CI system. What's the right way to document this in a C++ autotools package?

vy32
  • 28,461
  • 37
  • 122
  • 246
  • `requirements.txt` used to install required packages in python in order to build/run code. For C++ we can achieve this like `git clone --recursive`? – Mayur Jun 28 '20 at 17:08
  • I can't put a `git clone` in an autoconf file. I know that `requirements.txt` is used for Python. I want to know how to document requirements for a C++ package. – vy32 Jun 28 '20 at 18:21
  • There are several C++ package managers. [Conan](https://conan.io/) and [vcpkg](https://vcpkg.readthedocs.io/) are popular examples. – Miles Budnek Jun 28 '20 at 18:36
  • Found some useful source https://www.youtube.com/watch?v=9cCQHJ-cNHY – Mayur Jun 28 '20 at 19:11
  • autotools does not have package management functionality. Have a look [here](https://stackoverflow.com/questions/27866965/does-c-have-a-package-manager-like-npm-pip-gem-etc) for alternatives. – rustyx Jun 28 '20 at 19:26
  • Thanks. I'm not looking for a package manager; I'm looking for a way of documenting requirements. – vy32 Jun 28 '20 at 21:10
  • 2
    Neither the C++ (or C) nor the Autotools ecosystems have specific conventions for the kind of documentation you describe. Certainly not anything intended to be machine-actionable. I guess I would normally expect to find a README file in the source distribution that included any third-party requirements among possibly many other details. As other comments suggest, *formalization* of these kinds of requirements is usually a feature associated with a package-management system, which the Autotools are not. – John Bollinger Jun 28 '20 at 22:01

1 Answers1

0

This is a kind of question that tech writers would want to know: What packages or dependencies are there of our product.

There's two kinds of dependency in C/C++ as opposed to a singular list of Python dependency (I'm not talking test-specific dependency found in some Python packages or that kind of sort).

There are:

  • header include dependency
  • library dependency

Header Include Dependency

There is a C/C++ compiler option that list out all non-system include files:

gcc -c -MMD  <source.c>

For all include files:

gcc -c -MD <source.c>

And with those list of include files, you can find out the packages that provides it, for example, in Debian:

dpkg-query -S <include-file.h>

Library Dependencies

Best approach to securing a complete list of libraries used for a particular platform/distro is to use the ldd to extract a list of external object codes that your program requires before it can get up and running.

#!/bin/bash

# List Debian packages that a given executable is dependent on
BINARY_FILE=$1

LIB_LIST=$(ldd $1 | gawk '{ print $1 }' | tr '\n' ' ')

for THIS_LIB in $LIB_LIST; do
  dpkg-query -S $THIS_LIB
done

Output result of /bin/ls gives you a multi-platform list of packages that ls executable file depends on:

~/bin/dpkg-dependency-by-executable.sh /bin/ls
dpkg-query: no path found matching pattern *linux-vdso.so.1*
libselinux1:amd64: /lib/x86_64-linux-gnu/libselinux.so.1
libc6-x32: /libx32/libc.so.6
libc6:amd64: /lib/x86_64-linux-gnu/libc.so.6
libc6-i386: /lib32/libc.so.6
libpcre3:amd64: /lib/x86_64-linux-gnu/libpcre.so.3
libpcre3:amd64: /lib/x86_64-linux-gnu/libpcre.so.3.13.3
libc6-i386: /lib32/libdl.so.2
libc6-x32: /libx32/libdl.so.2
libc6:amd64: /lib/x86_64-linux-gnu/libdl.so.2
libc6:amd64: /lib64/ld-linux-x86-64.so.2
libc6-i386: /lib32/libpthread.so.0
libc6-x32: /libx32/libpthread.so.0
libc6:amd64: /lib/x86_64-linux-gnu/libpthread.so.0
root#

With those list, you can ascertain that your autotools has properly make dependency test for them (and often without the system-related ones).

John Greene
  • 2,239
  • 3
  • 26
  • 37
  • This is useful advice in a general sense, but only tangentially related to the question actually posed. In particular, it is of no (direct) help with respect to the OP's interest in engaging a CI system. In the context of these remarks, the question might be construed as asking about what do with the dependency information once it has been gathered. – John Bollinger Oct 15 '20 at 20:52
  • Ouch. I had described a process for CD system as in Continuous Development? – John Greene Oct 16 '20 at 08:00
  • You have described mechanisms for *discovering* a program's dependencies. The OP is asking for a standardized or widely supported conventional mechanism for *representing* those in machine actionable form, such as a CI system could read and work with. – John Bollinger Oct 16 '20 at 12:49
  • Short of an IDE with excellent autoheader feature during typing of function calls, we would need to extract that functionality into a standalone tool. – John Greene Oct 20 '20 at 12:21
  • In rereading the question, section “Library Dependencies” in my original answer of using `ldd` should make quick work of such library dependency listing, no? – John Greene Nov 16 '21 at 14:26
  • 1
    Again, the question is not for a *mechanism* to finding the dependencies or list them. Rather, it asks about a *standard convention* for the location and format of the resulting dependency list. – John Bollinger Nov 16 '21 at 19:17