[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Don't punish non-DJGPP/non-Windows platforms..., rev. 2 [PATCH]
From: |
Richard Dawe |
Subject: |
Re: Don't punish non-DJGPP/non-Windows platforms..., rev. 2 [PATCH] |
Date: |
Tue, 01 Apr 2003 21:59:29 +0100 |
Hello.
Alexandre Duret-Lutz wrote:
>
> Hi Richard,
>
> >>> "Richard" == Richard Dawe <address@hidden> writes:
>
> [...]
>
> Richard> This should apply cleanly to both the 1.7 and 1.8 branches.
>
> I'd prefer this goes only on HEAD. Let's try to put only
> bug-fixes and doc improvements on branch-1-7.
OK.
> Richard> 2003-03-31 Richard Dawe <address@hidden>
>
> Richard> * configure.in: Get the target platform name.
> [...]
> Richard> +AC_CANONICAL_TARGET
> [...]
> Richard> +case $target in
> [...]
>
> You care about a target platform only when you build a
> cross-compiler or its supporting tools. The above idiom is very
> common amongst existing configure.ins but it's usually an error:
> what people mean is _HOST and $host. It would be nice to find
> a way to teach people this... any idea?
>
> Where do you learn to use $target? Maybe this is the place we
> should fix. (FWIW I already fixed the place were *I* learned to
> use $target...)
Host didn't seem quite right. So it was a choice between build and target. The
only reason that I chose target over build is that the tests run on the
target. Is this reason bogus?
I didn't look at any particular documentation to decide between
host/build/target. I read the autoconf docs, to see how to detect
host/build/target. I don't think the autoconf docs misled me in any way. ;)
> In this precise case I guess we only want _BUILD and $build.
>
> [...]
>
> Richard> +AC_MSG_CHECKING([how many seconds we should wait after modifying a
> file])
> Richard> +AC_CACHE_VAL([am_cv_modification_delay], [
> Richard> +case $target in
> Richard> + *-pc-msdosdjgpp) am_cv_modification_delay=5;;
> Richard> + *) am_cv_modification_delay=2;;
> Richard> +esac
> Richard> +])
> Richard> +AC_SUBST([MODIFICATION_DELAY], [$am_cv_modification_delay])
> Richard> +AC_MSG_RESULT([$am_cv_modification_delay])
>
> Driving the autotank :) There is no point in caching the result
> of this case statement. Just handling the cache value will take
> as much time as the case statement. We don't need the checking
> message either because (1) this is not a check, and (2) the
> value will appear at the only place we may need to know it :
> when the user runs a testcase in verbose mode.
OK.
> [...]
>
> Since I've very little time these days, I'd find convenient that
> you can just check in your changes once they have been approved.
> If that's not any additional burden to you, could you fill the
> following form?
> http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi
That's no burden. I've filled it out.
I'll submit a new version of the patch sometime without the caching. Oh, and
probably the change for target -> build.
Thanks, bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]