On Tue, Jul 19, 2016 at 02:51:02AM -0700 I heard the voice of Greg A. Woods, and lo! it spake thus: > > Sorry for the delay -- too many other irons in the fire.
I'm well acquainted with the feeling :) Thanks for the reply. Please don't take anything I've said or say here as dismissive; I want to run these sort of things through as far as possible, and try and get somewhere that everyone's as happy as we can manage. > Yup, my bet is this CaptiveRoot stuff -- it's the only difference I > see in how the menu window is moved between old ctwm, twm, and new > ctwm. > > As soon as I can rebuild it....... Yeah. I would bet on that last patch in my June 17 mail <http://article.gmane.org/gmane.comp.window-managers.ctwm/1655> (~bottom third; the other two patches are just test spikes). In the time since, every time I've thought about it, I'm less convinced that it's a sensible thing the code is doing. Note that it's against 3.8.2, so you shouldn't have any build worries... On the build system side, let me make the short note that I _DO_ have it on my list to try and find a low-friction way of generating a parallel minimal build system. I don't expect it'll be built to do much beyond building the ctwm binary, but that gets you somewhere. It's not at the top of my list, but I hope I can do it before 4.0.0. Time is always limited, sadly, and my bank is deeply invested in me not doing too much. Now, if anybody want to sponsor full-time development of ctwm... ;) ----------------------------------------- The remainder of the mail is ignorable by anybody who doesn't wanna talk forever about the build system. Or even who does, but doesn't wanna listen to my self-justification. > I think for X11 apps Imake is still better, but that's just because > I've got sufficient experience with making it work. We've discussed a bit before what imake failures made it an easy decision to toss it, but to summarize just a few in no particular order: - The only real way to make it do any configuration is editing one of the input files, which isn't going to get along with people who've learned to build software in the last 20 years. (you can do _slightly_ more by invoking imake manually rather than via xmkmf, but nobody does that either) - The only configuration you can do is user-setting variables we decide to make user-settable; there's no introspection of the surrounding system to find things. So it's pretty much purely a Makefile builder that knows a thing or two about the X core to add itself; it doesn't really do much of any ./configure role aside from that. - The only things we can make user-settable are the things we totally control. For one notable exception that's bitten us before, imake Knows(tm) what compiler was used to build X, and hardcodes that. If you got X from binary packages built with a compiler your system doesn't have (say, you're on Solaris), or you WANT to use a different compiler for some reason (say, you're testing), your only way to build is to hand-edit the Makefile after imake has run. - It doesn't use cpp. It uses K&R cpp. My system compiler doesn't even have that anymore, so I can't just run xmkmf, it'll blow up. I need to install a separate tradcpp, and set... an env variable, I think? Before I can even run xmkmf. - Even X doesn't like it anymore, and it's not maintained much. A pretty weak reason by itself, but it's a reason. > especially if the configure.ac and makefile.am files for X.org's new > twm package are any indication. Far all together it's fewer lines > total than your CMakeLists.txt, and no need for the 45kb of > additional *.cmake files. I think that's not a great comparison, for two reasons. The general one is that I don't much like LOC-ish comparisons. Within reason, I don't _care_ how big the build scripts (or source, for that matter) get; I care how maintainable and understandable they are. I've rewritten code to be a lot smaller, and gotten something more maintainable out of it, but I've also rewritten code to be a lot bigger and gotten more maintainable results. Size metrics aren't entirely useless (if we start shipping 64 megs of build scripts, I'm gonna be a little unhappy), but they're _very_ weak. The more specific is that, well, it's a crazy unfair comparison. The twm build scripts are tiny, yes, but that's because they do practically _nothing_. They find lex/yacc (can't apparently build from tarballs without at least lex, though we can), the core X11 libs, and that's it. Of our ~42kB of .cmake files, over half is to do with building the manual, with multiple output formats, choosing among multiple different possible toolchains to give the best chance of successfully building it. And in fact, most of it is irrelevant to the Average User anyway, since release or snapshot tarballs ship with the manual pre-built so they can get along without any of the toolchains available. twm doesn't have any such thing at all. (and it'll probably grow; there's more I could do to improve the output, and it's still on The List to add a Dev's Manual along side the user one) The next biggest file is the build options. We can en/disable XPM support and find the necessary bits; twm doesn't have any XPM support. En/disable JPEG support and find bits; twm doesn't have any JPEG support. En/disable m4 support and configure which m4 program we use; twm doesn't have any m4 support. En/disable rplay support and find bits; twm doesn't have any rplay support. etc. So, y'know, I could eliminate that file trivially; I just remove those features :) Next biggest is generated source files. Half of that is about generating version info. Most of that is getting and stashing VCS info so you can tell where it came from, and the rest is generating the release version info in a way we can generalize. twm doesn't have any of that, and doesn't even have its own version, it's just labeled with the XORG_RELEASE. The other generated files make dev easier by avoiding hand-editing repetitititive code; twm doesn't do any of that. And on down the list. Yeah. It's a lot bigger. But it's doing a lot more too. And how big it is is way less important than how understandable and maintainable it is. I wrote most of it, so I'm hardly unbiased, but I think it's pretty easy to find what you're looking for and understand what it's doing. > I don't like GNU Autotools so much, but it's a billion times better > than CMake, >From the dev side, I contest the crap out of that. Making an autotools setup that does what we're doing with cmake would be a lot of work, and I'd put a heavy burden of proof (including certification of mental stability) on anybody claiming the result would be fractionally as manageable. >From the user side (if they're on a *nix system, at least) it certainly is simpler. Assuming the resultant nightmare-fuel sh scripts are generated right in the tarballs (the number of times ports is having to manually run autoreconf on distfiles give me very low confidence on how easy and widespread that is), they don't need anything their system isn't practically guaranteed to already have, and it'll work. Probably. With cmake, they need cmake. That's not a small drawback. In fact, it's a fairly large one. I absolutely don't want to minimize that. And I also certainly don't claim cmake is distilled rainbows and puppies. The docs are good, but hardly great, and it's not at all easy to find what you're looking for. It has more than a few odd quirks, and several outright bugs (IMO) we've had to work around. I just think that, on balance, it works out in our favor. And by a long way. I suspect you wouldn't speak in favor of gyp or scons or ant or such alternatives; I know I wouldn't. I think claiming autotools is always robust and easy from the user side is... optimistic, and from the dev side is madness. And even manual Makefile writing is a lot harder to do portably than it oughta be. Differing syntax for even trivial things like inclusion, for conditionals, for variable modification, in the names of special vars, etc, mean you're in deep trouble trying to write something non-trivial that works across BSD vs. GNU makes, never mind odder implementations that live out there. You practically have to start writing your own Makefile generators instead of hand-writing them (e.g., in libcidr, I've got awk scripts that generate GNUMakefile.*). And then you still have to invent a configure system for option setting and system discovery; hand-rolling that is guaranteed to be the worst of all possible worlds. That's not to say it's impossible to build _something_ for an escape hatch. As above, it IS still on my list to find some way we can generate a minimal build. It probably won't handle the manual. It probably won't handle dependencies well. It probably won't give much/any scope for configuring. But it'll hopefully give you a ctwm binary. As soon as I find those 45th through 49th hours in the day... -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
