libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests: import variables for MSVC.


From: Ralf Wildenhues
Subject: Re: [PATCH] tests: import variables for MSVC.
Date: Fri, 24 Sep 2010 20:56:15 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

* Peter Rosin wrote on Fri, Sep 24, 2010 at 02:44:25PM CEST:
> Den 2010-09-24 07:21 skrev Ralf Wildenhues:
> > Patch is ok with me if it keeps GCC working, and Chuck is ok with it.
> > You meant to use __declspec everywhere not declspec, even in your text
> > part of the mail, right?
> 
> Yes indeed, I intended __declspec.  I have revised the patch so that it
> handles "building" correctly (dllexport for dlls, not for static) and
> "using" the best way possible (still dllimports from from both dlls and
> static libs).  For Cygwin I removed some dead code in tests/pdemo,
> similar code was deleted from tests/demo back in 2002 (see commit
> 45d16ee8bf4559d6b976bfd4d6482767f16eac95).  I have verified that the
> Cygwin related cleanup does not affect the Cygwin testsuite results.

I'll let Chuck and you hash out and decide all the details on this.

One question though: will all of these '#ifdef _MSC_VER' cases need
changing as soon as we add support for yet another w32 compiler?  In
that case, I think the strategy should be reconsidered.  The idea is
that the sources should ideally not need any, or at least not many,
changes in the future.  Relying on compiler defines seems like a
suboptimal strategy, and should only be done if there is no other way.

> With this patch, the old testsuite SKIPs cdemo-undef and tagdemo-undef,
> FAILs demo-deplibs(1) and all the rest PASS (on MSYS/MSVC).  So it is
> looking really nice.

Cool.

> > A documentation addition describing the most general case of annotations
> > (multiple libraries, mixed static/shared, full MSVC + everything else
> > support) plus simplifications for common cases,
> > - no MSVC,
> > - no shared/static mixing,
> > - rely on auto-import,
> > - ...
> > 
> > would be good to have.  Something from which I can deduce that your
> > patch must be correct.
> 
> That documentation would be nice, yes, and I plan to write something about
> that eventually.  Is it a prerequisite for pushing this?

No.

But alongside the documentation, it would be good to have at least some
testsuite exposure for all the code that we recommend.  IOW, most of the
testsuite now works with MSVC and all, so it ought to follow more or
less the most general case of annotations.  Then, we should have a
couple of tests that simplify based on the assumption that we can rely
on auto-import; these tests should be skipped when auto-import is not
available, and they are for users whose code needs to rely on it anyway.
Then a couple of tests that assume static/shared mixing does not happen.
Etc.  So that we can rely on our documentation to remain accurate,
because we test it in the testsuite.

> > Also, may I remind you that you promised a number of testsuite additions
> > before the release.
> 
> I have been digging in the archives for quite a bit, but I'm only finding
> http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00266.html
> 
> What else have I promised?

Oh, s/you promised/y'all promised/   ;-)

Thanks,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]