{"thread":{"id":"11169","subject":"In future, to replace autotools by cmake like KDE4 did?","startedAt":"2007-12-07T02:10:36Z","lastAt":"2007-12-10T20:23:43Z","messageCount":8,"participants":["J.C. Pizarro","Marcel Holtmann","Jakub Narebski","Andreas Ericsson","Marco Costalba","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"62227","messageId":"998d0e4a0712061810k18e6388jde9d7bc5bd006b57@mail.gmail.com","threadId":"11169","inReplyTo":null,"subject":"In future, to replace autotools by cmake like KDE4 did?","fromName":"J.C. Pizarro","fromEmail":"jcpiza@gmail.com","sentAt":"2007-12-07T02:10:36Z","receivedAt":"2007-12-07T02:10:36Z","isPatch":false,"sender":{"key":"jcpiza@gmail.com","avatar":null},"body":"The autotools ( automake + libtool + autoconf + ... ) generate many big\nfiles that they have been slowing the building's computation and growing\nenormously their cvs/svn/git/hg repositories because of generated files.\n\nTo see below interesting links:\n1. http://dot.kde.org/1172083974/\n2. http://sam.zoy.org/lectures/20050910-debian/\n3. https://lwn.net/Articles/188693/\n4. http://en.wikipedia.org/wiki/GNU_Build_Tools\n5. http://en.wikipedia.org/wiki/GNU_Automake\n\nThe benefits could be:\n* +40% faster in the KDE4 building vs KDE 3.5.6.\n* elimination of redundant and unnecesary generated files as those\n from autotools.\n* smaller cvs/svn/git/hg repositories.\n* less errors/crashes when it's configuring.\n* can be improved the cmake's sources for better performance's gain.\n* good and long maintainance life.\n\nI hope if the files for cmake+make can be well integrated in GCC 4.4\n\n J.C.Pizarro\n"},{"id":"62256","messageId":"7FAE3E89-4C56-47AE-8AD8-9191D6BB8FAC@holtmann.org","threadId":"11169","inReplyTo":"998d0e4a0712061810k18e6388jde9d7bc5bd006b57@mail.gmail.com","subject":"Re: In future, to replace autotools by cmake like KDE4 did?","fromName":"Marcel Holtmann","fromEmail":"marcel@holtmann.org","sentAt":"2007-12-07T07:56:47Z","receivedAt":"2007-12-07T07:56:47Z","isPatch":false,"sender":{"key":"marcel@holtmann.org","avatar":null},"body":"Hi,\n\n> The autotools ( automake + libtool + autoconf + ... ) generate many \n> big\n> files that they have been slowing the building's computation and \n> growing\n> enormously their cvs/svn/git/hg repositories because of generated \n> files.\n>\n> To see below interesting links:\n> 1. http://dot.kde.org/1172083974/\n> 2. http://sam.zoy.org/lectures/20050910-debian/\n> 3. https://lwn.net/Articles/188693/\n> 4. http://en.wikipedia.org/wiki/GNU_Build_Tools\n> 5. http://en.wikipedia.org/wiki/GNU_Automake\n>\n> The benefits could be:\n> * +40% faster in the KDE4 building vs KDE 3.5.6.\n> * elimination of redundant and unnecesary generated files as those\n> from autotools.\n> * smaller cvs/svn/git/hg repositories.\n\nstop spreading this FUD. If you leave the auto-generated files from \nautotools in the source control repositories, then it is your fault. \nThey are generated files and can always be generated. Hence putting \nthem under revision control makes no sense and so don't do it. And \nmore certain don't complain about it if you did.\n\nRegards\n\nMarcel\n"},{"id":"62276","messageId":"m3lk86u2fq.fsf@roke.D-201","threadId":"11169","inReplyTo":"998d0e4a0712061810k18e6388jde9d7bc5bd006b57@mail.gmail.com","subject":"Re: In future, to replace autotools by cmake like KDE4 did?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-07T12:14:42Z","receivedAt":"2007-12-07T12:14:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"J.C. Pizarro\" writes:\n\n> The autotools ( automake + libtool + autoconf + ... ) generate many big\n> files that they have been slowing the building's computation and growing\n> enormously their cvs/svn/git/hg repositories because of generated files.\n[cut]\n\nAnd this is relevant for this mailing list exactly how? From the whole\nautotools package git uses only autoconf, and only as an optional part\nto configure only Makefile configuration variables.\n\nGenerated files should not be put into version control, unless it is\nfor convenience only in separate branch like HTML and manpage versions\nof git documentation are in 'html and 'man' branches, respectively.\nThe same could be done with ./configure script.\n\nAlthough there was some talk about whether giw should use autotools,\nor perhaps CMake, or handmade ./configure script like MPlayer IIRC,\ninstead of its own handmade Makefile...\n\n-- \nJakub Narebski\nShadeHawk on #git\n"},{"id":"62281","messageId":"47594021.40200@op5.se","threadId":"11169","inReplyTo":"m3lk86u2fq.fsf@roke.D-201","subject":"Re: In future, to replace autotools by cmake like KDE4 did?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-12-07T12:44:17Z","receivedAt":"2007-12-07T12:44:17Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> \n> Although there was some talk about whether giw should use autotools,\n> or perhaps CMake, or handmade ./configure script like MPlayer IIRC,\n> instead of its own handmade Makefile...\n> \n\nTo tell the truth, I'd be much happier if everything like that got\nput in a header file or some such. 95% of what we figure out by looking\nat \"uname\" output can already be learned by looking at the various\npre-defined macros.\n\nFortunately, there's a project devoted solely to this, so most of\nthe tedious research need not be done. It can be found at\nhttp://predef.sourceforge.net/\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"62288","messageId":"200712071456.11019.jnareb@gmail.com","threadId":"11169","inReplyTo":"47594021.40200@op5.se","subject":"Re: In future, to replace autotools by cmake like KDE4 did?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-07T13:56:09Z","receivedAt":"2007-12-07T13:56:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n> Jakub Narebski wrote:\n> > \n> > Although there was some talk about whether giw should use autotools,\n> > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,\n> > instead of its own handmade Makefile...\n> > \n> \n> To tell the truth, I'd be much happier if everything like that got\n> put in a header file or some such. 95% of what we figure out by looking\n> at \"uname\" output can already be learned by looking at the various\n> pre-defined macros.\n> \n> Fortunately, there's a project devoted solely to this, so most of\n> the tedious research need not be done. It can be found at\n> http://predef.sourceforge.net/\n\nCode talks, bullsh*t walks.\n\nPre-defined macros cannot tell us if one have specific libraries\ninstalled, cannot tell us if formatted IO functions support 'size\nspecifiers' even though compiler claim C99 compliance or even though\ncompiler doesn't claim C99 compliance but supports this, etc.\n\nBut perhaps the \"uname\" based compile configuration could be replaced\nby testing pre-defined macros... at least for C code, and git is not\nonly C code.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"62289","messageId":"998d0e4a0712070642u6ae75232t9cb5bfd0920b2439@mail.gmail.com","threadId":"11169","inReplyTo":"200712071456.11019.jnareb@gmail.com","subject":"Re: In future, to replace autotools by cmake like KDE4 did?","fromName":"J.C. Pizarro","fromEmail":"jcpiza@gmail.com","sentAt":"2007-12-07T14:42:31Z","receivedAt":"2007-12-07T14:42:31Z","isPatch":false,"sender":{"key":"jcpiza@gmail.com","avatar":null},"body":"On 2007/12/7, Jakub Narebski wrote:\n> Andreas Ericsson wrote:\n> > Jakub Narebski wrote:\n> > >\n> > > Although there was some talk about whether giw should use autotools,\n> > > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,\n> > > instead of its own handmade Makefile...\n> > >\n> >\n> > To tell the truth, I'd be much happier if everything like that got\n> > put in a header file or some such. 95% of what we figure out by looking\n> > at \"uname\" output can already be learned by looking at the various\n> > pre-defined macros.\n> >\n> > Fortunately, there's a project devoted solely to this, so most of\n> > the tedious research need not be done. It can be found at\n> > http://predef.sourceforge.net/\n>\n> Code talks, bullsh*t walks.\n>\n> Pre-defined macros cannot tell us if one have specific libraries\n> installed, cannot tell us if formatted IO functions support 'size\n> specifiers' even though compiler claim C99 compliance or even though\n> compiler doesn't claim C99 compliance but supports this, etc.\n>\n> But perhaps the \"uname\" based compile configuration could be replaced\n> by testing pre-defined macros... at least for C code, and git is not\n> only C code.\n>\n> --\n> Jakub Narebski\n> Poland\n>\n\nA powerful tool can do better things that old generators-based tools\n(as autotools).\n\nTo imagine, there are many scripts in subdirectories or subprojects:\n\n* Before: (many copy and paste of code as below paragraph)\nA_VARIABLE_OS = `uname -a | grep .... ` # <- slow\ncase \"$A_VARIABLE_OS\" in\n *linux*) ... ;;\n *bsd*) ... ;;\n *aix*) ... ;;\n *) ...;;\nesac\nm4 foo.sh.m4 > bar.sh # <- very slow\n./bar.sh\n\n* Later: (with the powerful tool that had cached many predefined variables in\n a ramdisk's file or in a daemon's memory)\n# call once at 1st time to internal uname of powerful tool for all ocurrences of\n# below predefined variable from many scripts:\ncase \"$FOO_VARIABLE_OS\" in\n *linux*) ... ;;\n *bsd*) ... ;;\n *aix*) ... ;;\n *) ...;;\nesac\n# i don't need to generate more scripts to inspect still more it.\n\n J.C.Pizarro\n"},{"id":"62294","messageId":"e5bfff550712070810p6beb0becs54280cb0f1f02637@mail.gmail.com","threadId":"11169","inReplyTo":"998d0e4a0712070642u6ae75232t9cb5bfd0920b2439@mail.gmail.com","subject":"Re: In future, to replace autotools by cmake like KDE4 did?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-12-07T16:10:51Z","receivedAt":"2007-12-07T16:10:51Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Dec 7, 2007 3:42 PM, J.C. Pizarro wrote:\n>\n> A powerful tool can do better things that old generators-based tools\n> (as autotools).\n>\n--- cut ---\n\n>\n> * Later: (with the powerful tool that had cached many predefined variables in\n\nInsisting on highlighting your proposal as \"powerful tool\" vs what is\nin git now (on which people spent long hours to tune it out) will give\nyou hard times on this list ;-)\n\nJust my guess...\n\nMarco\n"},{"id":"62614","messageId":"20071210202343.GB3517@efreet.light.src","threadId":"11169","inReplyTo":"998d0e4a0712070642u6ae75232t9cb5bfd0920b2439@mail.gmail.com","subject":"Re: In future, to replace autotools by cmake like KDE4 did?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-12-10T20:23:43Z","receivedAt":"2007-12-10T20:23:43Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Dec 07, 2007 at 15:42:31 +0100, J.C. Pizarro wrote:\n> A powerful tool can do better things that old generators-based tools\n> (as autotools).\n> \n> To imagine, there are many scripts in subdirectories or subprojects:\n\nNo, there are not. There is just one. Multiple configuration scripts rarely\nmake sense.\n\n> * Before: (many copy and paste of code as below paragraph)\n> A_VARIABLE_OS = `uname -a | grep .... ` # <- slow\n> case \"$A_VARIABLE_OS\" in\n> *linux*) ... ;;\n> *bsd*) ... ;;\n> *aix*) ... ;;\n> *) ...;;\n> esac\n> m4 foo.sh.m4 > bar.sh # <- very slow\n\nDone once at release time.\n\n> ./bar.sh\n> \n> * Later: (with the powerful tool that had cached many predefined variables in\n> a ramdisk's file or in a daemon's memory)\n\nA daemon not runnin' here. No ramdisk here either. Freshly downloaded tarball\nto an ancient Un*x with some quirky barely POSIX-compliant shell.\n\n> # call once at 1st time to internal uname of powerful tool for all ocurrences of\n> # below predefined variable from many scripts:\n> case \"$FOO_VARIABLE_OS\" in\n\nSomeone had to create that variable. And there is just one way to: uname -a | ....\n\n> *linux*) ... ;;\n> *bsd*) ... ;;\n> *aix*) ... ;;\n> *) ...;;\n> esac\n\nAnd how exactly does this differ from the code you had above? For task that\nruns once per installation (and for most users never, because their\ndistribution's build server runs it for them), it's simplicity of code that\nmatters.\n\n> # i don't need to generate more scripts to inspect still more it.\n\nAnd how exactly did you find, from the uname, whether I have libcrypto\ninstalled? And whether I have it in /usr/lib, /opt/openssl/lib or\n/usr/@foobar.com/sw/system/lib? How did you find libcurl, tcl, zlib...?\n\nBesides, I inspected the configure.ac script that comes with git and it does\nnot actually contain any code like you show above. Git's configure script is\nNOT looking at the platform name AT ALL. The makefile does, but that\nobviously does not need anything generated by M4.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}