Re: introduce configure --with-sysroot

[Daniel Jacobowitz <drow at mvista dot com>]

I see that Richard just approved this; I've got some comments, but
please do check it in and we can come to agreement later :)

On Thu, Oct 10, 2002 at 05:01:37PM -0300, Alexandre Oliva wrote:
> On Aug 23, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > On Fri, Aug 23, 2002 at 01:26:37AM -0300, Alexandre Oliva wrote:
> >> On Aug 22, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> >> 
> >> > I second H-P's comment about --with-installed-sysroot.
> >> 
> >> Tell you what...  --with-sysroot might just as well refrain from
> >> copying anything, and GCC could set itself up so as to use the very
> >> pathname that was passed.  Then, we'd just have to tweak our build
> >> scripts to do the copying from the outside.  I happen to find this
> >> more elegant, even.
> >> 
> >> The only potential gotcha is that one must pass ugly pathnames as
> >> arguments to --with-sysroot to get a relocatable tree: they must start
> >> with ${gcc_tooldir} = ${libdir}/${libsubdir}/../../../..., and the
> >> ${libsubdir} part is not easy to guess right from the outside.
> 
> > Ugh.  I don't like that at all.
> 
> I've updated the patch such that --with-sysroot would no longer do any
> copying, and, if the argument started with ${gcc_tooldir} (passed
> literally to gcc's configure, to be expanded by the Makefile), it will
> be relocatable.  I've also arranged for the target root directory to
> *not* be relocated in case it doesn't exist within the relocated tree,
> which is useful at build time (so I could remove the ugly hack that
> created a link to $(libdir) in the top builddir, that assumed
> exec_prefix was a subdir of prefix and would only work for gcc as a
> sub-directory of the top build tree).

+@options{$@{gcc_tooldir@}/sys-root}.  Starting the pathname with
+@option{$@{gcc_tooldir@}/}, in such a way that this variable is not
+expanded by the shell, but rather by the gcc Makefile, enables the
+target sysroot directory to be relocatable along with the entire
+install tree, but it will require the gcc tool directory to be created
+@emph{before} the build is started.  This directory, as well as its
+intermediate pathnames, can be easily created by running @command{make
+install-gcc-tooldir} the gcc build directory.  This is not done
+automatically to avoid touching the install tree without explicit
+permission.


$gcc_tooldir is something like:
  gcc_tooldir = $(libsubdir)/$(unlibsubdir)/../$(target_alias)

So you're saying that for this to work, $(libsubdir)/$(unlibsubdir)
already needs to exist.  That's a little awkward... since, generally,
it won't.  And since I build as non-root I can't run
install-gcc-tooldir during the build process.  I'm not quite satisfied.
This is the only objection that I've got left.


+if { test x$host != x$target && test "x$with_headers" = x &&
+     test "x$with_sysroot" = x ; } || test x$with_newlib = xyes ; then

Is the {} construction actually portable?  I'm not familiar with it,
but you'd know better than I do :)

> >> Alternatively, gcc could attempt to make the pathname relative, just
> >> like it does for gcc_tooldir, but I dislike this option.  Perhaps we
> >> could only make it relocatable if it starts with ${exec_prefix}.
> >> How's that?
> 
> > Ideal!
> 
> I enclose another patchlet at the end that translates ${exec_prefix}
> into a relocatable reference to ${exec_prefix} in the argument to
> sysroot, but I'd rather not put it in.  It feels good enough to
> support only pathnames starting with ${gcc_tooldir}, even if this
> might require an additional `..' to get to other directories outside
> ${target_alias}.  Is this good enough?

That's fine for me, I think.  I'd like to get rid of the obnoxiousness
of all the dots - _especially_ if it involves $(unlibsubdir) - but
I don't really care what I have to specify on the command line.

> Does the relocation of target_system_root conditional on the existence
> of the relocated tree address all three cases for you?  It seems to me
> that it does.

Yes, I think it does.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer