List:MySQL++« Previous MessageNext Message »
From:Pau Garcia i Quiles Date:January 9 2014 8:51am
Subject:Re: Next MySQL++ build system
View as plain text  
On Thu, Jan 9, 2014 at 2:20 AM, Warren Young <mysqlpp@stripped> wrote:

 It will be replaced sooner than later withs qbs.
>>
>
> Will qbs support the same set of development tools as qmake?
>
>
It is expected to, yes. When? Nobody knows.

I do not like the JSON syntax qbs is using. IMHO JSON is fine for machines,
not for humans: forget a curly brace, comma or bracket here or there and
unexpected things will happen. Debugging that is not exactly easy. Also,
qbs does not have anything like CMake modules (at least, not yet)

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.
>
>
I fail to see the problem with requiring SCons or CMake. It's developers
who will be needing it, not final users. Developers should be able to use
development tools. Even more so in the case of a library which will need to
be integrated in other projects (which will in turn require a build
system).

Just provide a INSTALL.txt file with detailed instructions (which amounts
to: "unzip, run cmake-gui pointing source dir to the source dir and build
dir to an empty dir, click configure and compile the generated
makefile/solution/project").

 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.
>
>
No, there is no such thing as "CMake extensions".

There are "CMake modules" and they are written in CMake script. They cannot
be written in C++. They are usually called "FindXXX.cmake" when they are
used to find a third-party dependency (automagically finding the
third-party dependencies by means of find_package(mysql) or alike is one of
the most powerful features of CMake). E. g. KDE provides a library of
ready-made CMake modules called "Extra CMake Modules", you'll find a lot
more if you search GitHub or Gitorious:

https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository
https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository/revisions/master/show/attic/modules

You can also find a few modules in the zsync-windows repository I linked to
yesterday:

https://www.assembla.com/code/zsync-windows/git/nodes/cmake/c/cmake


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.
>
>
Why would you want to do that?

If you need to build an autotools project (or a project using some other
build system), you can also use the ExternalProject facilities in CMake. E.
g. I am perverting it in a project called winstng (
https://elpauer.assembla.com/code/winstng/git/nodes ) to build Wt (a C++
web framework) and all of its dependencies to generate a complete SDK.


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.
>
>
That makes no sense to me. Either you replace the whole build system, or
you don't. Mixing autotools and CMake/Scons like that spells disaster to me.

 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?
>
>
Last I checked, SCons did not generate Makefiles/Visual Studio solutions
but compiled code directly. That made the use of third-party tools (e. g.
distributed build with Incredibuild) difficult, or not plain impossible.
Also, debugging was much more difficult because you didn't have a VS
project.

In addition to that, back then (I have not checked recently), Scons did not
provide standard (i. e. bundled with it) modules for third-party
dependencies. CMake, on the other hand, provides a lot of these modules
(and many more are available in the Internets)



-- 
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