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
|
----------------------------------------------------------------------
Q: It looks like you are reimplenting the wheel. There are lots of
alternatives to GNU autoconf, e.g. CMake, scons, waf,
PMK (pre make kit) and others.
A: mk-configure has different design and goals. Just to note a few:
simplicity for developers, Keep It Small and Simple, STOP CODE
GENERATION!, bmake is magic enough, using POSIX shell and POSIX for
implementing basic checks, and some others. If you like these
principles maybe you'll find mk-configure interesting. In this case
try to use it and help me to improve it. Any kind of feedback is
welcome, I don't ask you to send me patches ;-)
Otherwise just ignore it, why bother.
----------------------------------------------------------------------
Q: Using POSIX shell and POSIX utils for implementing a build system
sounds terrible to me. Why not to use more powerful languages like
Perl, Python, Ruby and others?
A: Python, Ruby and Perl are very big. I don't want to depend on such
a big tools. I also don't like when backward compatibility is
broken with new releases of program language. Finally I dislike
Perl and Python for their stupid syntax. Ruby is much better but it
is also very big and the language is not very stable.
----------------------------------------------------------------------
Q: Perl/Python/Ruby are available on almost every OS that ever existed
even on Windows and Symbian. Why you limit mk-configure to POSIX
compatible operating systems?
A: First, I don't use Windows and don't care about it. Second, if you
want to write software both for UNIX-like OSes and Windows there
are no problems. You can use Interix, Cygwin or any other POSIX
subsystem for Windows to build your software. By the way,
cross-compilation is one of my priorities. So, there is no problem
in cross-compiling your software for embedded platforms, Windows or
any other OS your software supports.
----------------------------------------------------------------------
Q: You say that portability is one of the main goal of your
mk-configure (build automation software MUST be portable. Right?).
At the same time you say you use POSIX shell and POSIX tools.
My experience says me that it is just not possible to write
something REALLY portable in shell/awk/sed etc.
A: I know very well how broken POSIX tools may be on some OSes and
hardware platforms. At the moment mk-configure supports the
following platforms: NetBSD, Linux, FreeBSD, DragonFlyBSD, Darwin,
HP-UX, Tru64, QNX, OpenBSD, Interix, Cygwin, MirOS BSD and Solaris.
If you find a bug please let me know. Also note that
mk-configure has lots of regression tests.
I don't make releases without testing on all platforms
available to me.
----------------------------------------------------------------------
Q: You just didn't read autobook and don't know how to use GNU
autotools properly. Your criticism is inadequate. First, read the
documentation!
A: The question is not about me personally. Try to maintain software
packages in BSD/Linux/... distributions and you'll understand that
LOTS of FOSS developers actually do not understand how to use GNU
autotools properly. I believe this is because autotools's
complexity has grown beyond all reasonable levels.
----------------------------------------------------------------------
Q: bmake? What is it? Is it for NetBSD only?
A: bmake is a portable version of NetBSD make that supports at least
the following operating systems and POSIX environments (besides
NetBSD of course): FreeBSD, DragonFlyBSD, OpenBSD, Linux, Solaris,
AIX, HP-UX, QNX, A/UX, OSF/1, Darwin, Interix, UnixWare and IRIX.
----------------------------------------------------------------------
Q: NetBSD make? Then why not to support FreeBSD/OpenBSD makes?
A: OpenBSD and FreeBSD make(1)s are different and NetBSD make
is more powerful. More over, NetBSD and Free/OpenBSD make(1)s are
incompatible in some aspects.
----------------------------------------------------------------------
Q: Learning yet another make doesn't look like a good idea to me.
Nobody will use your mk-configure because it requires learning
bmake.
A: First, bmake is easy. Learning it doesn't require too much time.
bmake is MUCH simplier than e.g. Python (see scons). I also
assume that every UNIX programmer knows the basic make
concepts. Second, software building rules are usually rather simple
and therefore you need not be an expert in bmake for writing Makefiles.
If building rules for your project are extremely complex, maybe the
problem is with your project, try to simplify it ;-)
Moreover, mk-configure provides several examples in
examples/ subdirectory. I hope they simplify learning mk-configure
significantly.
----------------------------------------------------------------------
Q: Yet another build automation software makes a packager's life
harder.
A: Not a big problem. First, packagers are specialists. They should
learn new things every time ;-) . Adding support for
mk-configure into your packaging system should not be a problem.
Have a look at pkgsrc (www.pkgsrc.org) for examples. Makefiles
for projects based on GNU autotools require the line
GNU_CONFIGURE = yes
Projects based on CMake need the following line
USE_CMAKE = yes
Projects using mk-files require
USE_BSD_MAKEFILE = yes
I think this is easy. If your packaging system doesn't allow the
similar functionality, improve it ;-)
----------------------------------------------------------------------
Q: Why NetBSD bmake was chosen? Why not "standard" GNU make? Today
Linux has MUCH more developers than FreeBSD/OpenBSD/Solaris and of
course NetBSD. Most programmers using Linux use GNU make. Without
support of Linux developers your project is dead.
A: NetBSD make was chosen for the following reasons: 1) when I started
mk-configure I could not find good analogs for mk-files written for
GNU make; 2) in my view bmake is simpler and more convenient for use
than GNU make; 3) I hate gmake's foreach/eval/call construct, bmake's
.for/.endfor is MUCH more convenient and easier to use; 4) gmake
starts finding includes starting from CWD, this is terrible, bmake
starts searching for "includes" starting from the including
makefile's directory. Note that mk-configure and mk-files widely use
the .for/.endfor construct.
Theoretically it is possible to implement a full analog for
mk-configure based on GNU make instead of bmake but I have no
time to do that. If you want to, let me know.
----------------------------------------------------------------------
Q: It's time to bury ALL make-like programs.
Use modern make replacements, Luke.
A: It's true that make-like programs have some limitations.
But none of them seem critical to me.
I'm quite happy with traditional makes (NetBSD make and GNU make).
----------------------------------------------------------------------
Q: You propose setting build options through environment and
bmake's options instead of ./configure --option=xxx.
Are you serious?
A: Yes, I don't see significant difference between setting paths and
build options via --options and command line arguments and
environment. The only thing lost is that autoconf's ./configure
checks for correctness of the given options but I don't think this
is a significant advantage. On the other hand using environment
variables for setting build options has its own advantages for
the development. You can set them ONCE in a shell session and
that's enough. Alternatively (and even better) you can add
.sinclude "my_local_settings.mk"
to Makefile and write your settings down to that file. Then
your local build options will take effect every time you run
mkcmake. Easy?
If you don't like .sinclude you can use
bmake -f my_local_settings.mk -f Makefile
command. Interactive shell's aliases and functions might help to make
things even easier.
----------------------------------------------------------------------
Q: It's known that libxxx has different places in different Linux
distributions. Can mk-configure find it automatically?
A: No. Software build tools MUST NOT have an artificial
intelligence inside. If you need libxxx tell mk-configure correct
CPPFLAGS (-I/headers/here) and LDFLAGS (-L/libraries/here).
This is how it works. mk-configure will not search for includes
in /usr/local, /opt/sfw or anywhere unless you ask it to do so
explicitely.
----------------------------------------------------------------------
Q: As far as I can see your mk-configure doesn't support ALL features
supported by GNU autotools and some other competitors.
A: If you see this tell me what type of functionality you are talking
about. If I find it helpful I'll implement it in future
releases of mk-configure.
----------------------------------------------------------------------
Q: How about GUI for "configuration" stage?
A: Most often today's users use software from their system in a
prebuilt form. I don't think software packagers need a GUI. On the
other hand, if you need a GUI, nothing prevents you from creating it.
----------------------------------------------------------------------
Q: GNU autotools provides two-phase project builds and this is a good
idea. mk-configure lacks support for it.
A: I personally don't like two-phase ideology. I see one phase
"build the software taking into account my platform's features".
If you want to check for errors first, run
bmake errorcheck
----------------------------------------------------------------------
Q: Does mk-configure support caching?
A: If you mean caching of the platform features, my answer is YES.
Look at _mkc_* files and documentation for MKC_CACHEDIR variable.
If you mean caching of object files, then NO. This is not
mk-configure's task. For this use distcc(1) or similar tools.
----------------------------------------------------------------------
Q: mk-configure lacks support for Qt/KDE etc.
A: Software is developed step-by-step. If you need something, let me
know. I'll implement missing features in future releases of
mk-configure.
----------------------------------------------------------------------
Q: mk-configure lacks support for my favourite
programming language XXX.
A: First, let me know about it. Second, nobody prevents you from
creating rules for your language directly in Makefile or in your
own (local to your project) include files.
----------------------------------------------------------------------
Q: How about integration of mk-configure to Eclipse or...
A: I don't use such IDEs but I agree it whould be nice to have such
support.
----------------------------------------------------------------------
Q: It looks like mk-configure is suitable for small-sized projects
but is not ready for huge ones.
A: Suppose you are right. How about the fact that 99% of all FOSS
projects are small or medium in size? ;-)
----------------------------------------------------------------------
|
