ISO image: where is the CLANG compiler?

[Andreas Nilsson]

On Thu, Jan 19, 2017 at 8:58 PM, Glen Barber <gjb at freebsd.org> wrote:

> On Thu, Jan 19, 2017 at 08:50:34PM +0100, Andreas Nilsson wrote:
> > On Thu, Jan 19, 2017 at 8:10 PM, Glen Barber <gjb at freebsd.org> wrote:
> > > I do want to weigh in here and inform I am actively watching this
> > > thread.  clang(1) is not in disc1.iso or bootonly.iso because the
> > > MK_TOOLCHAIN knob is disabled in the targets that generate them.  This
> > > has actually been the case for quite some time for these images.
> > >
> > > dvd1.iso does contain clang, but very rarely (if ever, actually) are
> > > there dvd1.iso images produced for development snapshots.  This is, in
> > > part, solely because of the additional space/bandwidth required on the
> > > mirrors (not just mirrors controlled by the Project, but third-party
> > > mirrors as well).
> > >
> > > I am working on splitting out how the memstick.img and disc1.iso images
> > > are produced, but ran into a problem which I'm looking into a
> workaround
> > > that is backwards-compatible.  Since for USB images, a 700MB limit does
> > > not make sense, and right now it just so happens that the memstick.img
> > > is created from the same contents of disc1.iso.
> > >
> > > I know this does not help with the immediate issue, but wanted to chime
> > > in with I do see and understand the larger issue, and am working on
> > > a more long-term resolution instead of a one-line workaround.
> > >
> > >
> > Good to see discussion, but my 5c is: do not enlarge regular install
> media,
> > it is hefty enough. I'd rather see it shrink, although without the
> > limitations of old cd's rescue-env.
> >
> > Install media is install media, not live image. Live usb-sticks are so
> easy
> > to do on your own, why waste the Projects storage and bandwidth on it?
> >
>
> For cases like what initiated this thread, actually.  But, I'm not
> looking to increase the disc1.iso size, but separate the disc1.iso and
> memstick.img targets, which then can be created from different userland
> environments (one with /usr/bin/clang and one without, for example).
>
> But, I do agree with you that keeping the downloadable installer medium
> as small as possible (while still being usable for "rescue" cases like
> this) is ideal.
>
> Glen
>
>

Good good. I am in no way opposed to the "infrastructure" change of
separating the targets, sounds like a bit of makefile-fun actually. And
having tools to create memsticks from ones preferred environment would be
sweet.

Maybe someone could add a target in the makefiles for a rescue image, which
basically would be the complete FreeBSD system one would get after untaring
base, kernel and src?

Best regards
Andreas