tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Bootstrapping pkgsrc with a compiler



I have experimented a bit with bootstrapping pkgsrc with a compiler intended to be used to build the rest of pkgsrc.  At least on some systems I have found that to be a huge help and am wondering if we should be moving toward enabling support for that.  One use case is that on certain systems the native compiler is inadequate.  In that case it is much easier to bootstrap pkgsrc with a compiler than to bootstrap it without one, install a compiler, and then rearrange the setup to allow building everything else with the new compiler.

Here is one small patch that allows me to do that.  This most definitely should not be committed, but I think it illustrates what I think are the minimal elements that would need to be addressed.  I am posting it to foster a discussion.

Index: bootstrap
===================================================================
RCS file: /cvsroot/pkgsrc/bootstrap/bootstrap,v
retrieving revision 1.281
diff -u -r1.281 bootstrap
--- bootstrap	30 May 2020 21:36:15 -0000	1.281
+++ bootstrap	2 Jul 2020 18:17:37 -0000
@@ -1373,6 +1373,13 @@
 
 echo "WRKOBJDIR=		${wrkdir}/wrk" >> ${BOOTSTRAP_MKCONF}
 
+echo "" >> ${BOOTSTRAP_MKCONF}
+echo "# XXX - bootstrap compiler" >> ${BOOTSTRAP_MKCONF}
+echo "PKG_DEFAULT_OPTIONS+=		always-libgcc" >> ${BOOTSTRAP_MKCONF}
+echo "DISTDIR=			/path/to/distfiles" >> ${BOOTSTRAP_MKCONF}
+echo "PACKAGES=			/path/to/packages" >> ${BOOTSTRAP_MKCONF}
+echo "FETCH_USING=			curl" >> ${BOOTSTRAP_MKCONF}
+
 echo "" >> ${TARGET_MKCONF}
 echo "" >> ${BOOTSTRAP_MKCONF}
 if test -n "${mk_fragment}"; then
@@ -1435,6 +1442,8 @@
 esac
 build_package "pkgtools/pkg_install"
 
+build_package "lang/gcc8" # XXX - bootstrap compiler
+
 etc_mk_conf="$sysconfdir/mk.conf"
 
 # Install the example mk.conf so that it is used, but only if it doesn't

For default use of pkgsrc, the absolute minimum is some way of selecting which compiler to build and then adding a command as in the second part of this patch.  No doubt, that requires adding a command option to bootstrap.

Since this will almost certainly trigger fetching distfiles, I expect much of the first section to also be needed in order to accommodate non-default locations of things.  These also would require additional command options.  However, those control variables that are often in the user-supplied makefile fragment for bootstrapping; we could entirely independently provide command options so they don’t have to be put elsewhere.

I am less clear whether the always-libgcc option would always be needed.  Given my recent experience (and comments here), I feel yes.  However, others may know better.

Of course a real version of this would retain the current behavior by default.  However, I am interested in what people think about enhancing the bootstrap script to support this use case.

Thanks for your input.

Cheers,
Brook





Home | Main Index | Thread Index | Old Index