Add support for overridding detected build system.

This is necessary in situations where the source includes more than one
build system (especially when only one of those actually works but
kdesrc-build auto-detects the other). The current example would be
libraptor.

doc/index.docbook

@@ -2032,6 +2032,46 @@ module if it normally would have tried anyways.</entry>
 due to fixes in the underlying build system.</entry>
 </row>
 
+<row id="conf-override-build-system">
+<entry>override-build-system</entry>
+<entry>Module setting overrides global</entry>
+<entry><para>This is an advanced option, added in &kdesrc-build; 1.16.</para>
+
+<para>Normally &kdesrc-build; will detect the appropriate build system to use
+for a module after it is downloaded. This is done by checking for the existence
+of specific files in the module's source directory.</para>
+
+<para>Some modules may include more than one required set of files, which could confuse
+the auto-detection. In this case you can manually specify the correct build type.</para>
+
+<para>Currently supported build types that can be set are:</para>
+
+<variablelist>
+    <varlistentry>
+        <term>KDE</term>
+        <listitem><para>Used to build &kde; modules. In reality it can be used to build
+            almost any module that uses &cmake; but it is best not to rely on this.</para></listitem>
+    </varlistentry>
+    <varlistentry>
+        <term>Qt</term>
+        <listitem><para>Used to build the &Qt; library itself.</para></listitem>
+    </varlistentry>
+    <varlistentry>
+        <term>qmake</term>
+        <listitem><para>Used to build &Qt; modules that use
+            <application>qmake</application>-style <literal>.pro</literal>
+            files.</para></listitem>
+    </varlistentry>
+    <varlistentry>
+        <term>generic</term>
+        <listitem><para>Used to build modules that use plain Makefiles and that do not
+            require any special configuration.</para></listitem>
+    </varlistentry>
+</variablelist>
+
+</entry>
+</row>
+
 <row id="conf-override-url">
 <entry>override-url</entry>
 <entry>Module setting overrides global</entry>

kdesrc-build

@@ -1614,6 +1614,7 @@ EOF
         "module-base-path"     => "",  # Used for tags and branches
         "niceness"             => "10",
         "no-svn"               => "",
+        "override-build-system"=> "",
         "override-url"         => "",
         "persistent-data-file" => "",
         "prefix"               => "", # Override installation prefix.
@@ -5178,6 +5179,28 @@ EOF
         return $self->scm()->currentRevisionInternal();
     }
 
+    # Returns a new build system object, given the appropriate name.
+    # This is a sub-optimal way to fix the problem of allowing users to override
+    # the detected build system (we could instead use introspection to figure out
+    # available build systems at runtime). However, KISS...
+    sub buildSystemFromName
+    {
+        my ($self, $name) = @_;
+        my $buildSystem;
+
+        given(lc($name)) {
+            when('generic')         { $buildSystem = GenericBuildSystem   -> new($self); }
+            when('qmake')           { $buildSystem = QMakeBuildSystem     -> new($self); }
+            when('cmake-bootstrap') { $buildSystem = CMakeBootstrapSystem -> new($self); }
+            when('kde')             { $buildSystem = KDEBuildSystem       -> new($self); }
+            when('qt')              { $buildSystem = QtBuildSystem        -> new($self); }
+
+            default { croak_runtime("Invalid build system $name requested"); }
+        }
+
+        return $buildSystem;
+    }
+
     sub buildSystem
     {
         my $self = shift;
@@ -5186,6 +5209,11 @@ EOF
             return $self->{build_obj};
         }
 
+        if (my $userBuildSystem = $self->getOption('override-build-system')) {
+            $self->{build_obj} = $self->buildSystemFromName($userBuildSystem);
+            return $self->{build_obj};
+        }
+
         # If not set, let's guess.
         my $buildType;
         my $sourceDir = $self->fullpath('source');