So with a pkgsrc version up to about two years ago I was using autoswc
quite successfully, with one caveat.
Autoswc has one _major_ problem, IFF run as root, that I have mostly
fixed for myself some time ago, and finally turned into this patch:
Index: pkgtools/autoswc/files/autoswc.sh
===================================================================
RCS file: /cvs/master/m-NetBSD/main/pkgsrc/pkgtools/autoswc/files/autoswc.sh,v
retrieving revision 1.3
diff -u -r1.3 autoswc.sh
--- pkgtools/autoswc/files/autoswc.sh 11 Oct 2008 18:03:58 -0000 1.3
+++ pkgtools/autoswc/files/autoswc.sh 22 Mar 2022 20:52:42 -0000
@@ -102,6 +102,9 @@
# The permissions may change during the execution of this script, but this
# won't bring us problems. This check is just done to save some time in
# case we got the wrong user running autoswc.
+if type chflags >/dev/null 2>&1; then
+ chflags nouchg ${confcache}
+fi
touch ${confcache} >/dev/null 2>&1 || err "can't update ${confcache}"
# Ensure that the source configure.ac exists.
@@ -154,6 +157,9 @@
# Update the cache file. We don't give it write permissions since we don't
# want third-party configure scripts update it with unwanted results.
install -c -m 444 config.cache ${confcache} || err "can't update ${confcache}"
+if type chflags >/dev/null 2>&1; then
+ chflags uchg ${confcache}
+fi
cd -
This prevents most packages from butchering the cache file with their
own results, though some, like lang/erlang, still manage to do so
somehow, on at least Darwin.
Thoughts?
However in the past weeks I've upgraded (finally) to pkgsrc-current and
I've been plagued by problems related to either libtool and/or not
having been careful enough with my shell environment when running
autoswc (i.e. to generate the system cache file).
The biggest problem has been accidentally using "bmake" when I should be
using "make" on NetBSD (because I have been doing builds on Darwin in
parallel -- maybe I should put /opt/pkg/bin earlier in my path and
hand-make a link from bmake to make there so I don't confuse myself).
Unfortunately "bmake -v CC" gives a different result to "make -v CC" on
NetBSD (by default, "cc" vs. "gcc"), and so I've had the bad luck to
have accidentally used "bmake" to build libtool-base.
Libtool bakes in what it calls the default "tagged configuration" that
it auto-selects when there's no "--tag" option, AND IFF the compiler
being invoked matches the compiler that was found when libtool was
configured and built.
So, if you happen to have built libtool-base with "bmake" by accident,
you end up with this error (e.g. from a "libtool --mode=compile ${CC}"
command, unless the package configure happens to also find "CC=cc"):
libtool: compile: unable to infer tagged configuration
libtool: error: specify a tag with '--tag'
I also messed up once by accidentally running autoswc when I had the
/usr/src $TOOLDIR in my path! This causes the same problem for packages
using configure scripts that load the autoswc cache file.
I mention all this because it raises some partly intertwined issues I
wanted to discuss:
1. Maybe when "bmake" is installed on NetBSD is should use /usr/share/mk
instead of the pkgsrc-supplied mk-files (which are currently broken
for some uses, and bit-rotting by the day, and I for one think they
should be replaced by Simon's latest mk-files anyway as that would
solve all of the breakage and bit-rotting and most future maintenance
issues in one go)
2. Maybe libtool could/should be patched so that it considers all of the
allowable/supported pkgsrc compilers as recognized compilers?
3. Maybe autoswc shouldn't have any AC_PROG_* macros? I.e. it shouldn't
cache the values of any toolchain programs, especially not CC/CPP/CXX
etc.?
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpsYzB1GcUaA.pgp
Description: OpenPGP Digital Signature