Re: FYI: Adjust circular dependencies

[Morten Eriksen]

> | So, time to re-submit my AC_EXEEXT patch again, I guess. :^}
> 
> Yep :)

..and again. :^)

> | +     AC_MSG_ERROR(cannot compile and link)])
> 
> Please quote.  Even if useless here, quote.

Ok.

> Please, here try to align on the arguments of _AC_LINK_IFELSE.

Ok.

> | +rm -f conftest.$ac_ext conftest.$ac_objext conftest.$ac_exeext
> 
> This is wrong: either you lack one *inside* AC_CACHE_CHECK, or it is
> superfluous (I have not tracked down).  But it makes no sense
> outside AC_CACHE_CHECK.

Ouch, you're right.

> | +ac_exeext=$ac_cv_exeext
> | +EXEEXT=$ac_cv_exeext
> | +AC_SUBST(EXEEXT)
> 
> Don't hesitate to promote this instead:
> 
> AC_SUBST(EXEEXT, $ac_cv_exeext)

Ok.

> I tend to agree with Pavel: it's a bit hard to track down the
> setting of ac_cv_exeext.  Personally I would favor that you use
> *only* ac_exeext in the body of AC_CACHE_CHECK, [...]

Ok.

> It should be clearer, and shorter.  Well, I think :)

Agreed.

> |  ** AC_EXEEXT, AC_OBJEXT
> | -We need a good implement.  As much as possible, they should not depend
> | -upon AC_EMXOS2 etc.
> | +These should be AC_REQUIRE'd where $ac_exeext and $ac_objext is used.
> 
> Hm, I don't understand this.  Well, I do, but the macros which use
> these guys also use AC_PROG_CC (or some other), which are in charge
> of calling them.  Are there macros which don't
> AC_LANG_COMPILER_REQUIRE but that depend upon $ac_exeext or
> $ac_objext?

Perhaps not. I don't have the spare time now to do the necessary
police work to check that neither $ac_objext nor $ac_exeext is used
before they are set, I'm afraid.

(BTW, couldn't a simple test for this be to initially set those
variables (in _AC_INIT_DEFAULTS) to something which would produce
invalid filenames and then see what happens? Hmm.)

Regards,
Morten

exeext5.diff
Description: Text document