List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:January 9 2014 1:20am
Subject:Re: Next MySQL++ build system
View as plain text  
On 1/8/2014 16:07, Pau Garcia i Quiles wrote:
>
> qmake is a dead project.

Thanks.  I will drop it from consideration.

> It will be replaced sooner than later withs qbs.

Will qbs support the same set of development tools as qmake?

I'd like the next MySQL++ build system to work with VS2003+, so that 
build tools don't force us to drop platforms that the library proper 
supports today.

If I can only get VS2005+, that's okay, since VS2003 already has one 
known compatibility problem with MySQL++ 3.x.

> For a CMake build system to
> work, whoever wants to compile your source needs to have CMake.

That effectively removes the last of SCons' cons.

(Leaving S. :) )

If neither SCons nor CMake can create a MySQL++ source distribution 
package that can be built with only Makefiles or project files, I either 
have to give up on moving from Bakefile, or give up on this feature.

> The CMake scripting language is simple and not that ugly.

It looks like the illegitimate love child of COBOL and Bourne shell.

http://goo.gl/ofyKhj   Hurl, spew.  ;)

(Don't worry, I'm not going to reject CMake on this basis alone.  As I 
pointed out above, the current system is XML + Automake + M4 + shell. 
When I throw stones in this glass house, realize that it's because I 
find the sound of tinkling glass pretty. :) )

> As for possible to extend in-place, it is possible. Create a directory (e.
> g. "cmake"), write whatever code you want and do "set(CMAKE_MODULE_PATH
> ${CMAKE_MODULE_PATH} cmake)".

Aren't CMake extensions written in C++?  I guess that would mean you'd 
have to build the extension first, so a future MySQL++ that relied on 
such an extension could then build.

Less than ideal, but good to know it's possible.

> You will need to replace m4 macros with CMake versions.

I think this is like SCons, too: you *can* use CMake to replace 
Autoconf, but you don't have to.  Autoconf can create a CMakefile from a 
CMakefile.in, and MySQL++ can use the config.h emitted by the configure 
script.

Where we'd want to use the Autoconf replacement features of SCons or 
CMake is in those areas where we want the autoconfigurable feature to 
work on all platforms.  So, for example, the ability of MySQL++ to 
discover the location of the MySQL C API development files on *ix 
systems could be made to work on Windows, too.

> You can see an example of an autotools project ported to CMake (in order to
> make the port to Windows easy) here:
>
> https://www.assembla.com/code/zsync-windows/git/nodes/cmake/c

Thanks!

It's a lot to think about.

> CMake...is...the only true and sane universal Makefile generator

Why do you say that?  Is it just because SCons doesn't go through a 
Makefile intermediary, or is there something SCons doesn't do that makes 
for a fatal flaw, in your view?
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