Menu ▾ ▴

#118 Remaining build system cleanups

Backlog
open
nobody
None
nobody
2024-05-05
2017-12-23
Ulf Lorenz
No
What and Why

This issue mainly collects leftovers from [#73] with low or unclear priority.

  • allow versioning of wavepacket builds; use-case a bit unclear
  • the Python tests are copied to the build directory as part of the CMake step. This should be a part of the testing step to avoid stale copies.
  • The demos could be installed as well
Acceptance criteria
  • Allow versioning of Wavepacket builds for the C++ library. Multiple versions can coexist, there is a default version reachable via symlinks (build script and library)
  • versioning of the Python modules
    • may be left out / postponed: allow, at least optionally, multiple WavePacket modules to coexist (e.g., by defining specific namespaces)
  • Fix: Changing the Python tests automatically updates the files in the binary directory

Related

Tickets: #73

Discussion

  • Ulf Lorenz

    Ulf Lorenz - 2019-02-17
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -8,6 +8,3 @@
 * deal with the annoying case of boost being more recent than CMake
     * annoying that you cannot use import targets from boost, and the warning is annoying, but so what?
     * Fix unclear
-* add script for automatic generation of movies from plots
-    * Wait for the result of [#117]. Maybe it is not needed afterwards.
-
     

    Related

    Tickets: #117

  • Ulf Lorenz

    Ulf Lorenz - 2019-08-15
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -8,3 +8,4 @@
 * deal with the annoying case of boost being more recent than CMake
     * annoying that you cannot use import targets from boost, and the warning is annoying, but so what?
     * Fix unclear
+* When you change the Python tests, you have to copy them manually to the folder (or delete and run cmake again). There should be a better and less error-prone way of doing this.
     

  • Ulf Lorenz

    Ulf Lorenz - 2019-12-29
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,11 +1,4 @@
 This issue mainly collects leftovers from [#73] with low or unclear priority.

-* allow versioning of wavepacket builds
-    * use case unclear: does anyone want that? do we want a version identifier, a free identifier, debug vs. release?
-* build debug and release builds together
-    * use case unclear: what for? Usually the developer has the debug build, the user / build system the release.
-    * How to distinguish between the two?
-* deal with the annoying case of boost being more recent than CMake
-    * annoying that you cannot use import targets from boost, and the warning is annoying, but so what?
-    * Fix unclear
+* allow versioning of wavepacket builds; use-case a bit unclear
 * When you change the Python tests, you have to copy them manually to the folder (or delete and run cmake again). There should be a better and less error-prone way of doing this.
     

    Related

    Tickets: #73

  • Ulf Lorenz

    Ulf Lorenz - 2019-12-29
    • Milestone: Backlog --> 0.3.1
     

  • Ulf Lorenz

    Ulf Lorenz - 2020-01-02
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,4 +1,12 @@
+#####What and Why#####
+
 This issue mainly collects leftovers from [#73] with low or unclear priority.

 * allow versioning of wavepacket builds; use-case a bit unclear
 * When you change the Python tests, you have to copy them manually to the folder (or delete and run cmake again). There should be a better and less error-prone way of doing this.
+
+#####Acceptance criteria#####
+
+* Allow versioning of Wavepacket builds for the C++ library. Multiple versions can coexist, there is a default version reachable via symlinks (build script and library)
+    * Note: no versioning for the Python builds, that seems completely useless.
+* Fix: Changing the Python tests automatically updates the files in the binary directory
     

    Related

    Tickets: #73

  • Ulf Lorenz

    Ulf Lorenz - 2020-01-02
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -8,5 +8,6 @@
 #####Acceptance criteria#####

 * Allow versioning of Wavepacket builds for the C++ library. Multiple versions can coexist, there is a default version reachable via symlinks (build script and library)
-    * Note: no versioning for the Python builds, that seems completely useless.
+* versioning of the Python modules
+    * may be left out / postponed: allow, at least optionally, multiple WavePacket modules to coexist (e.g., by defining specific namespaces)
 * Fix: Changing the Python tests automatically updates the files in the binary directory
     

  • Ulf Lorenz

    Ulf Lorenz - 2020-01-26
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -4,6 +4,7 @@

 * allow versioning of wavepacket builds; use-case a bit unclear
 * When you change the Python tests, you have to copy them manually to the folder (or delete and run cmake again). There should be a better and less error-prone way of doing this.
+* We could implement different exports for the library (wavepacket) and for the headers (wavepacket-dev). Use-case is equally unclear; probably most users will not need this distinction.

 #####Acceptance criteria#####

@@ -11,3 +12,4 @@
 * versioning of the Python modules
     * may be left out / postponed: allow, at least optionally, multiple WavePacket modules to coexist (e.g., by defining specific namespaces)
 * Fix: Changing the Python tests automatically updates the files in the binary directory
+* Optionally: implement different exports for wavepacket as a library dependency and as a compile-time dependency (header files)
    • Milestone: 0.3.1 --> Backlog
     

  • Ulf Lorenz

    Ulf Lorenz - 2020-02-03
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -2,6 +2,7 @@

 This issue mainly collects leftovers from [#73] with low or unclear priority.

+* do not download googletest if it is already installed on the system
 * allow versioning of wavepacket builds; use-case a bit unclear
 * When you change the Python tests, you have to copy them manually to the folder (or delete and run cmake again). There should be a better and less error-prone way of doing this.
 * We could implement different exports for the library (wavepacket) and for the headers (wavepacket-dev). Use-case is equally unclear; probably most users will not need this distinction.
     

    Related

    Tickets: #73

  • Ulf Lorenz

    Ulf Lorenz - 2020-11-08
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -4,7 +4,7 @@

 * do not download googletest if it is already installed on the system
 * allow versioning of wavepacket builds; use-case a bit unclear
-* When you change the Python tests, you have to copy them manually to the folder (or delete and run cmake again). There should be a better and less error-prone way of doing this.
+* the Python tests are copied to the build directory as part of the CMake step. This should be a part of the testing step to avoid stale copies.
 * We could implement different exports for the library (wavepacket) and for the headers (wavepacket-dev). Use-case is equally unclear; probably most users will not need this distinction.

 #####Acceptance criteria#####
     

  • Ulf Lorenz

    Ulf Lorenz - 2021-01-16
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -6,6 +6,7 @@
 * allow versioning of wavepacket builds; use-case a bit unclear
 * the Python tests are copied to the build directory as part of the CMake step. This should be a part of the testing step to avoid stale copies.
 * We could implement different exports for the library (wavepacket) and for the headers (wavepacket-dev). Use-case is equally unclear; probably most users will not need this distinction.
+* The demos could be installed as well

 #####Acceptance criteria#####
     

  • Ulf Lorenz

    Ulf Lorenz - 2024-05-05
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -2,10 +2,8 @@

 This issue mainly collects leftovers from [#73] with low or unclear priority.

-* do not download googletest if it is already installed on the system
 * allow versioning of wavepacket builds; use-case a bit unclear
 * the Python tests are copied to the build directory as part of the CMake step. This should be a part of the testing step to avoid stale copies.
-* We could implement different exports for the library (wavepacket) and for the headers (wavepacket-dev). Use-case is equally unclear; probably most users will not need this distinction.
 * The demos could be installed as well

 #####Acceptance criteria#####
@@ -14,4 +12,3 @@
 * versioning of the Python modules
     * may be left out / postponed: allow, at least optionally, multiple WavePacket modules to coexist (e.g., by defining specific namespaces)
 * Fix: Changing the Python tests automatically updates the files in the binary directory
-* Optionally: implement different exports for wavepacket as a library dependency and as a compile-time dependency (header files)
     

    Related

    Tickets: #73

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.