On 1/8/2014 15:32, Alex.Burton@stripped wrote:
> - We've got a big leg up on the conversion, thanks to Alex Burton.
> Only a small leg up - there is a lot more work to replicate all the
> existing build system does.
Simply having a scaffolding to start from is a huge help.
It's like the difference between being dropped in the middle of a big
foreign city at night, and being dropped in the same place in the same
city during the daytime, with a hand-drawn map. Ideally, it's the same
amount of work to get to a given destination either way, but mishaps are
less likely in the second scenario.
> Could you just distribute binaries for visual studio versions ?
Possibly. I think it depends on how compatible Visual C++ DLLs are
across Visual C++ versions. Between ABI changes, name mangling rule
extensions, and ties to specific RTL DLLs, I wouldn't expect a DLL built
with Visual Studio 2013 to be able to link against programs built with
older versions of VC++.
(I tried Googling, but didn't find anything but recommendations for
extern "C" and C++/CLI.)
My company skipped over VS2010 and VS2012, since we had no need to
upgrade from VS2008 until late last year. (I did an F# project, and
thus had a good excuse to get VS2013.)
VSE2010 and VSE2012 are fine for MySQL++ compatibility testing, which is
the main reason I bothered to download them. But, they won't build
64-bit executables, which means I'd probably be forced to farm out
creation of the Visual C++ binary package.
Does VC++ have C++ DLL *forward* compatibility, to speak of? I mean,
can I build a MySQL++ DLL with VC++ 2008 and expect it to link against
programs built in VC++ 2010-2013? Or do I have to build separately with
all tools in between, if I want it to be compatible with every version?
> Instructions for building from source on windows:
> Download and install python 2.x.
> Download and install scons.
> Run a batch file that sets up their PATH by searching for where they installed
> python, if it is not already in their PATH.
> The batch file then calls scons -j <number of processors>.
> Because SConstruct can be written to not depend on OS environment variables, very
> little can go wrong, you can search for or ask them where mysql lib and inlude are, what
> version of VS to use if necessary etc.
This is pretty much as I expected.
While not exactly onerous, this is still more difficult than "Open .sln
file, say Build All".
> - Because SCons replaces everything in the current build system, we'd
> have to port all the autoconf tests and custom flags
> (--enable-thread-check, --with-mysql, etc.) over to it, then document
> all the build system changes. This will cause some work for the kind
> souls who maintain the various MySQL++ binary packages.
> On *ix platforms you could continue calling those configure tools unless you wanted
> to replace them.
Yes, I suppose that's true.
In fact, it would let us write the main scons file as SConstruct.in, so
autoconf can sub in the version number.
> I don't use it in that way but it appears that scons also has special
> support for Configuration see "Configure Contexts" in
Actually, this is where I got confused. I saw this during my survey
yesterday. This feature is an alternative to Autoconf.
Nevertheless, you're correct that the existence of this feature doesn't
prevent you from using Autoconf with SCons.