List:MySQL++« Previous MessageNext Message »
From:Pau Garcia i Quiles Date:January 8 2014 11:07pm
Subject:Re: Next MySQL++ build system
View as plain text  
Hello,

qmake is a dead project. It is so broken its maintainer (Oswald
Buddenhagen) only fixes critical bugs and it is no longer being developed.
It will be replaced sooner than later withs qbs. Do not even consider qmake.

CMake provides cross-platform and cross-compilation facilities. It is also
the only true and sane universal Makefile generator. As for Visual Studio
support, it's there but it will only be enabled from a Visual Studio
command prompt (cmd.exe or PowerShell).

The fact that you want to use the VS generator on Ubuntu makes me think you
have misunderstood how CMake works: it's not like autotools, where you have
.in files that you use as the input to autoconf/automake/... and then you
distribute the output autotools generated. For a CMake build system to
work, whoever wants to compile your source needs to have CMake. You cannot
generate VS solutions and projects, GNU Make makefiles, etc and put them in
the tarball. CMake-generated makefiles/solutions/etc are not relocable.
Having CMake is no big deal, I must say.

The CMake scripting language is simple and not that ugly. There is a fork
which replaces the scripting language with JavaScript. I don't like it.

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)".

You will need to replace m4 macros with CMake versions. Most of them are
already bundled with CMake, others can be obtained from other 3rd-party
projects.

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

(the autotools build system is still there, although it is not needed; I
should have deleted it)





On Wed, Jan 8, 2014 at 5:10 AM, Warren Young <mysqlpp@stripped> wrote:

> Thanks to Alex Burton's prompting[1] I'm considering replacing the current
> Bakefile based build system with something else.
>
> Bakefile Pros
> ~~~~~~~~~~~~~
>
> Bakefile does many things right:
>
> - It is not a build system in and of itself.  It is a Makefile and project
> file generator, which means MySQL++ end users do not need Bakefile to build
> MySQL++.  They use the native tools they already have and know.  I very
> much want to retain this feature.
>
> - It builds and runs on the systems I use to create distribution tarballs.
>  Because Bakefile is not a prerequisite to building from a distribution
> tarball, its portability problems are largely immaterial.
>
> - Only one MySQL++ platform has a large chunk of end users with a good
> reason to rebake MySQL++: Windows, since the distributed project and
> Makefiles necessarily have hard-coded C API paths in them.  But, Bakefile
> has an official binary installer package for Windows, so once again, there
> is no real portability or availability problem.
>
> - It ships with enough project and Makefile generators that it covers
> every common platform.
>
>
> Bakefile Cons
> ~~~~~~~~~~~~~
>
> I am considering replacing Bakefile because it is not without problems:
>
> - It doesn't support MSBuild flavored Visual Studio projects, so people
> have to convert the Visual Studio 2008 projects to the version they're
> actually using, a process that doesn't always go as smoothly as it should.
>  (Ultimately, this is Microsoft's fault, but we have to deal with the
> fallout of their failure to do the conversion properly.)
>
> - Ugly, verbose XML syntax
>
> - Extensibility requires modifying the local Bakefile setup.  Since I
> don't want to ship Bakefile extensions, it means it is effectively
> inextensible short of getting patches into upstream.
>
> - Uncommon, hence not available everywhere in binary form, and it doesn't
> build from source everywhere.  If Python 2.x ever dies out, Bakefile will
> likely die, too.
>
>
> So, What Next?
> ~~~~~~~~~~~~~~
>
> The SCons wiki has a great comparison of competing build tools[2]. Having
> read through it, I still think only SCons and CMake are suitable
> replacements for Bakefile, as used by MySQL++.  Every other alternative
> either has too many limitations or problems.
>
> Of those rejected, only qmake looks like it might actually be a good fit
> for a Bakefile replacement.  The only reason it isn't under consideration
> is that I ran out of time while evaluating CMake and SCons to study qmake.
>
> If anyone reading this thinks I have unfairly overlooked another suitable
> alternative, please let me know about it.
>
>
>
> SCons Pros
> ~~~~~~~~~~
>
> - Clean, powerful Python based DSL.
>
> - Because the SConstruct file is Python, any code we'd have to write to
> port over all the features we get in the current build system will travel
> with MySQL++.  (This is why effective inextensibility is on the list of
> Bakefile cons above.)
>
> - Runs the same on all platforms.
>
> The current MySQL++ build system abstracts the platform differences at the
> Bakefile level, but because it generates native Makefiles and project
> files, different platforms have different features.  e.g. Debug vs Release
> builds on VS and Xcode, but not on MinGW or Autoconf.  Or easy toggling of
> threads and static libraries on Autoconf, but not on the other platforms.
>
> - We've got a big leg up on the conversion, thanks to Alex Burton.
>
>
> SCons Cons ons ns s ()    [3]
> ~~~~~~~~~~~~~~~~~~~~~~
>
> - It is the entire build system.  This means it is a prerequisite to
> building MySQL++ from source for everyone except perhaps the Visual Studio
> users.  (See next item.)  With Bakefile and CMake, only core developers or
> those who want to hack on the MySQL++ build system need the nonstandard
> tool.  I'm not sure I can accept this.
>
> - The front page of the SCons web site says there is a way to make it
> generate VS project files, but I don't see a section on it in the user
> guide[4].  Everything I've seen on this talks about Visual Studio 6 vs 7,
> which is ancient history.  I care about VS2003-2008 vs VS2010+.  If we
> can't get it to spit out VS2010 files at minimum, there isn't much point in
> switching to SCons, since I don't want to go telling Windows users they
> have to install SCons first, and that they have to build MySQL++ from the
> command line.  Some will be fine with that, but it's a pretty anti-Windows
> stance to take.
>
> - 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.
>
>
> CMake Pros
> ~~~~~~~~~~
>
> - It is a make/project file generator like Bakefile, so normal end users
> don't have to have CMake unless they want to do something atypical. (e.g.
> set up out-of-tree builds on *ix systems.)
>
> - MySQL and MariaDB 5.5+ use CMake.  Clearly it has enough power to do
> anything MySQL++ will ever need.
>
> - Up-to-date Visual Studio support.  It already has explicit support for
> VS2013, which is only a few months old.
>
>
> CMake Uncertainties
> ~~~~~~~~~~~~~~~~~~~
>
> - Since it replaces Automake, does it make it harder to keep using
> Autoconf?  Will we be pushed into translating all the M4 tests and such
> into CMake syntax?
>
> - It replaces Libtool, which we switched to not that long ago to get
> relocatable libraries on some embedded platform or other.  (Adrian?) Does
> CMake give suitable output here, or are we going to have to manually
> integrate libtool into the CMake build on these platforms?
>
> - None of the binary CMake packages I've tried (CentOS, Ubuntu, Brew,
> Cygwin) include the Visual Studio generators!  I don't know why everyone is
> building CMake without these.  We'll need them.  Am I going to have to
> build CMake from source just to get this?
>
>
> CMake Cons
> ~~~~~~~~~~
>
> - Fairly ugly syntax.  Not as ugly as XML + Automake + M4 + shell, but not
> nearly as clean as SCons/Python.
>
> - Yet another programming language.  Worse, yet another *specialized*
> programming language that I will touch but once a year or so, so I will
> never develop any real expertise.  I already have Python skills, and
> there's at least a chance I will have other calls on those skills, so my
> SCons-fu won't deteriorate too much between uses.
>
> - Probably not possible to extend-in-place, as with SCons.  Like with
> Bakefile, I think you have to build and install a plugin in the local CMake
> setup, which means MySQL++ can never rely on doing this.
>
>
>
>
> Thoughts?  Comments?  Suggestions?
>
>
>
> ---------
> Footnotes:
>
> [1] http://lists.mysql.com/plusplus/9646
>
> [2] http://www.scons.org/wiki/SconsVsOtherBuildTools
>
> [3] Can you tell I've been using FP languages lately?
>
> [4] http://www.scons.org/doc/production/HTML/scons-user/
>
> --
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe:    http://lists.mysql.com/plusplus
>
>


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

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