After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754082 - Since the C++11 changes made in 2.5, Visual Studio Solution Files for anything pre 2012 is pointless
Since the C++11 changes made in 2.5, Visual Studio Solution Files for anythin...
Status: RESOLVED FIXED
Product: libsigc++
Classification: Bindings
Component: build
2.5.x
Other Windows
: Normal enhancement
: ---
Assigned To: libsigc++ maintainer(s)
libsigc++ maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-08-25 14:00 UTC by Tony Bloomer
Modified: 2015-09-09 15:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Rename MSVC_Net2010/ to MSVC_Net2013/ (663.71 KB, patch)
2015-08-31 12:35 UTC, Fan, Chun-wei
committed Details | Review
Drop the MSVC 2005 and 2008 projects (408.42 KB, patch)
2015-08-31 12:35 UTC, Fan, Chun-wei
committed Details | Review
sigc++config.h.in: MSVC Builds: Define noexcept for MSVC 2013 (1.10 KB, patch)
2015-09-02 05:03 UTC, Fan, Chun-wei
committed Details | Review
patch: Update source of web page (14.49 KB, patch)
2015-09-07 17:29 UTC, Kjell Ahlstedt
committed Details | Review

Description Tony Bloomer 2015-08-25 14:00:20 UTC
There seems little point shipping builds for vs2005 / vs2008 / vs2010 when those compilers don't support enough of c++11 to compile the code base.

As a side note, the documentation on the main web page is also a little misleading as it seems to imply that the library is compatible back to vs2003 which of course some versions are, just not the latest.
Comment 1 Kjell Ahlstedt 2015-08-27 17:20:03 UTC
> There seems little point shipping builds for vs2005 / vs2008 / vs2010 when
> those compilers don't support enough of c++11 to compile the code base.

I tried to add Chun-wei Fan <fanchunwei@src.gnome.org> to the CC list, but
Bugzilla did not accept that email address.
Chun-wei, if you see this, is it something you could fix? You've mentioned it
in the commit message of a previous commit you've made.
https://git.gnome.org/browse/libsigc++2/commit/?id=891fa89e82d59251a99184dc7bf46cb6c39291a5

I can certainly remove the MSVC_net2005 and MSVC_Net2008 directories. But what
about MSVC_Net2010? Can it just be renamed to MSVC_Net2012, or must some of
the files in that directory be changed?

> As a side note, the documentation on the main web page is also a little
> misleading as it seems to imply that the library is compatible back to
> vs2003 which of course some versions are, just not the latest.

I suppose you mean http://libsigc.sourceforge.net/.
Yes, that web page is out of date in several respects. See bug 67255 comment 24.
Murray, do you know how that web page can be changed?
Comment 2 Kjell Ahlstedt 2015-08-27 17:25:46 UTC
s/bug 67255 comment 24/bug 672555 comment 24/
Comment 3 Kjell Ahlstedt 2015-08-28 07:01:37 UTC
Attempting to add Chun-wei Fan to the CC list with another email address.
Comment 4 Fan, Chun-wei 2015-08-28 14:10:27 UTC
Hi,

It would be fine to just rename the folder to MSVC_Net2012.

However, since I tried to build glibmm a couple of weeks ago, MSVC 2013 is needed to build that.  So, I'm not sure whether we still want to support pre-2013 MSVC as a result, unless other non-GNOME projects are using libsigc++, and it still supports non-C++11 compilers.

With blessings.
Comment 5 Kjell Ahlstedt 2015-08-28 16:34:30 UTC
libsigc++ now requires some C++11 support from the compiler.
If MSVC 2012 supports C++11 well enough to be able to build and use libsigc++,
it's meaningful to keep an MSVC_Net2012 directory even if MSVC 2012 can't build
glibmm. I'm almost certain there are non-Gnome projects that use libsigc++.
Comment 6 Fan, Chun-wei 2015-08-31 11:20:10 UTC
Hi,

Apparently more changes went in lately, so MSVC 2012 is not enough to build libsigc++, so the -mm stack will now require at least MSVC 2013.

I will update the projects again, and I found that they need some pretty significant overhauling...such as some projects are not properly configured for x64 builds, for instance, and they have too much baggage from the MSVC 2003 days.

With blessings.
Comment 7 Fan, Chun-wei 2015-08-31 12:35:11 UTC
Created attachment 310350 [details] [review]
Rename MSVC_Net2010/ to MSVC_Net2013/

Hi,

I have updated the MSVC 2012 projects to the 2013 projects, and gave them the makeover needed, so that they should now be cleaner and should build properly under x64 configs, in commit ae3913e.

I will upload 2 patches to complete the makeover required for this bug, and this patch is the first one, to rename MSVC_Net2010/ to MSVC_Net2013.

With blessings!
Comment 8 Fan, Chun-wei 2015-08-31 12:35:44 UTC
Created attachment 310351 [details] [review]
Drop the MSVC 2005 and 2008 projects

.
Comment 9 Kjell Ahlstedt 2015-09-01 08:12:46 UTC
I suppose you can push those two patches without asking, like you often do
with patches that only affect MSVC.
I applied them and successfully ran make distcheck.
Comment 10 Fan, Chun-wei 2015-09-02 05:03:37 UTC
Created attachment 310460 [details] [review]
sigc++config.h.in: MSVC Builds: Define noexcept for MSVC 2013

Hi Kjell,

Thanks!  I pushed these two patches as follows:

-Attachment 310350 [details]: a40ef84
-Attachment 310351 [details]: 78b4e71

Plus, since there are other items needed, so there are some other commits here as well for MSVC Builds:

-58c3a4a: "MSVC Builds: Add Forgotten Files", as I forgot to
 dist the property sheets, sorry!
-133a41d: "MSVC Builds: Use Windows Line Endings for .sln"

It also seems that sigc++ is also using noexcept, so sigc++config.h.in needs to be updated as well.  Note that a macro needs to be defined before we can try to define noexcept to _NOEXCEPT, which will also apply for glibmm.

Just out of curiosity (since I am heading out for a bit, I will also double-check later), is sigc++config.h included by the other -mm projects before doing their uses of noexcept?  If so, we could just do this #define here without touching the other projects.

With blessings, thank you!
Comment 11 Kjell Ahlstedt 2015-09-06 15:25:22 UTC
Review of attachment 310460 [details] [review]:

This is yet another patch that only affects compilation with MSVC. I suppose you
can push it without asking. You seem to know much more about MSVC than Murray and
me. I don't know how much Murray has permitted you to modify without asking.

> Is sigc++config.h included by the other -mm projects before doing their uses
> of noexcept?
No, there's no guarantee. But many glibmm files include sigc++ files that include
sigc++config.h. And many files in other mm projects include glibmm files.
Comment 12 Kjell Ahlstedt 2015-09-07 17:29:53 UTC
Created attachment 310853 [details] [review]
patch: Update source of web page

> I suppose you mean http://libsigc.sourceforge.net/.
> Yes, that web page is out of date in several respects.

This patch updates the files in libsigc++2/docs/website. I can push it to git,
but I don't know how to upload it to sourceforge. It would be great, if someone
with a sourceforge account could do that.
Comment 13 Murray Cumming 2015-09-08 19:30:34 UTC
Thanks. I've pushed that to git and done "make post-html" in docs/website to push it to the website.
Comment 14 Murray Cumming 2015-09-08 19:32:14 UTC
Yes, you can always make changes to MSVC++ projects without approval. It would be nice to check changes to other files beforehand.
Comment 15 Fan, Chun-wei 2015-09-09 08:59:28 UTC
Review of attachment 310460 [details] [review]:

Hi Kjell,

Thanks for the reviews, the patch was pushed as b695f22.

With blessings, thank you!
Comment 16 Fan, Chun-wei 2015-09-09 09:39:02 UTC
Hi,

Oh, by the way, the test programs do build and run successfully on Visual Studio 2013 builds, so should I go ahead and update the README file, before I go ahead to close this bug?

With blessings, thank you!
Comment 17 Murray Cumming 2015-09-09 11:00:37 UTC
Please go for it. Thanks.
Comment 18 Fan, Chun-wei 2015-09-09 15:40:23 UTC
Hi Murray,

Thanks, I just did that in commit d1f3523, so I think it is good to close this bug now.

With blessings.