On Wed, 2006-10-25 at 14:14 +0900, Paolo Bonzini wrote:
> Not as bad as you put it, if installing and typing "make" solves the
> issue (either for zip/unzip or gmp/mpfr, it is the same). I'll let the
> maintainers decide.
See my other email which explains why it is not user friendly. Waiting
2
Andrew Pinski wrote:
On Wed, 2006-10-25 at 13:32 +0900, Paolo Bonzini wrote:
I'm more content with the gmp check at the top level and don't plan to
submit a change to that. Although I agree if this configure is shared
between binutils, gdb and gcc, and you're not compiling gcc, then it
shoul
On Wed, 2006-10-25 at 13:32 +0900, Paolo Bonzini wrote:
> > I'm more content with the gmp check at the top level and don't plan to
> > submit a change to that. Although I agree if this configure is shared
> > between binutils, gdb and gcc, and you're not compiling gcc, then it
> > shouldn't requir
On Wed, 25 Oct 2006, Paolo Bonzini wrote:
>
> > I'm more content with the gmp check at the top level and don't plan to
> > submit a change to that. Although I agree if this configure is shared
> > between binutils, gdb and gcc, and you're not compiling gcc, then it
> > shouldn't require gmp. So
On Wed, 2006-10-25 at 13:32 +0900, Paolo Bonzini wrote:
> > I'm more content with the gmp check at the top level and don't plan to
> > submit a change to that. Although I agree if this configure is shared
> > between binutils, gdb and gcc, and you're not compiling gcc, then it
> > shouldn't requir
I'm more content with the gmp check at the top level and don't plan to
submit a change to that. Although I agree if this configure is shared
between binutils, gdb and gcc, and you're not compiling gcc, then it
shouldn't require gmp. So maybe something like your "test -d" fragment
would be appr
On Tue, 24 Oct 2006, Paolo Bonzini wrote:
>
> > But this is a different case as this error is for users rather than
> > developers.
> > So instead of getting an error early before compiling, we get an error 10
> > to 20
> > minutes later and users get upset that they get an error this late for
But this is a different case as this error is for users rather than developers.
So instead of getting an error early before compiling, we get an error 10 to 20
minutes later and users get upset that they get an error this late for something
which could have been found early on.
That is a probl
Maintainability first. If something fails with parallel make, and
is reproducible with plain "make" (i.e. doesn't screw up the build
directory), I don't see a reason not to move it. You'd do "make"
anyway to check if a dependency is missing, wouldn't you?
Really, all I care about is hav
>
>
> >> if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
> >> ...
> >> fi
> >>
> >> but I think that the whole test now belongs in the GCC subdirectory, not
> >> in the toplevel (it was anyway a hack for the sake of disabling Fortran).
> >
> > Moving it is not really a good thing
On Oct 23, 2006, at 4:15 PM, Paolo Bonzini wrote:
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC
subdirectory, not in the toplevel (it was anyway a hack for the
sake of disabling Fortran).
Moving it is not reall
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC subdirectory, not
in the toplevel (it was anyway a hack for the sake of disabling Fortran).
Moving it is not really a good thing anyways as you are able to configure
an
>
> It seems that the GMP test is always run, even when installing binutils
> or gdb.
>
> You probably need something like
>
> if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
> ...
> fi
>
> but I think that the whole test now belon
It seems that the GMP test is always run, even when installing binutils
or gdb.
You probably need something like
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC subdirectory, not
in the toplevel (it was anywa
14 matches
Mail list logo
