Re: RFC vgrind in base (and buildworld)

On Jan 21, 2011, at 7:25 AM, Alexander Kabaev wrote:

> On Thu, 20 Jan 2011 17:11:13 -0800
> Marcel Moolenaar <xcllnt_at_mac.com> wrote:
> 
>> 
>> On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote:
>> 
>>> On Thu, 20 Jan 2011 21:17:40 +0100
>>> Ulrich Spörlein <uqs_at_FreeBSD.org> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> OTOH, there are much more useful tools to vgrind(1) for source code
>>>> formatting. So do we still have vgrind(1) users out there?
>>>> 
>>>> Regards,
>>>> Uli
>>> 
>>> Why it needs to be in bootsrap tools at all? We have build tools for
>>> this exact purpose.
>> 
>> 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.
>> 
>> 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.
> 
> 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?

-- 
Marcel Moolenaar
xcllnt_at_mac.com