[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


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.


>  Richard> 2003-03-31  Richard Dawe  <address@hidden>
>  Richard> * Get the target platform name.
> [...]
> [...]
>  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.


> [...]
> 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?

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]