Re: Don't punish non-DJGPP/non-Windows platforms..., rev. 2 [PATCH]

[Richard Dawe]

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/ ]