Armin (currently fixing win32 build stuff), please make this change if it's appropriate. I've seen this pattern before so it probably is. Thanks, Philip.

I did not run accross this problem because I both did a mingw and msvc built, with the mingw one having generated config.h. However, if you did not run the configure script, how did you generate the glibmm.rc then (or, why didn't Visual Studio complain about it being missing)? I think this is normally generated from glibmm.rc.in, so you would need to run the configure script anyway.

Since SIZEOF_WCHAR_T is only used when GLIBMM_HAVE_WIDE_STREAM is defined, and the latter is not defined for MSVC, it is probably safe to simply not include config.h for MSVC. If we need it some day, then we could perhaps put it into glibmmconfig.h as GLIBMM_SIZEOF_WCHAR_T or something.

The package comes with the .rc files in the distribution.  Look at the AC_CONFIG_FILES section of the configure.in.  You see the entry:

MSVC_Net2003/glibmm/glibmm.rc

That causes glibmm.rc to be built from .rc.in and causes glibmm.rc to be included in the distribution via make dist/distcheck.  There is also an (unneeded) entry
in the above directory's Makefile.am:

EXTRA_DIST = glibmmconfig.h glibmm.vcproj glibmm.rc


However, the glibmm.rc includes both resource.h and afxres.h, neither of which
are in the distribution, so my workaround was simply to exclude glibmm.rc from the project and built without it.  The only consequence is the .dll is created without the:

VALUE "CompanyName", "The glibmm development team (see AUTHORS)"
VALUE "FileDescription", "The official C++ wrapper for glib"
VALUE "FileVersion", "2.17.2"
VALUE "LegalCopyright", "Distribution is under the LGPL (see COPYING)"
VALUE "OriginalFilename", "glibmm-2.4"
VALUE "ProductName", "glibmm"
VALUE "ProductVersion", "2.17.2"

information (no "Version" tab when you right-click on the dll).  That alone is may be regarded as a significant problem and I recommend fixing it.

Back to the original subject -- I simply wrapped the #include config.h with the HAVE_CONFIG_H guard to allow the compile to continue.

You mentioned that you used mingw to generate a configure for MSVC.  Each platform build mechanism should be complete and functionally independent, so you must test each one alone.

BTW, gtkmm and its subprojects all suffer from the .rc problem I describe in this comment.  They include the same non-existent files.  Deleting the resources is the workaround, but, again, the resulting .dll's contain no license/version/author info.   

Phil

I wanted to add that I was implicitly distinguishing the between the upstream maintainer who uses the gnu build system and 'make dist' to create a distribution tarball, from the end-user who wants to compile but may not have the gnu build system (e.g. an msvc user).

It's fine to use gnu for creating distributions (i do it all the time), but, if you support msvc, all the needed files for that build system must be packaged explicitly as well.

Cheers,

Phil 

I see. I built most stuff from SVN to be able to check in the changed project files, so I didn't notice the resource files are in the tarball (although I should, because it is in EXTRA_DIST). Thanks.

I already removed the "include resource.h" from all the resources (in SVN) because I had the same problem, and the resources build fine without. I didn't have a problem with the "afxres.h", though. Does it work for you if you remove both includes?

> I simply wrapped the #include config.h with the HAVE_CONFIG_H guard to
> allow the compile to continue.

I think I'll do the same for glibmm.

Armin,

I imported a fresh tarball of 2.17.2 into Microsoft Visual C++ 2008 Express SP1 and tried to rebuild.  After removing the include resource.h, it failed on include afxres.h.  After removing that include, I get many additional errors:

1>Compiling resources...
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>.\glibmm.rc(7) : error RC2144 : PRIMARY LANGUAGE ID not a number
1>.\glibmm.rc(32) : error RC2135 : file not found: VS_VERSION_INFO
1>.\glibmm.rc(33) : error RC2135 : file not found: 2
1>.\glibmm.rc(34) : error RC2135 : file not found: 2
1>.\glibmm.rc(35) : error RC2135 : file not found: 0x17L
1>.\glibmm.rc(41) : error RC2135 : file not found: FILEOS
1>.\glibmm.rc(42) : error RC2135 : file not found: 0x2L
1>.\glibmm.rc(45) : error RC2164 : unexpected value in RCDATA
1>.\glibmm.rc(47) : error RC2135 : file not found: BLOCK
1>.\glibmm.rc(49) : error RC2135 : file not found: VALUE

Not sure what is going on there.  I had to exclude the .rc from the project entirely.   

BTW this is the free version of MSVC.  Just download it from
http://www.microsoft.com/express/download/ and you should be able to reproduce these issues.

Regards,

Phil

Ok, I found and fixed the issue.  The underlying problem is that these MSVC 2008 Express editions do not ship with MFC and afxres.h is an MFC header.

If you remove the #include resource.h file (as you did) and replace 

#include <afxres.h>

with 

#include <windows.h>

then the resource compiler can compile the .rc file with no problems.

I hope this helps.

Phil

I committed the #ifdef HAVE_CONFIG_H ... #endif pair around #include <config.h>.

Thanks again for the resource thing. I will change the resource files accordingly in the relevant *mm projects.

(In reply to comment #2)
> Since SIZEOF_WCHAR_T is only used when GLIBMM_HAVE_WIDE_STREAM is defined, and
> the latter is not defined for MSVC, it is probably safe to simply not include
> config.h for MSVC.

MSVC++ doesn't support wide streams?  Even with recent versions?  Because if it does, GLIBMM_HAVE_WIDE_STREAM should definitely be defined.  Building without wide stream support cripples ustring::format() pretty badly, and I wouldn't recommend to build without it for anything but embedded systems...