buildgear/TODO at master · lundtor/buildgear · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
--- Build Gear TODO list --------------------

This is a list of features that are planned for Build Gear in the future. Some
features are just ideas and might never be included.

The Build Gear design principle does not allow for features if they introduce a
too high level of user interface or maintenance complexity.

In short, advanced features will have to be considered carefully in order to
keep Build Gear simple.


Build Gear v1.x (current 0.x beta in development):

 * Not much here - all features seem to be in place.. "famous last words" :)

 * Recurring tasks such as bug fixing and clean ups


Build Gear v2.x: (highly experimental)

 * Split output by using different package output variables

   In addition to $PKG, add support for eg. $PKGDOC and $PKGDEV.

   In the Builfile output will be sorted like so:

      $PKGDOC: man/info pages etc.
      $PKGDEV: include files
      $PKG: binaries

   This will add to maintenance cost so it will have to be considered
   carefully.

   There is also a performance cost when creating/handling multiple packages.

   Actually, this is very likely to never be supported (too high cost).

 * Menuconfig/Kconfig configuration support

   Introduce a .kconfig file or add support for a kconfig() {} section in the
   Buildfile.

   Also, add a new command "menuconfig":

   $ buildgear menuconfig

   This command will go through all .kconfig and compile and present the
   classic menuconfiguration interface with listing of configurable options.
   Also, when exiting, the configuration will be save to a .config file in the
   config directory or at the top level directory.

   This will allow for creating ditributions which are fully configurable but
   the hope is that it will _only_ be used for configuring essential features
   to keep the number of configuration options to a minimum because having
   configuration options adds to the maintenance cost.

   By design, this feature will allow for more complex build files and induce a
   higher maintenance cost. In other words, this will have to be considered
   very carefully.