Recommended way to use Autoconf Archive macros and other 3rd party macros

Question

I found several useful macros in the Autoconf Archive, and also a useful m4 file which helps test Boost library support. The Autoconf Archive is hosted by GNU and the Boost m4 helper is hosted as a GitHub repo. I'd like to use them in a C++ project which uses Autotools and managed by git.

Clearly it's possible to download them by hand and insert into my project's git repo. But is there a more recommended way to do it?

For example, it's possible to ensure the 3rd-party files are in the latest version by making the build process download them automatically, instead of updating them in the repo by hand. It also helps separate source from external files, since the 3rd party files aren't really part of the pure source code, but are external downloaded files.

If it's a good thing, should it be done by hand through autogen.sh? Or using automake.am? Or both (e.g. download files in autogen.sh and test version+update in automake)?

I guess keeping them in the git repo is not a disaster (just like things like COPYING, git.mk and others are there), but it's still useful to make the build process update them to latest version from the web.

Rabbinate

Answer 1

On the contrary, autoconf macro files are part of the corresponding source, important enough to be needed in the make dist tarball. In reality, most autoconf macros don't change often enough to warrant some kind of update feature in the build. Even if they did update often, there's no guarantee that the updated macro won't break your existing build.

Keeping macros under source control is a good idea.

EDIT: I agree with @delinquentme that adding these as a git submodule would be nice (can lock to a version, update easily). But I see a couple problems with this approach.

The first one is that git does not (IIUC) support partial checkouts even with submodules. The GNU Autoconf Archive (for example) has lots of macros and you'll probably only need a few of them. The rest of the unused files and macros will still be there, unused, and getting in the way.

The second problem is AC_CONFIG_MACRO_DIR only finds macros in one directory with no subdirectory search inside that directory, making using multiple submodules annoying. You could do it by checking out the submodules somewhere unobtrusive and symlink them to AC_CONFIG_MACRO_DIR.

To me, the upstream history of the macro isn't really that important. That's what the upstream's VCS is for :-).

Legging

Answer 2

You've got a number of options for a more nuanced way of handling these dependencies:

Submodules ( http://git-scm.com/docs/git-submodule )

... [S]ubmodules are meant for different projects you would like to make part of your source tree, while the history of the two projects still stays completely independent and you cannot modify the contents of the submodule from within the main project. [Note: cd-ing into repo will allow edits]

• Most-similar to your suggested in-repo approach

• Especially powerful for any code kept within Git ( as Autoconf Archives are )

• Freezes to an exact commit ( https://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/ ) thus alleviating the chance of breaking on build

• Less upfront config than a Hook

Hooks ( http://git-scm.com/book/en/Customizing-Git-Git-Hooks )

Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these hooks: client side and server side.

• Runs via git-specific events

• Git-supported if you're looking for continuous integration, instead of frozen assets

I agree with @ldav1s' on keeping them within version control, however with regards to maintainability it could be helpful to know where the code originated ( maintain history ). And with future updates it seems advantageous to build off the work others have done...

TLDR: Go with a submodule, maintain history and be done w it.

$ git submodule add http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_am_jobserver.m4

The above command will submodule the URL into your codebase within the current dir

Bibliography