* Junio C Hamano wrote on Tue, Jan 20, 2009 at 07:50:52AM CET:
> Ralf Wildenhues <Ralf.Wildenhues@xxxxxx> writes:
> > --- a/configure.ac
> > +++ b/configure.ac
> > + [ac_cv_c_c99_format=no],
> > if test $ac_cv_c_c99_format = no; then
>
> This one probably is Ok, but...
>
> > @@ -380,6 +381,7 @@ AC_RUN_IFELSE(
> > FILE *f = fopen(".", "r");
> > return f && fread(&c, 1, 1, f)]])],
> > [ac_cv_fread_reads_directories=no],
> > + [ac_cv_fread_reads_directories=yes],
> > [ac_cv_fread_reads_directories=yes])
> > ])
> > if test $ac_cv_fread_reads_directories = yes; then
>
> I am not quite sure if this is an improvement ...
>
> > @@ -414,6 +416,7 @@ AC_RUN_IFELSE(
> > if (snprintf(buf, 3, "%s", "12345") != 5
> > || strcmp(buf, "12")) return 1]])],
> > [ac_cv_snprintf_returns_bogus=no],
> > + [ac_cv_snprintf_returns_bogus=yes],
> > [ac_cv_snprintf_returns_bogus=yes])
> > ])
> > if test $ac_cv_snprintf_returns_bogus = yes; then
>
> ... nor this one.
I can see why you're cautious here, but AFAICS the actual code that will
be enabled by these defaults is portable to systems that have no bogus
snprintf and whose fread does not read directories. IOW, all you lose
is a bit of performance at most.
> Is there a way to say something like "I'll autodetect as much as I can
> without running tests, but please tell me these characteristics of the
> target system manually" and leave the resulting config.mak.autogen in a
> shape that will guarantee compilation failure until the missing ones are
> supplied by config.mak?
Well, without my patch, each of these three tests will get configure to
error out. Instead of setting a variable, these added arguments can
also output a more helpful error, in the sense of
"please find out whether the return value of snprintf is ok,
and set $ac_cv_snprintf_returns_bogus accordingly when rerunning
configure"
> The thing is, I am not convinced that it is desirable to be able to build
> a possibly suboptimal binary in a cross compilation environment, without
> being told in what aspect of the resulting binary is suboptimal. I'd
> rather see a build system that honestly tells me what information it needs
> but couldn't find, so that I would know I have a chance to help it.
Sure.
> Of course, suggesting a pessimistic default that can result in suboptimal
> but correct result would be a good thing to help the user help the build.
> I just think it is a good idea to tell the user we are giving such hint a
> bit more loudly to draw attention.
Agreed, too. Would you prefer a hard erroring out of configure, for
each of the tests, or would it suffice to see a warning fly by?
Thanks,
Ralf
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
