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