That's why I've said "not just distribution guys".
Posted Nov 9, 2011 13:42 UTC (Wed) by khim
In reply to: This is stupid argument...
Parent article: libabc: a demonstration library for kernel developers
Bundling unrelated libraries with your project is a big no-no on Linux.
I don't know why will you ever want to add "unrelated" library - usually you bundle related library :-)
Indeed, even GNU Hello does that.
Whether or not you agree with it, most distributions have a policy of "no bundled libraries."
That's different. That's for packagers in distributions. And yes, autotools support them just fine, too. Aforementioned GNU Hello will only use bundled library if gettext is not available on the host system (and on host system with GLibC it's always available).
Have you ever actually developed a piece of cross-platform software using CMake or Scons?
Sure. In fact that's why I'm so against them. I do know them - and I hate them. We use Scons here for Native Client development - and I hate it. Simple things which are trivial with autotools (for example: "compile the same sources for four different platforms: one native and three cross" or "compile the some sources twice using different compilers to compare output") become serious problem and require a lot of kludges.
You will be able to develop software faster and with fewer hassles.
Somehow I'm not seeing this. Not only build is unbearably long (this is Scons problem, CMake does not share this particular problem), but I have nothing like "make distcheck". A lot of similar simple amenities are lost when you start using "modern advanced build systems".
Imagine if Lennart had been discussing systemd with someone making the same arguments as you.
I'd laugh very loud.
...are hard to do with SysV init scripts...
...every distribution is unique, there are no standard amond sysv-init based systems...
portability between distros
...does not exist: if you'll try to move startup script from RedHat to Debian or back it'll not work... even if we'll forget about things like Gentoo...
Would Lennart have accepted (his own) argument, and abandoned the systemd project?
Why would he abandon it? The right answer (and this is exactly what Lennart did) is to discuss the common tasks people need to perform and translate "sysv-init solutions" to "systemd solutions". In fact Lennart spent sizable effort doing it.
He knew that making better software sometimes requires breaking compatibility with the old, obsolete software.
Bwa-ha-ha. Don't make me explode. The very description of systemd is systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts (emphasis mine). One of the PulseAudio FAQs is Can I get OSS and ALSA applications to work with PulseAudio? and answer is, of course, yes.
Lennart is low-level guy, not GNOME guy. He knows compatibility is important. That is why his creations are accepted as a replacement for the "old way". Apparently "new, improved" build systems are created by guys who don't know that. Oh, well, their loss, then.
Compatibility can never be perfect, I understand that, but when I'm presented with "new super-puper build system" and ask how to do simple and important (to me) tasks I usually hear either "nobody needs that" or "you can probably invent a kludge" or even "patches are welcome". Sorry, guys, but it's your resposibility to provide backward-compatibility with "the old way" in your creation, not mine. I can live with rare and insignificant problems but when I ask trivial, simple, obvious, question "how to add autoconfiscated library to my build" and hear some tales about how I should not do that... well, sorry, no way I'd accept this build system.
But when it comes to build systems, people are still repeating the old myth that there are no viable alternatives to autotools-- that everything else is somehow suspect or tainted, that nobody will ever be able to learn the new thing. This is complete BS.
Sorry, but no, this is not a "complete BS". You can say anything you want about Lennart, but the important fact is that both systemd and pulseaudio do include support for important predecessors while CMake, Scons, Waf and others in their arrogance ignore autotools. Well, it's their problem, not mine. They may be interesting for people who need to support Windows more then they need to support GNU, but in the GNU world autotools will remain standard till someone invents good and compatible replacement.
to post comments)