Overview of changes:
* Fixed issue that would break release
Releases with many commits or many changed files can produce 'Bump
version' message so long that it would trigger OS command line limit.
This risk has been mitigated by ensuring the message is read from
file instead of git argument.
* Added "SRC" mode to preserve file modes from repository
Sometimes the mode scheme is not easy, so having mode to apply to
whole group is not plausible. Setting group mode to a special value
`SRC` will cause MKit replicate the mode from source (repo or
tarball).
* `stub new` will produce "nice" mkit.ini right away
Previously, re-formatting of mkit.ini would work only in update
mode; now it's nicely re-formatted on creation.
* Fixed formatting of INI files
If value in INI file contained space, formatting would break it up.
This is no longer the case.
* Cleaned up specfile template stub
New specfile template now does not contain tabs, has fields grouped
in more logical way, and omits BuildRequires, which was not all that
correct anyway.
* Improved README.md
If sources are built using `dist`, `rpmstuff` or `debstuff`, current
version of MKit does not actually require git--all that is necessary
should be cached in the tarball anyway.
Regarding coreutils, they are part of essential set on most
distributions; on those, one should actually refrain from specifying
them.
Overview of changes:
* Added data-sampler pseudo-target
To help developers see what tokens are available, this pseudo-target
just prints list of tokens and their values, for built-in tokens as
well as for user-defined.
* Removed obsolete build_manpages target and 'markdown' type
These were not compatible with current design od MKit and will
be better off re-implemented as plugins.
* Items in changelog template are now delimited by empty line
Just for convenience when formatting and extending.
* ini() can now list all sections from mkit.ini ('ini lssect')
* Refactored internal functions with double underscore
* Updated own meta-data
* Fixed small typos in comments and docstrings
* Quoted $MKIT_DIR properly in mkit.mk
* Updated own dogfood
Remove obsolete build_manpages target and markdown type
They're based on obsolete mkit.ini structure and is not used in any known
project. That said, at least build_manpages will be added in future,
most probably in form of plugin, once plugin structure is figured out.
(Stay tuned, but don't hold your breath!)
The changelog is intended to be edited, but it's more convenient this
way (especially if you're like me, using Vim and '{' and '}' as major
means of moving around.
Overview of changes:
* build target will now leave file .mkit/semver file
Build tools can read this to easily find out version.
* semver() caches its output now
* Refactored common operations in .mkit
* Removed old unnecessary check
* Solved or muted last few ShellCheck issues
A bit convoluted check that cannot fail, since everything now relies on
var.sh being imported, which is guarranteed to set $MKIT_LOCAL to a
non-empty value.
Overview of changes:
* mkit/stub: Removed `[roots]` reference from `[tokens]` example
Using '[roots]' as reference can have unpredictable results since it
silently depends on DESTDIR, which is only available at install
time.
Next breaking release (v0.1.0, but could be earlier as we are still
in 0.0.z space) should rename 'roots' to 'ROOTS' to reflect its
volatile nature (similar to ENV).
* mkit/stub: LICENSE.md won't be mentioned in headers if not asked
* mkit/stub: PREFIX is set to /usr in packaging templates
* mkit/stub: Added notes about file paths in packaging templates
* mkit/stub: Fixed bug when empty license name would be accepted
* mkit/stub: Fixed double deploy of template.spec
* mkit/make: Having relsrc same as reldst is now tolerated (albeit useless)
* mkit/make: 'release' and 'vbump' can now be reached directly (without GNU Make)
* mkit/make: Added -V option to mkit/make script
* Code maintenance
Use of `[roots]` in `[tokens]` is tricky, because final value of a
`[roots:foo]` will "silently" depend on DESTDIR, while DESTDIR is
only known during install time. On the other hand, `[tokens]` are used only
during build time.
In other words, YOU CANNOT RELY on the value of keys in `[roots]` to be
consistent. For example, consider root:
[roots]
foo = /bar
qux = [ENV:PREFIX]:/quux
`[roots:foo]` will be '/bar' at build time, but "$DESTDIR/bar" at
install time, and `[roots:qux]` will be "$PREFIX/quux" at build time,
but "$DESTDIR/$PREFIX/quux" at install time.
Just about only case when you might want to use it is mentioning it in
a document, when you want the value to be rather "standard" than
"correct", while you still want to respect PREFIX.
So let's not lead new users directly into that rabbit hole.