|
From: | Ken Raeburn |
Subject: | Re: deprecated symbol warnings and Windows |
Date: | Wed, 18 May 2005 15:18:48 -0400 |
On May 14, 2005, at 08:40, Neil Jerram wrote:
The warnings can be disabled while building guile (only while building deprecated.c, I hope) so that -Werror doesn't kill the build.In the header files, here's how it's taking shape, roughly: #if defined(SCM_DISABLE_DEPRECATION_WARNINGS) # define SCM_DECL_DEPRECATED /* empty */ #elif __GNUC__ >= 3 # define SCM_DECL_DEPRECATED __attribute__((deprecated)) #elif defined _WIN32Does the __declspec syntax work for all Windows compilers? If it's actually specific to MSVC (which is the only compiler I'm familiar with), you should use _MSC_VER. If it's for all Windows compilers, I'm surprised by the underscore - i.e. I'd normally use WIN32; are WIN32 and _WIN32 equivalent?
I've done a bit more investigating, and it appears that __declspec(deprecated) is new with Visual Studio 2003, or maybe 2002. So there would be no warning with older compilers, probably. (And the older compiler we've been using at work defines _WIN32 but not WIN32.) For now, in my code, I'm testing _MSC_VER >= 1310.
In looking at the current headers, I think when I'm changing macros into functions, I need to stick "SCM_API" in front where I'd use "extern" normally, to get the Windows DLL import/export specs right? So this conversion will actually be adding to the exported-symbol list of the DLL. (Has anyone thought about limiting exported symbols on UNIX?) I've just gotten access to the newer compilers, so I should be able to run some tests any make sure I've gotten the syntax right for multiple declspecs etc.
Oh, and based on the discussions, I'm sticking with the "#define foo foo" form for now, rather than renaming symbols.
Ken
[Prev in Thread] | Current Thread | [Next in Thread] |