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
|
============================================================
Plan 0.25.0
Some thoughts inspired by talks with Michael Crogan
- During development of huge projects it may make sense to always keep
"installed" version of the software somewhere (FAKEPREFIX?)
and always keep it synced.
mk-configure needs a mechanism to always "install"
after "all" and "uninstall" before "clean". Options: develop this in
mk-c and make it optional feature; provide a mechanism for
auto-depend one target from TARGETS from another one. In the latter
case users will be able to implement this kind of things themself.
(myall -> "myall-* : all-* .WAIT install-*)
(myclean -> "myclean-* : uninstall-* .WAIT clean-*)
- VARIANTS for libraries.
- project "roundup" for testing
- Better explain how "test" target works, maybe as a couple of slides
in the PDF presentation. With and without mkc.minitest.mk.
- One more example/ for TARGETS, demonstrating such things as
"mkcmake release/debug/profile" or "mkcmake all_clang/all_gcc"
or "valgrind_test"/"gcov_test" etc.
- Additional slides in PDF for virtual subprojects.
Notes about "virtual subproject" in examples/.
- Notes in examples/hello_dictd and other examples based on
mkc.subprj.mk about what mkc.subprj.mk really does. Reference (man page)
is not enough for newcomers. Notes about clean-SUBPRJ, all-SUBPRJ etc.
- Better explain ../Makefile.inc included automatically. For those who
are not familiar with *BSD it is not obvious how to use it.
- "errorcheck/configure" tests should be run in parallel. Something
like shlock(1) or flock(1) is needed for this.
- Example is needed for how to embed autoconf-based subproject into a
project based on mk-configure. The sad fact is autoconf/automake is
everywhere. So, it would be nice integrate mk-c into reality.
mkc_imp.autotools.mk is needed for this.
- Alternative .depend generation, e.g. like it is described in GNU
make info files
- Higher priority for fixing handling of dependencies between
libraries and programs. In addition examples/ is needed for
triggering rebuild of subproject if "something" was rebuild in
another subproject (build script for example).
- For better extensibility it makes sense to implement user-implementable
pre_all, post_all, pre_install, post_install etc. targets.
- Interdependencies between targetX-subprjA and targetY-subprjB (for
example all-prject1 and install-prject2). Maybe this is cool idea
for examples/ and slides. I need some good example for this.
<<<depend-project1:errorcheck-autotools_based_project2>>>!!!
- Steal cool features from Simon Gerraty's mk files and analyse
"meta mode" he invented.
- Better support for working without installation to /. -rpath, additional
directories for objects, binaries and libs.
Some "targets" from TARGETS should set MKCHECKS to "no"
ronn(1) : markdown to man pages
-----------------------------------------
gcc -L/usr/pkg/lib -R/usr/pkg/lib -o hello_lex hello_lex.o -ll
yacc calc.y
mv y.tab.c calc.c
gcc -I/usr/pkg/include -c -o calc.o calc.c
gcc -L/usr/pkg/lib -R/usr/pkg/lib -o hello_calc calc.o
ERROR: cannot find program -y
Cannot find bison, good bye!
------------------------------------------
custom test failed -> exit status of mkcmake should not be zero
MKC_CUSTOM_ERR.qqqq -> error message before exiting just like
mkcmake configure doesn't work
New variable MKC_CUSTOM_ENV.xxx
Add script_check to MKC_CHECK_CUSTOM
Ex. MKC_CHECK_CUSTOM+= nested_funcs
MKC_CUSTOM_FN.nested_funcs= nested_funcs.c
MKC_CUSTOM_FN.script_check= checks/script_check
- BINSUBDIR, LIBSUBDIR, LIBEXECSUBDIR etc...
- Fix USE_SSP support for clang (-mllvm -stack-protector-buffer-size=1)
- @sysconfdir@/mkc.conf
- LDFLAGS vs. LDFLAGS in link.me (global paths before project's)
- Reimplement linkme.mk. It is not flexible enough.
- USE_RPATH
- OBJCOPTS_<proj>
- Regression tests:
* optional .f tests
* optional .p tests
* optional .m tests
* optional(!) glib2 tests
============================================================
Plan 1)
- Support for MKDEBUG like in NetBSD mk files
- .lua.luac:
- Implement mkc_imp.libtool.mk to build
the shared libraries using GNU libtool(1).
- MKSTRIP, STRIP, mkc_install: use STRIP, not STRIPPROG
Slides for:
- Slide "extensibility" about Lua module.
- code specific to GNU ld(1) (.def?)
============================================================
Plan 2)
- ./configure written in shell?
- EXPORT_DYNAMIC_SYMBOLS - add the specified symbols to
dynamic symbol table (GNU ld)
- EXPORT_SYMBOLS_REGEXP
- recheck documentation for Makefile.rec
- Syllable, Haiku, OpenServer/UnixWare and HURD
- lcc and tcc compilers
- epm -> rpm, SVR4 pkg etc.
- mkc_imp.filelist.mk
- FL_NOPREFIX
- FL_PERSUBPRJ
- IRIX: "endianess" and EXPORT_SYMBOLS
============================================================
Plan 3)
= sample for home-made .mk file (Ocaml? Pike?)
= marker for user's custom tests that
run generated executables, i.e. not ready
for cross-compilation
= symlinks to executables and libraries in ${OBJDIR}/{bin,lib}
= support for gettext
= xxxDIR variable for /var
= mkclint?
= Command line may be limited in size.
Save defines to config.h and set HAVE_CONFIG_H to 1
for compiling.
= MKC_NEED_FUNCLIBS - the same as MKC_SOURCE_FUNCLIBS but
implementation is taken from mk-c.
Ex: MKC_NEED_FUNCLIBS += strlcat strlcpy getline
= MKC_CUSTOM_premk, MKC_CUSTOM_postmk
= Online tutorial
= shared libraries support for AIX, UnixWare, Hurd, Haiku.
= shared libraries support for nwcc and other compilers.
= Comparison with quagmire, kBuild, CMake, scons, waf, framewerk, pmk,
MagicMakefiles, bjam, pymake etc.
= Often compilers need special options to compile pthread code.
Support for MKPTHREAD=yes|no is needed.
= implement MANBZ2?
= man page for mkc_check_compiler
============================================================
Plan 4)
= EXPORT_SYMBOLS for HP-UX, AIX, SCO etc.
= Single cache file as an automatically loaded (if exists)
bmake makefile.
= Targets bin_rpm, bin_epm
= Targets src_tar, src_targz, src_tarbz2
= mkc.subdir.mk:
- continue bulding even if some subprojects failed
= MKC_CHECK_CUSTOM:
- MKC_CUSTOM_FN=xxx.f
- MKC_CUSTOM_FN=xxx.objc
= Implement mkc.qt.mk
= Implement mkc.doxygen.mk?
============================================================
Plan 5)
= mkc.configure.mk functionality but for bourne shell, e.g.
Upstream creates ./configure shell script:
MKC_CONFIG_MK=mkc_config.mk
MKC_CONFIG_H=mkc_config.h
MKC_CHECK_HEADERS='
header1.h
header2.h
header3.h'
MKC_CHECK_FUNCLIBS='
func1:lib1
func2
func3:lib3'
#<...>
. mkc_configure
mkc_run # generating mkc_config.h and mkc_config.mk
User runs
./configure ...
<any>make all
= MKC_CHECK_DECL_TYPE (define, function|variable)
= MKC_DEFINE_01 - -DHAVE_XXX=0 or -DHAVE_XXX=1
============================================================
Plan 6)
= MKC_BUILTINS (from autoconf):
broken_free_NULL,
exit_ret_int,
isinf, isnan, malloc_0, putenv_xxx, realloc, signal,
snprintf, sprintf, sscanf, strerror_r, strnlen,
sysconf, unlink, unsetenv, va_copy, va_list,
signed_shr, int_div, chown_minus_1,...
(autoconf.info/Particular Function Checks)
AC_FUNC_ALLOCA
= autoconf (Portability of headers)
= autoconf (Particular Header Checks)
|
