Hi,

On Wed, Feb 25, 2015 at 09:47:06PM +0300, Vladislav Ivanov wrote:
> When C++ bindings for libsigrok are enabled, cross-compilation for Windows 
> currently fails because of a macro name conflict:
[...] 
> The problem is RELATIVE and DIFFERENCE are replaced to integer constants by a 
> preprocessor. Both macros are defined in windows-specific includes:
> 
> wingdi.h:
> /* Coordinate Modes */
> #define ABSOLUTE            1
> #define RELATIVE            2
> 
> winuser.h:
> 
> #define RT_RCDATA           MAKEINTRESOURCE(10)
> #define RT_MESSAGETABLE     MAKEINTRESOURCE(11)
> #define DIFFERENCE     11
> 
> One of possible solutions is to undefine these macros in each generated enum 
> file, and another to rename enum values. This patch implements the former:
> 
> diff --git a/bindings/cxx/enums.py b/bindings/cxx/enums.py
> index aed4212..5d7e50e 100644
> --- a/bindings/cxx/enums.py
> +++ b/bindings/cxx/enums.py
> @@ -70,7 +70,11 @@ code = open(os.path.join(outdirname, 'enums.cpp'), 'w')
>  swig = open(os.path.join(dirname, '../swig/enums.i'), 'w')
> 
>  for file in (header, code):
> -    print("/* Generated file - edit enums.py instead! */", file=file)
> +    print("/* Generated file - edit enums.py instead! */\n"
> +         "#ifdef WIN32\n"
> +         "#undef DIFFERENCE\n"
> +         "#undef RELATIVE\n"
> +         "#endif\n", file=file)
> 
>  # Template for beginning of class declaration and public members.
>  header_public_template = """
> 
> This is a bit messy. Not as messy as WinAPIs macro naming, though. This 
> (alongside with configure.ac fix) should fix Windows build.

Yup, it's all a bit messy. Please check this bug:

http://sigrok.org/bugzilla/show_bug.cgi?id=517

The build used to work a while back, I *think* what caused this is some
newer version of Boost which apparently now has some additional
#includes of Windows headers in their own .h(pp) files. Just a guess though.

I'd like to be sure about the actual source of the problem first (i.e. is it a
Boost related bug or MinGW/MXE related bug or sigrok related bug?).
Also, the NOGDI mentioned in the bugreport should be tested, might be
the nicer alternative if it does what we want, otherwise in a few weeks
some other macro will conflict again and we need to #undef even more stuff.

If NOGDI or something similar does work, the question still remains
where it needs to be placed correctly - in Boost headers, MinGW headers,
or libsigrok headers?


Uwe.
-- 
http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Reply via email to