I just released the first release candidate of the build-tool 0.6 series. It is a release with many changes. Therefore beware that i did not call it a release candidate lightly. It is possible that things break using it.
If you want to test it use gem update|install --pre build-tool. Then make a backup of your $HOME/.build-tool folder and remove all *.db files in that folder. The last step is to switch your recipe to the branch build-tool-0.6.
New Features
Command: recipe edit
This command makes it easier to edit the recipe override file. It either opens a editor for the file or a file browser for the directory with the file. It uses xdg-open to do it.
Command: module cleanup
The command helps in removing the build and source directory of a module. Be careful when using it because you could lose unpushed / uncommitted changes if you do. Use on your own risk.
Keep in mind that build-tool can only remove modules it knows about. If a module falls out because of a recipe change you have to remove the module before the recipe is updated. Best workflow is the following:
Global Options: --ionice and --nice N
When given build-tool sets its nice value to N and its ionice value to idle. Use like this kde-build --nice 10 --ionice build -u KDE/kdelibs.
Major Changes
Module Status moved to database
The module status (enabled/disabled) moved into the database. To enable or disable a module use the new command module enable|disable MOD|GROUP. On first run the current settings will be migrated into the database. Afterwards remove all module enable|disable ... lines from you recipe override file (command recipe edit).
Feature Status moved to database
The feature status (enabled/disabled) moved into the database. To enable or disable a feature use the new command feature enable|disable MOD|GROUP. On first run the current settings will be migrated into the database. Afterwards remove all feature enable|disable ... lines from you recipe override file (command recipe edit).
Settings moved to database
The content of the file RECIPE.yaml moved into the database. On first run the values will be migrated into the database and the file will be renamed.
The new command configuration list [VARIABLE]... shows the current value of all (default) or the given variables.
To edit configuration values use the new command configuration edit [VARIABLE]... which will open a editor with the all variables or only the ones given on commandline. After you made your changes write the file and the changes will be written back to the database.
I know that the new layout is much less readable than the old file. I use yaml as before but because of technical reasons it looks much worse. I am trying to come up with an improvement.
Improvements
Show list of commits on rebase
If you are interested in an overview of the commits you get when updating specify one --verbose option to the build command. Beware that the list can get long.
Build :all
If you only have a small amount of active modules use :all to specify them all at once.build :all build them all for example
Help texts improved
Most of the help texts have been reworked and improved dramatically. If you still see area for improvement somewhere tell me.
Command: lsmod
Much improved output.
lsmod --broken shows all currenly broken modules (last build failed).
lsmod --no-sort shows modules in order of declaration, which is the same as build order.
lsmod --all shows all modules including inactive ones.
lsmod --disabled shows only disabled modules.
Command: lsfeat
Much improved output. Shows only active feature by default.
lsfeat --all shows all features including inactive ones.
lsfeat FEATURE shows all modules associated to the given feature.
Command: gc
The command was improved dramatically and now removes old cruft much better.
Build inactive modules
It is now possible to build inactive modules as long as the associated feature is active when the command is give explicitly on the command line. This makes it possible to trigger them manually while not getting them with groups.
Technical Changes
Build-tool uses branch from recipe
Build-tool no longer uses master to follow a recipe. The used branch is named build-tool-[MAJOR].[MINOR]. It is therefore easier to support more than one build-tool version at the same time. If you use the build-tool incoming command the change has no affect on you. If you rebase the recipe manually keep that in mind.
ActiveRecord used
Build-Tool now uses ActiveRecord of rails fame. It is therefore necessary to recreate the database from scratch. The new database will be written under a new location to make it easier to switch back to an old build-tool version.
Unit Test are back
The switch to ActiveRecord made it possible again for me to enable unit tests again. I was unable to do that with the old database layer. Many new test have been done.
Comments
Post new comment