Date: Fri, 21 Jan 2011 09:22:58 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Alexander Kabaev <kabaev@gmail.com> Cc: stable@FreeBSD.org, current@FreeBSD.org, uqs@FreeBSD.org Subject: Re: RFC vgrind in base (and buildworld) Message-ID: <E41C301B-58FA-4D75-A9C9-0F9DA194012B@mac.com> In-Reply-To: <20110121102544.1bc9222c@kan.dnsalias.net> References: <20110120201740.GE24444@acme.spoerlein.net> <20110120153103.50a86ad3@kan.dnsalias.net> <CE03E002-9A32-49AC-8C31-1568FCD127E4@mac.com> <20110121102544.1bc9222c@kan.dnsalias.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 21, 2011, at 7:25 AM, Alexander Kabaev wrote: > On Thu, 20 Jan 2011 17:11:13 -0800 > Marcel Moolenaar <xcllnt@mac.com> wrote: >=20 >>=20 >> On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote: >>=20 >>> On Thu, 20 Jan 2011 21:17:40 +0100 >>> Ulrich Sp=F6rlein <uqs@FreeBSD.org> wrote: >>>=20 >>>> Hello, >>>>=20 >>>> Currently our buildworld relies on groff(1) and vgrind(1) being >>>> present in the host system. I have a patch ready that at least >>>> makes sure these are built during bootstrap-tools and completes the >>>> WITHOUT_GROFF flag. >>>>=20 >>>> vgrind(1) is only used for two papers under share/doc and we could >>>> easily expand the results and commit them to svn directly, >>>> alleviating the need to run vgrind(1) during buildworld. >>>>=20 >>>> OTOH, there are much more useful tools to vgrind(1) for source code >>>> formatting. So do we still have vgrind(1) users out there? >>>>=20 >>>> Regards, >>>> Uli >>>=20 >>> Why it needs to be in bootsrap tools at all? We have build tools for >>> this exact purpose. >>=20 >> Actually no. The buildtools target is there to allow building = programs >> that are not installed, but are otehrwise needed to compile a = program. >> These are typically little tools that create source files. >>=20 >> The bootstrap target is the to deal with compatibility in case we >> can't use the version on the host or we don't want to depend on the >> version on the host. >=20 > Then it is cross-tools, or whatever build stage that builds new gcc = and > other tools which run on host and are used to generate the final = target > binaries. Cross-tools is what you say. Anything that has target architecture neutral output should therefore not be build all the time as part of cross-tools. > The point being that bootstrap-tools target is greatly abused > in src, with recent addition of llvm libs making it almost pandemic. Yes, I can see bootstrap tools being abused. It started being abused the moment it came to live :-) But rather than abuse the other targets, I'm more inclined to review our build system and see if we need to start making big changes again. In particular: Juniper is ramping up on stock FreeBSD development and the first thing we ran into is that FreeBSD doesn't have a good cross-development and cross-build environment. We have hacks so that we don't have to say we don't have it at all, but one cannot possibly believe that what we have is good. So, let's get everything on the table and look for ways to improve things structurally rather than using ad-hoc or one- off tweaks. Is there value in having FreeBSD development ports that one can install on a machine and thereby making it suitable for FreeBSD (cross-) development? In other words: do people mind if there's a one-time setup (or upgrade) required before being able to build FreeBSD? What if this is done automatically as part of buildworld (i.e. installing or upgrading a port)? If not, then we can get rid of bootstrap-tools altogether. If the port also includes (cross-compilers) we can also rid ourselves of cross-tools and end up with a good cross-devel environment in the process. Thoughts? --=20 Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E41C301B-58FA-4D75-A9C9-0F9DA194012B>