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

[Peter Rosin]

Peter Rosin skrev:
> Ralf Wildenhues skrev:
> > 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'm sure I can read up on that in a number of git resources on the
> web. Is there anything I should be aware of that is special for
> libtool? But feel free to recommended a git tutorial...

Ok, managed to push this patch. I think anyway...

> > 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.
>
> dllimport is only needed on variables, functions work just fine to
> import on MSVC as well (at least I think so). So the naming
> LIBA_SCOPE and LIBA_SCOPE_VAR is perhaps a bit misleading since they
> are both used for variables. Also, in what cases do you need the
> dllimport for gcc? I don't seen any pattern. Sure, const seems to
> be involved, but if not dllimporting variables doesn't always work,
> isn't it a support nightmare to only recommend dllimport when it's
> desperately needed?

I was confused by const char v8[] which is apparently dll-auto-imported
by gcc even if it's const.

Oh well, I thought a bit about it and you can view it as if LIBA_SCOPE_VAR
is used for variables that truely are variable (i.e. non-const).

Please let me know if I got anything wrong in the push.

Cheers,
Peter