This is confusing me but hopefully someone’ll be able to make sense of it…
Earlier today I did a git clone of libsigc++ and switched to the branch called origin/libsigc-2-4
This particular branch makes various use of a struct called sigc::is_base_and_derived - though AFAICT, no such struct exists. It looks like (in 2.4) it should be present in type_traits.h - but it isn’t there. And according to NEWS it looks like it got removed in version 2.5.2 and replaced with std::is_base_of. And yet the various source files still use it extensively… So I’m not sure if I’ve got 2.4 or something later…
[Edit…] Hmmm… leave it with me. I downloaded a 2nd time and this time I’m seeing std::is_base_of rather than sigc::is_base_and_derived so it looks like something went wrong the first time
The latest release of sigc++ v2 is 2.12, so if you need v2 that’d probably be what you want to use. If you need 2.4 specifically (perhaps you might explain your reasoning?), I’m sure you’d be better served by the actual release tarball at https://download.gnome.org/sources/libsigc++/2.4/libsigc%2B%2B-2.4.1.tar.xz rather than such an old git branch.
Thanks Andrew. The other devs here are using either 2.10 or 2.12 but my git version here was still at 2.3. So I decided to update but I figured I’d start off simply and just go to 2.4 as the first step. But what confused me was that updating to 2.4 seemed to include lots of stuff relating to later versions (according to the NEWS file anyway…)
e.g. according to NEWS, std::is_base_of didn’t get introduced until 2.5 - yet in the git branch for 2.4, it seems to be already there
I’ll try the source tarball later if I get a chance. But presumably dev libraries aren’t available any more?
Okay, I downloaded the source tarball for release 2.4.1. Obviously I can’t see any git entries but with regard to files like NEWS, its changes only go as far as 2.4.1 stable. Whereas in the git branch for libsigc-2-4, NEWS is showing entries going all the way up to 2.99.10
Another thing is that the non-git tarball contains files like lambda.cc and lambda.h which are missing from 2-4 git. And it contains .vcproj files for building with older versions of VC++ which are also missing from 2.4 git (presumably these all got removed sometime later?)
I can’t pluck up the courage to try switching to any other branch (2-8 or 2-10 etc) but as for the 2-4 branch in git, it looks like that one’s gotten badly corrupted somehow.
Git branches are for development; it is common for branches to have commits further along than any particular release. if you want the git commit for a particular release you need to use a tag. Unfortunately, the v2.4 tag is not available; development was moved from gnome.org to github in 2018, and the older tags don’t seem to have come along for the ride. If you read the git-log, however, you can see that release 2.4.1 was commit 90c1479, and contains files such as lambda.cc.m4.
The origin/libsigc-2-4 branch is pointing to commit 8116ff70, but that commit is also pointed at by origin/libsigc-2-2, origin/libsigc-2-0, origin/ligsigc+±2-8, origin/ligsigc+±2-10, origin/c++17, and many others. It is likely that this was simply the commit that was HEAD when development was moved to github and the branches from the old repo somehow defaulted to that commit. So, you should regard that branch as in no way representative of version 2.4.
Thanks again Andrew and that’s what I’m seeing here - so for version 2 code it’s looking like I’d be better off working from the relevant tarball, rather than from git.
So I built from the tarball for 2.10.8. I ran the command nmake /f Makefile.vc CFG-release and it built successfully - albeit as Win32. What would I need to change to get a Win64 build?
Also, that particular tarball contains 2 x sets of header files (one under the sigc++ folder and another under untracked/sigc++) but both sets are different and they both seem to have files missing. So I then tried building from the 2.10.2 tarball. The header files seem better in that one - but the nmake command fails and that version won’t build.
So it looks like I’m caught between a rock and a hard place here with absolutely nothing buildable from ver2.10. So can I just check again please … are there definitely no dev libraries available these days (for Windows)? A dev library would make this a whole lot simpler.
Woohoo!! After a bit of reading I realised that Visual Studio offers both a 32-bit Command Window and also 64-bit. And if I build 2.10.8 from within the 64-bit window it builds me 64-bit DLLs etc. So I then hit on another idea…
Going back to 2.10.2, I renamed the (non-working) MSVC_NMake folder and dragged across the working one from 2.10.8 - and bingo! I can now build 2.10.2. And so far, it all seems to work.
So I’m just left with one more question… the built modules ended up with the name sigc-vc140-2.0.lib (and dll). Is there some way I can specify a name I’d prefer? AFAIK libs and DLLs need to have the desired name specified at build time - i.e. they won’t work together if you rename them after building.
