This is complete BS.Īnyway, I can't keep posting in this thread. He knew that making better software sometimes requires breaking compatibility with the old, obsolete software.īut 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. Would Lennart have accepted (his own) argument, and abandoned the systemd project? Of course not. Alternate init systems are "like crack." "It will come back to you if you choose anything else, sooner or later. Well, Lennart, this systemd stuff looks good, but you know, people are familiar with SysV init scripts, and they won't be familiar with your new stuff. Imagine if Lennart had been discussing systemd with someone making the same arguments as you. You will be able to develop software faster and with fewer hassles. Have you ever actually developed a piece of cross-platform software using CMake or Scons? I have. > Windows and autotools on Linux rather then try to use SCONS or CMake for It's much better to use Visual Studio projects on > When you try to use some "universal solution" you usually just make life But as we've discussed ad nauseum, autotools does not support that platform. Whether or not you agree with it, most distributions have a policy of "no bundled libraries."īundling libraries is common and expected on Windows. > If your library uses CMake or SCONS I need to do a lot of manipulations toīundling unrelated libraries with your project is a big no-no on Linux. > in my project, add few lines to configure.ac/Makefile.am - and that's all. > library is autoconfiscated then I can drop the directory with this library It's much better to use Visual Studio projects on Windows and autotools on Linux rather then try to use SCONS or CMake for both. When you try to use some "universal solution" you usually just make life miserable for everyone. Note that some administrators know Windows and some know Linux, but few know both well. Sometimes it's good idea to start with Windows and add Linux port later. Most system administrators are more familiar with Windows than Linux does that mean we should switch? If your library uses CMake or SCONS I need to do a lot of manipulations to convince it to play along. If I'm developer and you library is autoconfiscated then I can drop the directory with this library in my project, add few lines to configure.ac/Makefile.am - and that's all. Maybe what you're trying to refer to, in a very indirect way, is that distribution guys who package software are more familiar with autotools than CMake. And for them Scons/CMake/etc suck - simply because they offer nothing new over autotools and must be treated quite differently to get the same result. But most people who touch your build system are neither developers of your project nor people who are building tarballs - they are people who are using these tarballs. First of all, as I made clear, CMake provides a better experience for both developers and people building tarballs. You may as well talk about preference of people who never seen a computer at all. So what? For them CMake or autoconf make no difference. They simply install the binary package provided by their distribution. Second of all, most users never have to build tarballs. Parent article: libabc: a demonstration library for kernel developers Posted 5:47 UTC (Tue) by khim (subscriber, #9252)
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |