Recent Features
| |||||||||||||
Hmm...Hmm...Posted Nov 7, 2011 16:46 UTC (Mon) by khim (subscriber, #9252)In reply to: Hmm... by cmccabe Parent article: libabc: a demonstration library for kernel developers
CMake manages to support Windows, Mac, Linux, and many other platforms, so I don't see why we should accept anything less out of a supposedly portable build system. Because it refuses to support the most important platform: GNU. GNU standard is "./configure ; make ; make install". If you don't support that standard that means that you've put portability to other systems ahead of portability to GNU system. Which is kinda stupid for the Linux library because Linux is often used as part of GNU system. Even libraries which end up installed in non-GNU systems (like Android or OpenWRT) are usually build on GNU system and should follow GNU conventions. I have to ask: don't your developers and users deserve something a little better than "barely good enough"? Yes. They deserve system where hundred of packages can be changed using the same approach (config.site). They deserve system where said packages can be multiarch compiled in regular manner and installed using the same approach (make "install-exec"/make "install-data"). They deserve system where you can combine different packages in one "superpackage" easily. In short: they deserve to have capabilities of autotools. This all works only if you use autotools exclusively. It may be possible to create something like this starting from CMake, I don't know, but since GNU is build around autotools... autotools that is. Are you really too old to learn something new? I'm not too old to learn something new, but I'm definitely too old to start pointless crusade with goal of total replacement of autotools with CMake. And world with a mix of autotools and CMake is much, much, worse then world of pure autotools.
(Log in to post comments)
Hmm... Posted Nov 7, 2011 19:47 UTC (Mon) by cmccabe (guest, #60281) [Link]
[snip discussion of other platforms]
Android doesn't use autotools. They knew better than touch that mess. They use plain old makefiles. However, they do use GNU Make extensions. I have not used OpenWRT, so I don't know what build system they use.
> I'm not too old to learn something new, but I'm definitely too old to
We already live in a world with a mix of autotools and other things.
The kernel doesn't use autotools (which makes kernel hackers recommending autotools unintentionally ironic.) KDE uses CMake. MySQL is transitioning from autotools to CMake. Anything that is portable to Windows (like openoffice, the gimp, etc.) will need to have a parallel build system to handle that platform, because autotools can't.
Android itself has serious NIH syndrome... Posted Nov 8, 2011 6:15 UTC (Tue) by khim (subscriber, #9252) [Link] Android doesn't use autotools. They knew better than touch that mess. I know. They create their own mess instead. As usual it makes life easier for them (albeit not by much: lots of Android developers just like lots of Chrome developers hate GYP - but since they must support Windows it stays). When you develop software for android you don't need to bother with all that and use can easily use NDK and autotools. We already live in a world with a mix of autotools and other things. No. We live in a world of autotools with some additional abominations here and there. Every time you hit yet another such project (be it pure Makefile-based project like libgd or CMake-based project like OpenSceneGraph) you have a problem. Often the problem is eventually solved by autoconfiscation (last version of libgd uses autotools like sane package), sometimes you must tolerate the abomintation (bzip2 is standard example), but if your project needs such a library it's always a problem. KDE uses CMake. Thankfully KDE is it's own "distribution in the distribution": it's hard to use KDE libraries outside of KDE for reasons other then build system thus it's not important what it uses. MySQL is transitioning from autotools to CMake. This one is problematic, yes, but one can always switch to MariaDB. As I've said: non-autoconfiscated libraries are always a problem, but if you are well-established and important project you can get away with it. New library will be just rejected. The kernel doesn't use autotools (which makes kernel hackers recommending autotools unintentionally ironic.) This is not a recommendation of kernel hackers. This is recommendation for kernel hackers by people who develop userspace plumbing. Kernel uses it's own conventions because, in a sense, kernel is it's own universe: it can not use standard libraries at all, it must use some foul tricks to make the whole thing work on bare metal, etc.
Android itself has serious NIH syndrome... Posted Nov 8, 2011 17:39 UTC (Tue) by cmccabe (guest, #60281) [Link]
> I know. They create their own mess instead. As usual it makes life easier
> for them (albeit not by much: lots of Android developers just like lots of > Chrome developers hate GYP - but since they must support Windows it > stays). When you develop software for android you don't need to bother > with all that and use can easily use NDK and autotools.
I work on Android for NVidia. We do not use gyp. In fact, I am not familiar with that build system. We use the Android build system, which is simply makefiles which use GNU extensions. If you want to learn more about it, you can check it out here: http://git.android-x86.org/?p=platform/build.git;a=summary
I have developed software for Android before, including using the NDK. The NDK also relies on makefiles. There is no automake or autotools component. You have to write an Android.mk file to build whatever you're building. The Java software you develop on Android builds with ant. Again, there is no autotools.
What it boils down to is this: we both agree that autotools is mediocre at best. Are you willing to tolerate mediocrity? I'm not.
Android itself has serious NIH syndrome... Posted Nov 8, 2011 20:26 UTC (Tue) by mpr22 (subscriber, #60784) [Link] Unfortunately, it appears that no potential replacement for autotools is sufficiently widely regarded as having a clear and compelling edge over it - indeed, most of them appear to be Marmite.
Hmm... Posted Nov 10, 2011 14:04 UTC (Thu) by nix (subscriber, #2304) [Link]
As an aside, I don't have a problem with cmake, except that it is pointlessly hard to get the equivalent of 'configure --help': you have to make a new directory, cd into it, then do ccmake .. and hit 'c', then note down the flags you want, quit, and wipe the directory (assuming you want to note those flags down for your autobuilder rather than make it by hand).
But as for supporting an equivalent of config.site... well, all my config.site does is runs a shell script under 'eval', passing in as arguments those 'variables set by options' by configure whose default value is non-NULL. All I have to do for cmake is arrange for my autobuilder to add default arguments to the cmake invocation which are computed by calling the same shell script and doing a few trivial transformations of the output with sed (to change configure-style variable names to cmake-style command-line arguments). This is not hard. My configure-running script is 85 lines; my cmake-running script is 32, mostly comments. I don't see the point of whining over 32 lines and half an hour's shell script hacking.
Hmm... Posted Nov 10, 2011 16:17 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link]
> it is pointlessly hard to get the equivalent of 'configure --help'
And why isn't there a wrapper script named 'configure' that offers an autotools-compatible interface? This should be possible for all build systems that can generate makefiles.
Hmm... Posted Nov 11, 2011 16:50 UTC (Fri) by nix (subscriber, #2304) [Link]
Quite. The command-line interface of CMake is pretty horrible all round: the -DCAPITAL_LETTERS=FOO interface is very silly. That D is pure excise. Why the cmake authors thought that modelling the command line on a C preprocessor rather than on getopt_long() -- a far more common program invocation syntax -- is quite beyond me.
|
|||||||||||||