List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:January 9 2014 12:05am
Subject:Re: Next MySQL++ build system
View as plain text  
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
> http://www.scons.org/doc/HTML/scons-man.html

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.
Thread
Next MySQL++ build systemWarren Young8 Jan 2014
  • Re: Next MySQL++ build systemWarren Young8 Jan 2014
  • RE: Next MySQL++ build systemAlex.Burton8 Jan 2014
    • Re: Next MySQL++ build systemWarren Young9 Jan 2014
      • Re: Next MySQL++ build systemPau Garcia i Quiles9 Jan 2014
        • Re: Next MySQL++ build systemWarren Young9 Jan 2014
          • Re: Next MySQL++ build systemPau Garcia i Quiles9 Jan 2014
            • Re: Next MySQL++ build systemWarren Young9 Jan 2014
  • Re: Next MySQL++ build systemPau Garcia i Quiles8 Jan 2014
    • Re: Next MySQL++ build systemWarren Young9 Jan 2014
      • Re: Next MySQL++ build systemPau Garcia i Quiles9 Jan 2014
        • Re: Next MySQL++ build systemWarren Young9 Jan 2014
          • Re: Next MySQL++ build systemPau Garcia i Quiles9 Jan 2014
            • Re: Next MySQL++ build systemWarren Young9 Jan 2014