<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/qbs.git/src/lib/buildgraph/tst_buildgraph.cpp, branch dynablaster</title>
<subtitle>code.qt.io: qbs/qbs.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/qbs.git/'/>
<entry>
<title>Some minor improvements to the Error class.</title>
<updated>2013-06-18T08:57:25+00:00</updated>
<author>
<name>Christian Kandeler</name>
<email>christian.kandeler@digia.com</email>
</author>
<published>2013-06-14T08:57:38+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/qbs.git/commit/?id=b1d926024ddded2a43cc182c2d97839bb528def4'/>
<id>b1d926024ddded2a43cc182c2d97839bb528def4</id>
<content type='text'>
- Rename "Error" to "ErrorInfo", to make clear that this class conveys
information about errors, including that there might not actually be
one.
- Rename "ErrorData" to "ErrorItem", to make clear that these are parts
of an aggregate structure.
- Introduce ErrorInfo::hasError() for quick checking of whether an error
occurred.

Change-Id: Icea6ed5240d6d14bd30e9cea189c6babd7004792
Reviewed-by: Joerg Bornemann &lt;joerg.bornemann@digia.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Rename "Error" to "ErrorInfo", to make clear that this class conveys
information about errors, including that there might not actually be
one.
- Rename "ErrorData" to "ErrorItem", to make clear that these are parts
of an aggregate structure.
- Introduce ErrorInfo::hasError() for quick checking of whether an error
occurred.

Change-Id: Icea6ed5240d6d14bd30e9cea189c6babd7004792
Reviewed-by: Joerg Bornemann &lt;joerg.bornemann@digia.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove structural redundancy in project and product classes.</title>
<updated>2013-04-12T12:19:12+00:00</updated>
<author>
<name>Christian Kandeler</name>
<email>christian.kandeler@digia.com</email>
</author>
<published>2013-04-08T16:18:16+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/qbs.git/commit/?id=1d9c080428dcd5e8c1d08598d6542d87f1ca1819'/>
<id>1d9c080428dcd5e8c1d08598d6542d87f1ca1819</id>
<content type='text'>
We had two project classes, each holding a list of products
that was structurally identical, except that no BuildProduct
object existed for a disabled ResolvedProduct. The same kind
of duplication also happened for product dependencies.
This patch gets rid of these parallel structures. BuildProject
and BuildProduct are largely being demoted to data holders and are
aggregated by ResolvedProject and ResolvedProduct, respectively.
The resulting project structure should be easier to understand
and maintain.

Change-Id: I68beef60b9e0d62258f6a8337c9015864e18bd80
Reviewed-by: Joerg Bornemann &lt;joerg.bornemann@digia.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We had two project classes, each holding a list of products
that was structurally identical, except that no BuildProduct
object existed for a disabled ResolvedProduct. The same kind
of duplication also happened for product dependencies.
This patch gets rid of these parallel structures. BuildProject
and BuildProduct are largely being demoted to data holders and are
aggregated by ResolvedProject and ResolvedProduct, respectively.
The resulting project structure should be easier to understand
and maintain.

Change-Id: I68beef60b9e0d62258f6a8337c9015864e18bd80
Reviewed-by: Joerg Bornemann &lt;joerg.bornemann@digia.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Build a shared library.</title>
<updated>2013-02-08T16:29:16+00:00</updated>
<author>
<name>Christian Kandeler</name>
<email>christian.kandeler@digia.com</email>
</author>
<published>2013-02-07T16:31:59+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/qbs.git/commit/?id=a0442f40968da79b4b0e50e665a8885b78769df7'/>
<id>a0442f40968da79b4b0e50e665a8885b78769df7</id>
<content type='text'>
We don't want our code to be duplicated in memory for each application
that uses it, so the library should not be linked statically.
Some ramifications worth mentioning:
    - The unit tests had to be moved into the library,
      because otherwise we would need to export random
      internal symbols. This is why the patch appears so big.
      A follow-up patch should probably make compilation
      of tests optional, so the library can be deployed without
      unneeded code.
    - The DESTDIR of the auto test executables is now the
      same as the one of all other executables, so they
      can all use the dll on Windows without additional
      setup.
    - Some internal symbols were exported, namely:
          a) Logging-related stuff. This allows us to use
             a uniform logging approach in the library and in
             our command-line tools; I consider this acceptable.
          b) A handful of classes and functions currently needed
             by certain command-line tools. These seem more questionable
             to me and we should probably find a different way to implement
             the respective functionality.

Change-Id: I9cd21e12cd622b55cf62f5e04ad398734410ede1
Reviewed-by: Joerg Bornemann &lt;joerg.bornemann@digia.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We don't want our code to be duplicated in memory for each application
that uses it, so the library should not be linked statically.
Some ramifications worth mentioning:
    - The unit tests had to be moved into the library,
      because otherwise we would need to export random
      internal symbols. This is why the patch appears so big.
      A follow-up patch should probably make compilation
      of tests optional, so the library can be deployed without
      unneeded code.
    - The DESTDIR of the auto test executables is now the
      same as the one of all other executables, so they
      can all use the dll on Windows without additional
      setup.
    - Some internal symbols were exported, namely:
          a) Logging-related stuff. This allows us to use
             a uniform logging approach in the library and in
             our command-line tools; I consider this acceptable.
          b) A handful of classes and functions currently needed
             by certain command-line tools. These seem more questionable
             to me and we should probably find a different way to implement
             the respective functionality.

Change-Id: I9cd21e12cd622b55cf62f5e04ad398734410ede1
Reviewed-by: Joerg Bornemann &lt;joerg.bornemann@digia.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
