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
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
|
Changes in 0.5.1
* ZMK now defines `ZMK.BugFixes` as a set of identifiers of issues that were
known and addressed inside the library. Specific bugs may gain stable identifiers
that, once addressed, are added to the list in the next release of the library.
This mechanism is intended to enable hot-fixes, which are applied to the
makefile of a specific project, which update or replace part of zmk to fix a
specific issue while doing so in a way which eventually disables the
workaround.
* The Symlink template is now documented with a dedicated manual page
* The Symlink template no longer retains the sub-directory related to the
placement in the development tree after installation, matching the behavior
of the Program template.
This is a backwards incompatible change resulting from the fact that
previous behavior was simply wrong. There are additional tests checking
various combinations of this behavior now.
This issue is identified in ZMK.BugFixes as zmk-issue-80
* ZMK integration tests no longer fail on Haiku
Changes in 0.5:
* The Program.Test template no longer fails with syntax error when computing
test coverage.
* The Toolchain module no longer misidentifies clang on FreeBSD.
* The Toolchain module has initial integration test suite that checks the real
interaction with the host system. The integration test suite has reference
data for FreeBSD and MacOS.
* The Coverity module gained support for checking if scan result is viable for
submission and an ability to submit the scan automatically, using the new
`upload-coverity-scan` target. See the manual page for additional information
about project configuration.
* ZMK now supports additional static analysis tools: clang-tidy, clang-analyzer
(via scan-build), cppcheck and sparse. They each define a CamelCase-named
module and a Sources attribute which includes the set of files to scan.
* The distclean no longer forgets to run clean target.
* ZMK now allows installing multiple headers simultaneously with the
use of the HeaderGroup template. HeaderGroup supports group customization of
InstallDir and InstallMode and otherwise behaves identical to the Header
template used multiple times, manually.
* The ClangTidy template now passes `-- $(CPPFLAGS)` if there are non-empty
CPPFLAGS defined. This can be used to provide include paths and macro
definitions appropriate for the project.
* The Sparse module now passes $(Sparse.Options) via CFLAGS set at the environment
level before invoking recursive $(MAKE). This avoids clobbering CFLAGS set in
the build system (e.g. to pass -fpic) as make treats command line overrides
differently from environment values.
* The Configure module now supports setting the target triplet. The generated
configuration script handles the --target= command line option and the result
is available as $(Configure.TargetArchTriplet).
* The configure script now accepts --exec_prefix= as an alternate spelling of
--exec-prefix.
* The configure script now accepts but ignores --oldincludedir for compatibility
with some build systems.
* The Configure module now supports configuration of static and dynamic
libraries with the new configuration script options: --enable-static,
--disable-static, --enable-dynamic and --disable-dynamic. Both library types
are enabled by default. The values are stored and inhibit expansion of
appropriate templates.
* The Header and HeaderGroup template no longer expand $(includedir) too early,
allowing customized includedir to be respected.
* The Configure module no longer breaks in out-of-tree builds and no special
care is required to support that anymore.
* ZMK is now able to use an explicit sysroot for all activities.
The configure script now accepts --with-libtool-sysroot which sets
$(Configure.SysRoot). The Toolchain module defines $(Toolchain.SysRoot) which
defaults to whatever was configured. The templates ObjectGroup, Library.So,
Library.DyLib and Program now pass the sysroot argument when
Toolchain.SysRoot is non-empty. Lastly the PVS module similarly passes
a non-empty sysroot when invoking the pre-processor.
Changes in 0.4.2:
* The PVS module no longer fails when running the pvs-report target.
* The Header module no longer clobbers custom InstallDir.
* The Library.DyLib template no longer creates symlink foo -> foo.dylib when
the library is not versioned. In addition the amount of code shared between
Library.So and Library.DyLib has increased.
Changes in 0.4.1:
* The Library.So template no longer creates symlink foo -> foo.so when the
library is not versioned.
* The ObjectGroup template no longer fails during out-of-tree builds with
dependency generation and sub-directories in source file paths by attempting
to put the generated dependency information alongside the source code.
* The ObjectGroup template no longer fails during out-of-tree builds when
the original project explicitly uses $(ZMK.OutOfTreeSourcePath).
* The PVS module no longer fails when the original project uses
sub-directories to organize the source tree.
Backwards incompatible changes in 0.4:
* The Configure module introduces a backwards incompatible change in the
name of the generated configuration file. In older releases the file was
called GNUmakefile.configure.mk, starting with this release the name is
config.$(NAME).mk. $(NAME) is the name of the project, also available as
$(Project.Name). This also restricts the configuration system to projects
that define a name. The background of this change is a realization that prior
approach caused confusing an buggy behavior, where Make would search the
include path, which also contains all of PATH, for *any* file named
GNUmakefile.configure.mk and include the first one it found.
Projects using zmk are advised to change their manually included
configuration file to one that contains their project name.
Changes in 0.4:
* The Symlink template used by Library.So and Library.DyLib will now work
correctly when invoked with -B switch (aka --always-make), by force-creating
symbolic links that already exist.
* Program template no longer forgets to add the .exe suffix to installed executables.
* The ObjectGroup template used by Program, Program.Test, Library.A, Library.So
and Library.DyLib now supports sub-directories in source file names. Object files
created by the object group are now created in directories corresponding to the source
files.
* The ObjectGroup template now supports additional C++ extensions: .cxx and .cc.
This is in addition to the .cpp extension that was supported before.
* The ObjectGroup template used by Program, Program.Test, Library.A, Library.So
and Library.DyLib is now performing rudimentary detection of a missing compiler.
* The GitVersion module now provides GitVersion.Origin attribute
to indicate how the version information was obtained. The value "git" is used
when git history along with git tags were used. The value "file" is used when
the .version file was read.
* The Tarball.Src template no longer breaks when used from a dist archive.
* The Program and Script modules no longer attempt to transform installed name
when the Configure module is not imported.
* The internal toolchain.GCC module no longer attempts to invoke gcc and g++
if they are not installed.
* The ManPage module again checks for errors in manual pages. This feature
was disabled in an earlier release as it was showing a problem with zmk
that was not understood at the time.
* The Tarball.Src module only signs the release if both GPG and GPG keys are
available.
Changes in 0.3.8:
* The release archive now contains the full collection of test files.
Changes in 0.3.7:
* The release archive no longer contains the pre-compiled manual pages. Instead
the .in files are shipped, to be compiled locally.
Changes in 0.3.6:
* InstallUninstall no longer reuses the relative directory in the source tree
to represent the target directory. Instead the InstallDir property is the
only way to influence the final path. This was a late discovery but one that
is ultimately only sensible. ZMK itself was adjusted to install correctly in
this new scheme.
Changes in 0.3.5:
* Make distclean no longer breaks building of packages in Debian, by not
removing the bundled zmk and the configure script that current packaging
helpers cannot yet re-generate from zmk itself.
Changes in 0.3.4:
* GitVersion no longer interferes with downstream packaging of releases
by bundling the .version file for snapshots and tagged releases alike.
Changes in 0.3.3:
* Tests no longer hang on case-insensitive filesystems.
* The Directory module no longer issues warnings on MacOS
Changes in 0.3.2:
* The ManPage module no longer installs files to the /man directory.
Changes in 0.3.1:
* The GitVersion module now follows public/private variable naming scheme.
The only public attribute is GitVersion.Active, which expands to yes if
the module has altered VERSION as compared to what was set in the makefile.
* The Tarball.Src module no longer attempts to sign releases in CI systems
and no longer issues warnings if the GitVersion module is not used.
Changes in 0.3:
* For future extensibility backwards compatibility is dropped. All symbols are
different. By the time this release is finalized a compatibility module may
be introduced, if practical.
- All variables now use CamelCase, not under_score. This includes template
instance variables, so for example "hello.sources" becomes
"hello.Sources".
- All public variables are capitalized. This includes variables scoped with
the "ZMK.PublicName". Private variables are named like "ZMK.privateName"
and cannot be relied for backward compatibility across releases. All
public variables should be documented in the manual page corresponding to
the module or template name.
- All custom variables are prefixed with module name, or "ZMK.".
- Modules are imported with the ZMK.Import function, replacing "import".
Modules no longer have the "Module." prefix as it was somewhat redundant.
- Templates are expanded with the ZMK.Expand function, replacing "spawn".
Templates no longer have the "Template." prefix as it was equally
redundant.
- All module names are now using CamelCase naming. Some modules were
renamed, for example "git-version" became "GitVersion" and "PVS-Studio"
became just "PVS"
* Introduction of manual pages for zmk. This is a longer effort but eventually
all modules, templates, variables and rules will be documented.
* Examples are now part of the distribution archive.
* The true_false example illustrates how preprocessor options can
vary per target, even if the same source file is used in more than one
program.
* Examples are now much more terse and to the point.
* The Directories module now warns if DESTDIR is defined inside a makefile.
* The Toolchain module no longer removes all object files.
* The Toolchain module now prefixes all non-standard variables with
Toolchain, to avoid confusion and clashes with user code.
* The Tarball.Src module no longer signs the release archive
from a git-versioned snapshot.
* The Tarball module, when used on Darwin, no longer now forgets to
add the versioned top-level directory, matching the experience on Linux.
* The GitVersion module now detects some CI systems and alerts the
user of a possibility of a shallow git clone.
* Test suite is now part of the distribution archive. All examples are tested,
some modules are also separately tested, to ensure coverage.
* C++ is now supported for all programs and library types.
* Objective C is now supported for all programs and library types. Certain
special features related to gnu-step were dropped. Those are better applied
in actual project makefiles where they can be precise and accurate.
* Numerous smaller bug were found and fixed.
Changes in 0.2:
* The Template.data module now handles nested directories better.
* The Module.configure module can now synthesize the configure script.
* The configure script now handles --runstatedir=DIR option.
* The configure script no longer considers --build=TRIPLET as cross-compiling,
both --build=TRIPLET and --host=TRIPLET must be used and must differ for
that to happen.
* The configure script now supports --help and --version options.
* The Module.git-version module now strips leading "v" from tags.
* The Module.git-version module no longer clashes with Debian packaging
and now collaborates with Template.tarball.src module to store the version
in a .version file.
* The new Template.tarball.src module now creates GPG signatures for
release tarball and handles the .version file.
* ZMK now generates all required files and stores them into source archives
created with Template.tarball.src. Generated data can be removed with the
distclean target.
Changes in 0.1:
* Initial release with the build system extracted out of libzt.
|
