> "Rodney W. Grimes" wrote:
>
> > IMHO, the only ``correct'' fix for the latest incarnation of the
> > problem is to finally once and for all fix the cross compilation
> > environment instead of using a half cooked tools: target to deal
> > with certain problems.
>
> brainstorm:
>
> Upgrading cannot be solved if it is approached as being nothing more
> than a cross-compilation. This can be easily seen by the following
> cross-compilation prerequisites:
>
> 1. A compiler C running on machine 1 and capable of generating code
> for machine 2 (the compiler includes headers and libraries),
> 2. Source code compatible with compiler C, but also with machine 2.
And also compatible with machine 1, that is the bugger right now
it seems. Have the sources been modified such that they are now
no longer portable :-(.
> The problem is that upgrading can violate the first part of rule 2
> (source code compatible with the compiler), because you have new sources
> (say -current) which you want to compile with an old compiler (say
> -stable). Think of having ANSI C extensions without the proper support
> for it in the compiler.
Okay.
> The current build-tools target tries to solve that by creating a
> compiler C' by using cross-compilation. The result violates rule 1:
> Compiler C' is build for machine 2 and not for machine 1 and therefore
> should not be used on machine 1. This is where the discussion is all
> about.
Then this is an error in the tools target, by design the tools are
suppose to be capable of running on machine 1, and producing code for
machine 2. Only later when you do the ``make all'' over the tree do
you produce the compiler that runs on machine 2. Yes, you may end
up building gcc/egcs twice. Just like you may end up building make
twice. To solve you above problem gcc/egcs would need to be added
to the tools target probably right after make was built.
> So, as long as rule 2 is not violated, cross-compilation can be used to
> to build a -current system on -stable and thus also to handle upgrades.
> The problem is in the case where rule 2 is violated. What's needed is
> the ability to "port" the proper tools to machine 1. Well, the first
> thing that comes to mind is the ports collection...
Why should ports have code that is any more portable than what is in
the src tree? You should just be able to build egcs from the current
sources with the correct options and achive any results you could with
a port. If you can't, then the src tree has been rendered non-portable.
> Example: If gcc on -stable can not be used to build a -current world,
> then egcs must be installed from the ports collection and build as part
> of the upgrade/cross-compilation. the egcs port does not violate rule 1
> and since egcs is used on -current, rule 2 is also not violated. The
> build process uses egcs to do the cross-compilation.
We did this without the ports collection when we jumped from gcc 1.x to
2.x, and that had some major hoops in it. One should probably look
closely at the NOTOOLS sections of the Makefile and see how it works
when this is undef.
> This implies that:
> 1. The ports collection must contain ports for all the tools that are
> needed for doing cross-compilations and/or upgrades from any
> supported
> source version to any supported target version.
I would amend that to be what has always been true up until now it seems,
the SRC tree must contain all the tools that are needed for doing
cross-compilation, and those tools should be maintained in a portable enough
state that they can be built on box X running OS Y and produce binaries
for box Z. This is the purpose of the tools build section of the Makefile.
> 2. An easy, yet flexible way must be used to be able to tell whether
> ports must be installed or not. Simple rules like
> ".if $source < srcvers .and $target > trgvers .then install egcs"
> where $source = `sysctl kern.osreldate` and so on, may be sufficient.
Irrelivant, just always build the correct set of tools. Trying to maintain
a list of the intertwinned dependicies can lead one to madness.
> Am I being clear?
Yes.
> Do I make any sense? :-)
Somewhat, you seem to be headed the right way.
> Does this in fact cover it?
I think it does, as amended by myself.
> Can it be done?
Most likely.
>
> BTW: I'm running a make buildworld on -stable with -current sources. I'm
> making assumptions I like to see verified...
:-).
>
> > I furthermore think that if you put your mindset in the frame that this
> > is just another engineering problem you'll come up with the ``right
> > solution'' that will make everyone happy.
>
> You don't have to be a committer for long to know that you can't make
> everyone happy :-)
:-)
--
Rod Grimes - KD7CAX - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
