Re: [patch #6448] [MSVC 7/7] Add MSVC Support

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Fri, Aug 08, 2008 at 11:42:11AM CEST:
> Peter Rosin skrev:
>>   31: export.at:25       Export test
>> Exporting variables.
>
> This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are
> still happy. Is there any reason for not __declspec(dllimport)ing all
> these variables?

Yes: the auto-dll-import feature (was it named that?) from GCC on Cygwin
and MinGW is happy to import all these variables automatically.

I would like to somehow ensure that we expose this auto-import feature;
IOW, that we don't explicitly dllimport these variables.  That way code
that is not portable to MSVC anyway, can rely on not needing these
annotations.  Sorry to be such a pain on this point, but the GNU Coding
Standards explicitly allow developers to not go out of their way in
making stuff work on w32, and as such they come to expect that things
work smoothly without these kinds of annotations (and I for one would
like to be able to pinpoint where exactly the limits are).

So can we do something like this in the test, what do you think?


/* w32 fun.  With GCC, you can have auto-import, which will work for
 * functions and non-const variables.  With MSVC, you have to explicitly
 * import all variables.  Depending on the amount of portability, you
 * need these annotations: LIBA_SCOPE for GCC, and also LIBA_SCOPE_VAR
 * for MSVC.  Of course you can merge both to one, this test only avoids
 * that in order to expose the auto-import feature on Cygwin.
 *
 * For users, it's best tor realize that they should not provide any
 * non-function API at all.
 */
#if defined(LIBA_DLL_IMPORT)
#  if defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__)
#    define LIBA_SCOPE extern __declspec(dllimport)
#  if defined(_MSVC)
#    define LIBA_SCOPE_VAR LIBA_SCOPE
#  endif
#  endif
#endif
#if !defined(LIBA_SCOPE)
#  define LIBA_SCOPE extern
#endif
#if !defined(LIBA_SCOPE_VAR)
#  define LIBA_SCOPE_VAR extern
#endif

and then add only LIBA_SCOPE_VAR annotations?  If you agree, then
a patch to the pr-msvc-support branch to this end is preapproved
(you know how to push changes to a branch?)

I haven't yet decided for myself whether I would like to see this
split-up in the other test failures too, but I would definitely like
to see it in export.at.  Maybe in stresstest.at too, but not in the
old-style testsuite.  I'm open to suggestions here though.

Cheers, and thanks,
Ralf

> 2008-08-08  Peter Rosin  <address@hidden>
>
>       * tests/export.at [cygwin, mingw]: dllimport all imported
>         variables.

> diff --git a/tests/export.at b/tests/export.at
> index 73fb45f..4f9d012 100644
> --- a/tests/export.at
> +++ b/tests/export.at
> @@ -104,21 +104,21 @@ AT_DATA(main.c,
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> -extern int v1;
> -extern int v3, v4;
> +LIBA_SCOPE int v1;
> +LIBA_SCOPE int v3, v4;
>  LIBA_SCOPE const int v5, v6;
> -extern const char* v7;
> -extern const char v8[];
> +LIBA_SCOPE const char* v7;
> +LIBA_SCOPE const char v8[];
>  extern int v9(void);
> -extern int (*v10) (void);
> -extern int (*v11) (void);
> +LIBA_SCOPE int (*v10) (void);
> +LIBA_SCOPE int (*v11) (void);
>  LIBA_SCOPE int (*const v12) (void);
>  #ifdef __cplusplus
>  }
>  #endif
>  
>  typedef struct { int arr[1000]; } large;
> -extern large v13, v14, v15;
> +LIBA_SCOPE large v13, v14, v15;
>  
>  int main (void)
>  {