This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: updated win32 macro




----- Original Message -----
From: "Akim Demaille" <akim@epita.fr>


> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au>
writes:
>
> Robert> It looks like the cc result is not used from cache - so I
> Robert> don't think this test should allow caching. Also I have a
> Robert> question on the caching: I need to cache _the change needed to
> Robert> CC_... Is that temporary variable automatically cached?
>
> If you ac_cv_ it, yes.  But never display a cache variable to the
> user.

Understood (now).

> You macro, indeed, is fragile to the changes of LANG.  I'm not sure
>
> AC_PROG_CC_WIN32
> AC_LANG(C++)
> AC_LANG(C)
> echo $ac_compile
>
> will display what you hope it would.  And actually, now that coffee
> suddenly breaks my mind free, I just understood you meant to do here:
>
> ac_cc_win32=yes
> ac_compile="$ac_compile -mwin32"
> ac_link="$ac_link -mwin32"
> CC="$CC -mwin32"
>
> this is `wrong'.  ac_compile and friends are not evaluated at their
> definition, but at their uses.  So you need not (and must not) change
> them at all.  Changing CC is a bad idea.  And BTW, my suggestion
> behind the C++ stuff was that, IMHO, you should not set CC, or maybe
> at least provide the user with a means to get the switch, say the
> variable $WIN32CFLAGS.

Ah, Well I answered a different question then :]

> AC_LANG_COMPILER_MWIN32([YES-WIN32], [NOT-WIN32])
>
> I would be able to write
>
> AC_LANG_COMPILER_MWIN32([CC="$CC $WIN32CFLAGS])
> CXX="$CXX $WIN32CFLAGS"
>

Ok problem here: that might not be valid for CXX. AFAIK it happens to be
on cygwin, but I can't vouch for other scenarios (WINE comes to mind
again). For that reason I suggest a separate test for each language.

I've copied from your next email to prevent us having 20 concurrent
threads..

> Then it seems to me that the interface is not right.  Maybe something
> like
>
> AC_HEADER_WINDOWS

Good suggestion. Then the developer can simply check for HAVE_WINDOWS_H
afterwards.. I like :]
What about the language specific issues? Or should AC_HEADER_WINDOWS
look for _every_ compiler that it knows how to set WIN32 on?

>
> which would do the whole thing might be what you need.  Also, why do
> you set CC and not CFLAGS (and maybe LDFLAGS)?  This is a tricky
> question, I often wondered, not only in the present case.
>

Because I misunderstood the ac_* variable vs the CAPITALISED ONES.
Does this mean I get to set CC again?

Rob



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]