I'll drop the discussion on Imake. It's dead in the water, probably even for anyone stuck on X11R6.
As for CMake, well let's just say I'm serious when I say I agree with
every criticism ever mentioned about it, and there are more than a few,
so I won't bother repeating anything specific that google, etc. can find.
My first and last direct encounter trying to work with it was in
libwebsockets. It was so difficult to modify and make anything work as
I wanted it to work that I gave up entirely and have never finished
trying to push some interesting and useful changes to the code upstream.
Also when I saw that YAJL used it for less than a dozen extremely
portable and standards compliant C code files with literally no
compile-time options or configuration necessary I ran for github and
pushed a fork with "portable" BSD Makefiles and was done with it.
As for the major effort in the documentation, well let's just say I'm
also sad that you didn't just update the manual page to use mdoc macros.
Then any and all normal output formats desired by anyone could be
generated with pretty much one line in a BSD Makefile. My default
system builds can include text, HTML, and PostScript and/or PDF for all
manual pages and other documents, but I can choose which formats to
build if I need to. Manuals are also built with localised pathnames,
some of which are set with system-wide macros, and others of which can
be customized by the build for specific local options.
The NetBSD Makefile I just posted allows ctwm to be built with multiple,
possibly distributed, jobs, and to be cross-compiled, and to build into
another directory, e.g. with a read-only source tree. It all just works
-- quite simple, direct, and understandable. Wrapping feature controls
on optional features requires an "if" wrapper for each to encapsulate
the related settings, and then either system or site-wide defaults will
take effect, or individual builds can choose options by simply setting
them on the command line or in a simple declarative Makefile.inc file.
The syntax is simple, regular, and familiar to most everyone.
Note that one does not write portable makefiles -- one writes makefiles
for a specific version of make. That's no different than knowing that
you can't tyro to make CMake files portable for Automake or Scons or
whatever. At this moment in time the portable version of NetBSD Pmake
is the most easily usable on the widest variety of systems imaginable.
(Yes, there is a POSIX spec for make, but it's the most crippled useless
make you can imagine, unless perhaps you're building 7th Edition Unix on
a PDP-11.)
At work we use GNU Make with a support infrastructure much like the mk
files for BSD Make, and it's mostly as simple to use, including for
cross-compilation and read-only source-tree builds, though parallel
builds are literally impossible to get right due to fundamental design
flaws in GNU Make. The other problem with GNU Make is of course that it
does not come with a standard, portable, set of useful macros on the
scale of the BSD mk files. Everyone writes their own, every time they
need to do it, and they're all different.
I guess BSD Makefiles won't make everyone so happy though -- and they're
probably not quite ideal for X11 packages, at least not at the moment.
They do make me very happy. The day I was able to cross-build X11 for
my old SparcStations using my 4-CPU AlphaServer with "make -j 6" and see
all the CPUs fully utilised and mostly at doing useful compilation (not
wasted on the build system), and for the whole build to finish orders of
magnitude more quickly, I was one very happy person. That was going on
a dozen years ago now and I've never looked back. My build machines
have got much faster, but some of the target architectures I build for
are much smaller and some are even slower than the old SS-5 and SS-20.
The simplicity and ease of understanding of BSD Makefiles also makes me
incredibly happy. I can very quickly read one and know exactly how a
project builds and how everything fits together and what depends on
what.
As for GNU Autotools, well I'm not sure which X.org module you might
consider comparable to the build and option complexity of ctwm.
Maybe xdm? I think it's actually probably a bit more complex on the
"how the heck do I build this thing!?!?!?" scale of things, given it has
several programs to build as well as a bunch of scripts and config files
that need "building". It's also got about 20 or more build options for
the user to choose from, which I think is quite a few more than ctwm
will ever need.
Xdm's entire build system (i.e. the part a human had to write specific
to the xdm project) is still half the size of your CMake stuff, and it's
supportable within the modern X.org framework, and I'll argue that it
was indeed easier to write and will be easier to change and to maintain
as well. It'll certainly be easier for any arbitrary person familiar
with maintaining X.org packages to take over.
As I've said, I don't care much for Autotools, but I still think it's a
million times easier to deal with than CMake. Autotools with Automake
is, after all, half-way to BSD Makefiles in terms of simplifying the
description of how things go together and what depends on what.
Makefile.am files should generally be as simple and clear and easy to
understand and maintain as BSD Makefiles.
I also think you are, at the very best, going hard against the grain by
using CMake for what is not really anything more than a forked
enhancement of what's still considered a core X.org package -- something
that itself uses Autotools along with all the rest of the X.org world.
If you have any hopes of ctwm being more widely accepted by X.org users,
never mind X.org developers and maintainers, Autotools is probably your
only safe choice.
BTW, the NetBSD makefiles for xdm total about 6KB but are still quite
simple and straight forward; but of course they have most of the option
decisions hard-coded in their current non-portable form.
--
Greg A. Woods
Planix, Inc.
<[email protected]> +1 250 762-7675 http://www.planix.com/
pgpSo7LU4vjLb.pgp
Description: PGP signature
