Remove build/: two dead developer setups, and the autotools helpers moved to m4/ and build-aux/

[d-torrance]

build/ had three subdirectories. Two of them cannot work and are removed here;
the third holds one tracked file, and moves to where autotools projects
conventionally keep it. The directory itself is gone afterwards.

build/setup/make-Makefile.sh — 4967c4e

A 2013 developer script that cloned memtailor, mathic and mathicgb and built them
against each other in several configurations. Last substantive commit 93d8985,
2013-09-24. Broken three ways over:

• it clones from https://github.com/broune/{memtailor,mathic,mathicgb}.git, the
  pre-Macaulay2 URLs;
• it downloads gtest 1.6.0 from http://googletest.googlecode.com/files/, and
  Google Code shut down in 2016 — every other target in the makefile it writes
  depends on the gtest target, so none of them can run;
• it defines MEMTAILOR_DEBUG, which is not a macro. memtailor's is
  MEMT_DEBUG, as PR Don't define memtailor's and mathic's debug macros #68 established, so its assert-enabled configurations never
  enabled memtailor's asserts even back when the script worked.

doc/description.txt referred to it in three places, all updated: the recipe for
setting up several configurations at once goes with the script, and the two
project ideas that described the makefile it wrote no longer point at it.

build/vs12 — b254bfa

Visual Studio 2012 project files. Last real change 2013-10-03; the two commits
since are a file-permission fix and the CRLF normalization in f78d6be.

Staleness is not the decisive part — they cannot work. stdinc.h has required
C++17 since PR #60 and VS2012 does not do complete C++11, so any build stops at
#error "mathicgb requires C++17 or later". Independently the file list has been
wrong since 2021: MESClassicGBAlg.cpp, added in e6996a3, is missing from
mathicgb-lib.vcxproj.

Three things go with them, all of which existed only for these files: the
*.sln text eol=crlf rule in .gitattributes (no .sln, .vcxproj or
.filters file remains anywhere in the tree); the seven MSVC artifact rules in
.gitignore, one of which named vs12's output/ directory specifically; and
doc/description.txt's entire "Installation for Visual Studio" section, which
asserted that "as of the time of this writing (October 3, 2013) the code compiles
in MSVC".

Deliberately kept: the #ifdef _MSC_VER branch in stdinc.h, which is the
ordinary shape of a compiler-abstraction header and is paired with a __GNUC__
branch; Atomic.hpp's MSVC path; and cmake/FindTBB.cmake, which is vendored
third-party code carrying its own MSVC logic.

build/autotools → m4/ and build-aux/ — cd80f1d, 25735e1

Two levels of directory for one tracked file. Everything else under there —
install-sh, missing, depcomp, compile, ar-lib, config.guess,
config.sub, ltmain.sh, test-driver and the five libtool .m4 files — is
written by autoreconf --install and ignored; the only thing kept in the tree is
ax_cxx_compile_stdcxx.m4, which configure.ac calls for the C++17 requirement.
This uses the layout autoconf's own manual and gnulib default to: m4/ for the
macros, build-aux/ for the auxiliary tools.

The ignore rules are consolidated with the move. compile and test-driver were
listed in the top-level .gitignore while their seven siblings were in the
subdirectory's; they are together in build-aux/.gitignore now. One of the three
top-level entries was wrong regardless: configure has generated mathicgb.pc at
the top level since PR #72, not under build/autotools, so the built file has
been showing up as untracked ever since. That entry is now /mathicgb.pc.

The second commit drops ACLOCAL_AMFLAGS from Makefile.am in favour of
AC_CONFIG_MACRO_DIRS, which aclocal has traced out of configure.ac since
automake 1.13 — otherwise the same directory is written twice, in two files, where
the copies can fall out of step.

One cosmetic regression from that: libtoolize now ends every autogen.sh run with
Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am. It checks for the
flag without checking whether AC_CONFIG_MACRO_DIRS already covers it — the line
above it in the same output reads putting macros in AC_CONFIG_MACRO_DIRS, 'm4' —
so the suggestion is wrong on libtool 2.4.7, but it is new noise. Happy to keep
ACLOCAL_AMFLAGS and drop that commit if the nag is worse than the duplication.

Verification

Both build systems, from a tree with build/ deleted, on GCC 13.3 / TBB 2021.11.0:

• autotools: autogen.sh, configure, make distcheck — PASS: unittest,
  archive built. distcheck unpacks the tarball and builds out of tree against a
  read-only srcdir, so it exercises the moved m4/ and build-aux/ from scratch;
  they ship in the tarball exactly as build/autotools/ did.
• cmake: configure reports Multithreading with TBB: ON, build clean,
  src/mathicgb-unit-tests passes 246/246 in 29 suites.

git status is clean after both, so autoreconf regenerates every moved file
into its new home and the ignore rules cover all of them. configure still
expands the C++17 check through the relocated macro: checking whether g++ supports C++17 features by default... yes.

🤖 Generated with Claude Code