----------------------------------------------------------------------
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? ;-)

----------------------------------------------------------------------
