Build issues on MacOS

[maxieds]

I am having to modify the Python/Makefile substantially to get GTFP to build on MacOS (Big Sur). The following is the tail end of what I get after trying to build from source:

$ make clean && make
... MUCH OUTPUT TRUNCATED ...
libtool: link: rm -fr  .libs/libgomp.a .libs/libgomp.la .libs/libgomp.lai
libtool: link: ar cr .libs/libgomp.a  alloc.o atomic.o barrier.o critical.o env.o error.o icv.o icv-device.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o bar.o ptrlock.o time.o fortran.o affinity.o target.o splay-tree.o libgomp-plugin.o oacc-parallel.o oacc-host.o oacc-init.o oacc-mem.o oacc-async.o oacc-plugin.o oacc-cuda.o priority_queue.o affinity-fmt.o teams.o oacc-profiling.o oacc-target.o
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libgomp.a(mutex.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libgomp.a(ptrlock.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libgomp.a(oacc-target.o) has no symbols
libtool: link: /usr/bin/ranlib -c .libs/libgomp.a
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libgomp.a(mutex.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libgomp.a(ptrlock.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libgomp.a(oacc-target.o) has no symbols
libtool: link: ( cd ".libs" && rm -f "libgomp.la" && ln -s "../libgomp.la" "libgomp.la" )
cd  && /Library/Developer/CommandLineTools/usr/bin/make  am--refresh
make[1]: -c: No such file or directory
make[1]: *** [/aclocal.m4] Error 1
make: *** [make_GTFold] Error 2

[maxieds]

I thought about this more. I think the build problems are related to changes in automake and the autoconf tools used in the build of the original GTFold source. Using these tools for a relatively small code base is, as we discovered years ago with RNAStructViz, overkill and prone to breaking over time. I am considering just rewriting the build scripts (especially the Makefile for those subdirectories) for that directory. It is more to do upfront to fix this issue, but should lead to easier maintenance and better reliability of these builds in the future.