{"thread":{"id":"4511","subject":"Autoconf/Automake","startedAt":"2006-06-14T22:27:10Z","lastAt":"2006-06-16T20:42:44Z","messageCount":26,"participants":["Pavel Roskin","Linus Torvalds","Bertrand Jacquin","Timo Hirvonen","Yann Dirson","Alex Riesen","Olivier Galibert","Jakub Narebski","Phil Richards","Yakov Lerner","Johannes Schindelin","Nikolai Weibull","Jerome Lovy","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21807","messageId":"1150324030.23268.12.camel@dv","threadId":"4511","inReplyTo":null,"subject":"Autoconf/Automake","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-14T22:27:10Z","receivedAt":"2006-06-14T22:27:10Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nIs there any interest in converting the build system used by git to\nAutoconf and Automake? The ad-hoc configuration in Makefile is getting\ntoo big. As for nice features like remembering $prefix, wouldn't it be\nbetter to add them to Automake instead of limiting them to just one\nproject?\n\nOther goodies from Automake are \"make distcheck\" and automatic\ndependency tracking. Compatibility with non-GNU make could earn us some\nrespect from BSD folks.\n\nI converted several projects to the GNU build system, including qgit.\nIt may be hard to get right, but then it just works for any\nconfiguration without giving any trouble.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21809","messageId":"Pine.LNX.4.64.0606141538500.5498@g5.osdl.org","threadId":"4511","inReplyTo":"1150324030.23268.12.camel@dv","subject":"Re: Autoconf/Automake","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-14T22:45:28Z","receivedAt":"2006-06-14T22:45:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Jun 2006, Pavel Roskin wrote:\n> \n> Is there any interest in converting the build system used by git to\n> Autoconf and Automake? The ad-hoc configuration in Makefile is getting\n> too big.\n\nNO! At least the Makefile is debuggable and understandable.\n\nIf we need a better build system, I'd much rather use something \nhigher-level that can generate VC++ project files etc. \n\nIn other words, I'd much rather see us using CMake or something like that, \nwhich actually adds real value-add.\n\n(And no, I've never used cmake, so maybe it has horrors waiting for us \ntoo, but autoconf is just worthless).\n\n\t\t\tLinus\n"},{"id":"21810","messageId":"4fb292fa0606141554p2562cbear8fff960d052e825c@mail.gmail.com","threadId":"4511","inReplyTo":"1150324030.23268.12.camel@dv","subject":"Re: Autoconf/Automake","fromName":"Bertrand Jacquin","fromEmail":"beber.mailing@gmail.com","sentAt":"2006-06-14T22:54:30Z","receivedAt":"2006-06-14T22:54:30Z","isPatch":false,"sender":{"key":"beber.mailing@gmail.com","avatar":null},"body":"On 6/15/06, Pavel Roskin wrote:\n> Hello!\n>\n> Is there any interest in converting the build system used by git to\n> Autoconf and Automake? The ad-hoc configuration in Makefile is getting\n> too big. As for nice features like remembering $prefix, wouldn't it be\n> better to add them to Automake instead of limiting them to just one\n> project?\n\nAutofoo are pretty good but it's unix make dependant, can't create\nbuild files for other build system as Visual, or so on. How don't lost\nhis hairs trying to do autofood his project ?\nCMake seems to be as good for git. And is also expansible.\nGit Makefile is quiet big but not complex, autofood imho will make it\nless stable and usable.\n\n-- \n# Beber : beber@gna.org\n# IM : beber@jabber.fr\n# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}\n"},{"id":"21811","messageId":"20060615021832.4f07a694.tihirvon@gmail.com","threadId":"4511","inReplyTo":"1150324030.23268.12.camel@dv","subject":"Re: Autoconf/Automake","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-06-14T23:18:32Z","receivedAt":"2006-06-14T23:18:32Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Pavel Roskin wrote:\n\n> Hello!\n> \n> Is there any interest in converting the build system used by git to\n> Autoconf and Automake? The ad-hoc configuration in Makefile is getting\n> too big. As for nice features like remembering $prefix, wouldn't it be\n> better to add them to Automake instead of limiting them to just one\n> project?\n> \n> Other goodies from Automake are \"make distcheck\" and automatic\n> dependency tracking. Compatibility with non-GNU make could earn us some\n> respect from BSD folks.\n> \n> I converted several projects to the GNU build system, including qgit.\n> It may be hard to get right, but then it just works for any\n> configuration without giving any trouble.\n\nAutotools almost drove me crazy so I had to write my own configure\nsystem:\n\n http://onion.dynserv.net/~timo/tconf.html\n\nIt is really easy to use and quite flexible.\n\nPersonally I don't think git needs autoconf/tconf/whatever. The current\nmakefile is good enough.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"21821","messageId":"20060615072450.GF7766@nowhere.earth","threadId":"4511","inReplyTo":"1150324030.23268.12.camel@dv","subject":"Re: Autoconf/Automake","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-06-15T07:24:50Z","receivedAt":"2006-06-15T07:24:50Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Wed, Jun 14, 2006 at 06:27:10PM -0400, Pavel Roskin wrote:\n> Is there any interest in converting the build system used by git to\n> Autoconf and Automake? The ad-hoc configuration in Makefile is getting\n> too big. As for nice features like remembering $prefix, wouldn't it be\n> better to add them to Automake instead of limiting them to just one\n> project?\n\nSince there are many people objecting to autotools, what about using\nJam instead ? It has the advantage of being designed to be\ncross-platform, and should have all the features we would need for *git.\n\nWhen compared to autotools, it rather takes the place of automake, and\ncan also be use together with autoconf (or any non-make-specific\nreplacement you can name) if there is a need for it.\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"21832","messageId":"20060615133146.GA5794@steel.home","threadId":"4511","inReplyTo":"20060615072450.GF7766@nowhere.earth","subject":"Re: Autoconf/Automake","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-06-15T13:31:46Z","receivedAt":"2006-06-15T13:31:46Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Yann Dirson, Thu, Jun 15, 2006 09:24:50 +0200:\n> > Is there any interest in converting the build system used by git to\n> > Autoconf and Automake? The ad-hoc configuration in Makefile is getting\n> > too big. As for nice features like remembering $prefix, wouldn't it be\n> > better to add them to Automake instead of limiting them to just one\n> > project?\n> \n> Since there are many people objecting to autotools, what about using\n> Jam instead ? It has the advantage of being designed to be\n> cross-platform, and should have all the features we would need for *git.\n\nExcept that it is not readily available everywhere, has unreadable\nand illogical syntax, and lots of unknown assumptions built in.\nWe are forced to use that thing at work, and it is mostly hated.\n\nGit already has enough external dependencies (crypto, Python, Perl,\nbash, gmake), why create another one?\n\nIf we are about to need a configuration system (and I doubt it), may\nbe we should at least select a system small enough to have it always\nin git repo? (yes, as linux kernel configuration system is)\n"},{"id":"21835","messageId":"20060615163209.GJ7766@nowhere.earth","threadId":"4511","inReplyTo":"20060615133146.GA5794@steel.home","subject":"Re: Autoconf/Automake","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-06-15T16:32:09Z","receivedAt":"2006-06-15T16:32:09Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, Jun 15, 2006 at 03:31:46PM +0200, Alex Riesen wrote:\n> Yann Dirson, Thu, Jun 15, 2006 09:24:50 +0200:\n> > Since there are many people objecting to autotools, what about using\n> > Jam instead ? It has the advantage of being designed to be\n> > cross-platform, and should have all the features we would need for *git.\n> \n> Except that it is not readily available everywhere, has unreadable\n> and illogical syntax, and lots of unknown assumptions built in.\n> We are forced to use that thing at work, and it is mostly hated.\n\nWell, being hated is often the fate of tools for which users got no\ntraining, but are forced to used because of a corporate decision.\nThat does not necessarily mean the tool is bad in itself.\n\n> If we are about to need a configuration system (and I doubt it), may\n> be we should at least select a system small enough to have it always\n> in git repo? (yes, as linux kernel configuration system is)\n\nThe kernel is a beast that is specific enough to need its own build\nsystem, and does not support that many platforms, IIRC. Wrong\nexample, if you want my opinion :)\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"21836","messageId":"Pine.LNX.4.64.0606150954430.5498@g5.osdl.org","threadId":"4511","inReplyTo":"20060615163209.GJ7766@nowhere.earth","subject":"Re: Autoconf/Automake","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-15T17:02:10Z","receivedAt":"2006-06-15T17:02:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 15 Jun 2006, Yann Dirson wrote:\n> \n> Well, being hated is often the fate of tools for which users got no\n> training, but are forced to used because of a corporate decision.\n\nThat's one possible reason.\n\n> That does not necessarily mean the tool is bad in itself.\n\nIt does not _necessarily_ mean that, but let's face it, it really usually \ndoes.\n\nToo many developers shrug off the \"it's hard to use\" argument. THEY think \nit's fine. THEY think it's \"lack of training\". THEY think the tools are \nfine, and the problem is the user.\n\nTHEY are wrong.\n\nAlmost every time when a user says \"it's hard to use\", the user is right. \nSometimes it's a lack of documentation, but quite often it's just that the \ntool interfaces are bad.\n\nOh, I'm sure git has the same problems, but dammit, I think we've tried \nvery hard to listen to user opinions, and make the things that make them \ngo \"that's hard\" be more obvious. All the things that were _possible_ to \ndo if you did them by hand, that you now can do pretty obviously without \neven knowing what it really does. \"git commit -a\". \"git log -p\". \"git show \n\", etc etc. \n\nSometimes the problem space makes the interfaces fundamentally hard. But \nsometimes the program itself just makes things ugly and hard, and autoconf \nand automake definitely didn't make it easier for users - they were \ndesigned for people who knew fifteen different versions of UNIX, and not \nfor sane people.\n\nThese days, there aren't fifteen different versions of UNIX. There's a \ncouple, and it's perfectly ok to actually say \"fix your damn system and \njust install GNU make\". It's easier to install GNU make than it is to \ninstall autoconf/automake.\n\n\t\tLinus\n"},{"id":"21837","messageId":"20060615174833.GA32247@dspnet.fr.eu.org","threadId":"4511","inReplyTo":"Pine.LNX.4.64.0606150954430.5498@g5.osdl.org","subject":"Re: Autoconf/Automake","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-06-15T17:48:33Z","receivedAt":"2006-06-15T17:48:33Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:\n> These days, there aren't fifteen different versions of UNIX. There's a \n> couple, and it's perfectly ok to actually say \"fix your damn system and \n> just install GNU make\". It's easier to install GNU make than it is to \n> install autoconf/automake.\n\nYou should be careful to separate autoconf and automake. Autoconf is\nnot so bad, and you can make clean, maintainable Makefile.in and\nconfig.h.in files with it, because it uses simple substitution. It is\nquite useful to detect available librairies when some are optional,\nand also to lightly[1] ensure that prefix and friends will stay the\nsame between make and make install. Also, especially if you hack a\nlittle bit to alias 'enable' and 'with', you get a sane interface to\noptional feature selection. Oh, and to seperate compilation\ndirectories too (vpath generation).\n\nOTOH, automake is a BDSM session gone bad. The makefiles it generates\nare atrocious and outdated, even buggy on some lesser makes, which is\nquite annoying when what you try to build is gnu make.\n\nThe worst of the lot is libtool, though. That one explicitely tries\nto make your experience as painful as possible. Including, but not\nlimited to, hiding the files in dot-directories so that you try to run\ngdb on a script, relinking at install time, silently removing flags\nyou want to pass to ld or the compiler because it thinks it knows\nbetter, locking C++ shared libraries to the exact compiler version\nthat compiled them through the .la file crap, etc.\n\nSo, autoconf can be useful. The rest should die.\n\n OG.\n\n[1] As in, you can still override when running make, but if you don't\n override anything you'll get the value you passed to configure every\n time.\n"},{"id":"21838","messageId":"e6s7eb$78h$1@sea.gmane.org","threadId":"4511","inReplyTo":"20060615174833.GA32247@dspnet.fr.eu.org","subject":"Re: Autoconf/Automake","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-15T18:03:56Z","receivedAt":"2006-06-15T18:03:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Olivier Galibert wrote:\n\n> On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:\n>> These days, there aren't fifteen different versions of UNIX. There's a \n>> couple, and it's perfectly ok to actually say \"fix your damn system and \n>> just install GNU make\". It's easier to install GNU make than it is to \n>> install autoconf/automake.\n> \n> You should be careful to separate autoconf and automake. Autoconf is\n> not so bad, and you can make clean, maintainable Makefile.in and\n> config.h.in files with it, because it uses simple substitution.\n[...]\n> So, autoconf can be useful. The rest should die.\n\nDoes autoconf generate configure script in POSIX shell, or in bash?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"21839","messageId":"20060615181922.GA36286@dspnet.fr.eu.org","threadId":"4511","inReplyTo":"e6s7eb$78h$1@sea.gmane.org","subject":"Re: Autoconf/Automake","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2006-06-15T18:19:22Z","receivedAt":"2006-06-15T18:19:22Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Thu, Jun 15, 2006 at 08:03:56PM +0200, Jakub Narebski wrote:\n> Does autoconf generate configure script in POSIX shell, or in bash?\n\nIt seems that it still generates bare /bin/sh compatible scripts.\nICBvery easilyW, though.\n\n OG.\n"},{"id":"21842","messageId":"20060615201000.600939E2BC@derisoft.derived-software.demon.co.uk","threadId":"4511","inReplyTo":"20060615133146.GA5794@steel.home","subject":"Re: Autoconf/Automake","fromName":"Phil Richards","fromEmail":"news@derived-software.ltd.uk","sentAt":"2006-06-15T20:10:00Z","receivedAt":"2006-06-15T20:10:00Z","isPatch":false,"sender":{"key":"news@derived-software.ltd.uk","avatar":null},"body":"On 2006-06-15, Alex Riesen wrote:\n> Yann Dirson, Thu, Jun 15, 2006 09:24:50 +0200:\n> > Since there are many people objecting to autotools, what about using\n> > Jam instead ? It has the advantage of being designed to be\n> > cross-platform, and should have all the features we would need for *git.\n> Except that it is not readily available everywhere, has unreadable\n> and illogical syntax, and lots of unknown assumptions built in.\n> We are forced to use that thing at work, and it is mostly hated.\n\nFWIW, I like Boost and use it every day. I hate bjam.\n\n> Git already has enough external dependencies (crypto, Python, Perl,\n> bash, gmake), why create another one?\n> \n> If we are about to need a configuration system (and I doubt it), may\n> be we should at least select a system small enough to have it always\n> in git repo? (yes, as linux kernel configuration system is)\n\nWell, since Python is already a dependency, why not use a build system\nthat has Python as its scripting/extension language? It's also quite\nsmall, and it's called SCons. I found it rather easy to learn\nwhen I was having a quick look around at alternative build systems.\n\nJust a thought.\n\nphil\n-- \nchange name before \"@\" to \"phil\" for email\n"},{"id":"21843","messageId":"f36b08ee0606151317j235d3da9s1304ca9766289a47@mail.gmail.com","threadId":"4511","inReplyTo":"Pine.LNX.4.64.0606150954430.5498@g5.osdl.org","subject":"Re: Autoconf/Automake","fromName":"Yakov Lerner","fromEmail":"iler.ml@gmail.com","sentAt":"2006-06-15T20:17:57Z","receivedAt":"2006-06-15T20:17:57Z","isPatch":false,"sender":{"key":"iler.ml@gmail.com","avatar":null},"body":"On 6/15/06, Linus Torvalds wrote:\n> These days, there aren't fifteen different versions of UNIX. There's a\n> couple, and it's perfectly ok to actually say \"fix your damn system and\n> just install GNU make\". It's easier to install GNU make than it is to\n> install autoconf/automake.\n\nIt's easier to learn GNUmake than to learn autoconf/automake or jam, too.\n\nHowever, the idea of compiling small pieces of main() at the\nconfigure-time to automatically figure what exactly is available --\nI like how well this approach works. It works more\nprecisely than relying on uname.\n\nYakov\n"},{"id":"21844","messageId":"20060615233221.7ad33aea.tihirvon@gmail.com","threadId":"4511","inReplyTo":"20060615201000.600939E2BC@derisoft.derived-software.demon.co.uk","subject":"Re: Autoconf/Automake","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-06-15T20:32:21Z","receivedAt":"2006-06-15T20:32:21Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Phil Richards wrote:\n\n> Well, since Python is already a dependency, why not use a build system\n> that has Python as its scripting/extension language? It's also quite\n> small, and it's called SCons. I found it rather easy to learn\n> when I was having a quick look around at alternative build systems.\n\nOnly git-merge-recursive depends on Python. I hope it will be rewritten\nin C some day.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"21846","messageId":"Pine.LNX.4.63.0606152239270.7480@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4511","inReplyTo":"20060615201000.600939E2BC@derisoft.derived-software.demon.co.uk","subject":"Re: Autoconf/Automake","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-15T20:42:40Z","receivedAt":"2006-06-15T20:42:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jun 2006, Phil Richards wrote:\n\n> On 2006-06-15, Alex Riesen wrote:\n>\n> > Git already has enough external dependencies (crypto, Python, Perl,\n> > bash, gmake), why create another one?\n> > \n> > If we are about to need a configuration system (and I doubt it), may\n> > be we should at least select a system small enough to have it always\n> > in git repo? (yes, as linux kernel configuration system is)\n> \n> Well, since Python is already a dependency, why not use a build system\n> that has Python as its scripting/extension language? It's also quite\n> small, and it's called SCons. I found it rather easy to learn\n> when I was having a quick look around at alternative build systems.\n\nOkay, let's face it. There are gazillions of make clones which \"guarantee\" \nto fix all shortcomings of make. None of them are even close to make \n(regarding developer exposure: take 3 developers, and 1 does not know \nmake, and 2 do not know whatever-your-favourite-make-clone-is).\n\nAs for now, I fail to see why the current system is not adequate for git!\n\nCiao,\nDscho\n"},{"id":"21853","messageId":"20060615211454.GK7766@nowhere.earth","threadId":"4511","inReplyTo":"Pine.LNX.4.64.0606150954430.5498@g5.osdl.org","subject":"Re: Autoconf/Automake","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-06-15T21:14:54Z","receivedAt":"2006-06-15T21:14:54Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:\n> Too many developers shrug off the \"it's hard to use\" argument. THEY think \n> it's fine. THEY think it's \"lack of training\". THEY think the tools are \n> fine, and the problem is the user.\n> \n> THEY are wrong.\n> \n> Almost every time when a user says \"it's hard to use\", the user is right. \n> Sometimes it's a lack of documentation, but quite often it's just that the \n> tool interfaces are bad.\n\nIn tha case of jam, the doc issue can certainly be raised, but the\nmost prominent problem is probably that everyone and their dog knows\nmake, and expects a replacement to work in a similar fashion. The\ncurrent documentation and tutorial unfortunately does not show\nprecisely how people used to \"make\" can easily switch to jam.\n\nFor those not knowing about jam, I'd say the 1st thing to anchor in\none's mind is that jam gives complete (programmatic) control on the\ndependency tree (eg. you just have to write once that the results of a\ncompilation have to be removed by \"jam clean\", and everytime you\ndeclare a file to be built with your rule, you don't have to remember\nto add it to the Clean rule - and more importantly, as soon as you\nremove that declaration, you don't have to fear the Clean target to\nremove it, in case it would be precious).\n\n\n> Sometimes the problem space makes the interfaces fundamentally hard. But \n> sometimes the program itself just makes things ugly and hard, and autoconf \n> and automake definitely didn't make it easier for users - they were \n> designed for people who knew fifteen different versions of UNIX, and not \n> for sane people.\n> \n> These days, there aren't fifteen different versions of UNIX. There's a \n> couple, and it's perfectly ok to actually say \"fix your damn system and \n> just install GNU make\". It's easier to install GNU make than it is to \n> install autoconf/automake.\n\nRight, autoconf would be much more sane if it would not insist on\nsupporting vintage unices. OTOH, people having to work on these\nsystems (eg. for professional reason - not everyone has the luck to\nwork with modern systems all the time) are more than happy to be able\nto build some recent tools to make there task easier. Except when it\nfails in that task (eg. a configure script for the bash package\nfailing to run on an years-old lynxos version because of a sh bug on\nthe OS), it still does a wonderful job in the end.\n\nBut I agree having to carry all this compat stuff, when one just wants\nto benefit from higher-level features (like those mentionned by\nOliver), is annoying. Maybe the support for legacy platforms could be\nrestricted in some way to the bare minimum. Eg. using a \"legacy\"\nbackend where the cruft would go, and stubs for modern things, that\nwould generate a hopefully-more-portable-but-limited\n./configure-simple script, and a \"modern\" backend generating a sane\nfull-fledged bash script.\n\nBut I'm going off-topic :)\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"21857","messageId":"20060615220534.GL7766@nowhere.earth","threadId":"4511","inReplyTo":"Pine.LNX.4.63.0606152239270.7480@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Autoconf/Automake","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-06-15T22:05:34Z","receivedAt":"2006-06-15T22:05:34Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:\n> As for now, I fail to see why the current system is not adequate for git!\n\nI can reassure you, gazillions of people still fail to see why cvs is\nnot adequate for their project. And the ratio of devs in the\ncorporate world not knowning git to those not knowning cvs is far\nsuperior to 2. And everyone here knows cvs is not more adequate than\ngit for so many tasks :)\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"21858","messageId":"Pine.LNX.4.64.0606151545050.5498@g5.osdl.org","threadId":"4511","inReplyTo":"20060615211454.GK7766@nowhere.earth","subject":"Re: Autoconf/Automake","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-15T22:54:34Z","receivedAt":"2006-06-15T22:54:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 15 Jun 2006, Yann Dirson wrote:\n> \n> In tha case of jam, the doc issue can certainly be raised, but the\n> most prominent problem is probably that everyone and their dog knows\n> make,\n\nOh, I agree. A \"simpler\" thing that people don't know is often much \ninferior to a complex thing that people are generally intimately familiar \nwith.\n\nI just personally believe that autoconf/automake are the worst of both \nworlds (ie it's a _complex_ thing that a lot of people don't know).\n\nGNU make in many ways is actually not that bad. Yeah, the makefiles get \nmore complex, but it's usually not totally unreadable, and you can do some \nclever stuff with it. \n\nThe kernel makefiles are a pretty extreme example (and it hides a lot of \nthe complexity in files that get included and that most people never ever \nneed to look at). I suspect that git could more easily do something like \nthat (on a _much_ smaller scale - don't get me wrong).\n\n\t\t\tLinus\n"},{"id":"21859","messageId":"Pine.LNX.4.63.0606160053560.7480@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4511","inReplyTo":"20060615220534.GL7766@nowhere.earth","subject":"Re: Autoconf/Automake","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-15T22:58:30Z","receivedAt":"2006-06-15T22:58:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 16 Jun 2006, Yann Dirson wrote:\n\n> On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:\n> > As for now, I fail to see why the current system is not adequate for git!\n> \n> I can reassure you, gazillions of people still fail to see why cvs is\n> not adequate for their project. And the ratio of devs in the\n> corporate world not knowning git to those not knowning cvs is far\n> superior to 2. And everyone here knows cvs is not more adequate than\n> git for so many tasks :)\n\nYou know as well as I that this comparison is unfair. I am _NOT_ a \ncorporate person. I hope that you do not judge me as a complete airhead.\n\nThe point is: the right tool solves the problem. You can have a tool which \nis mighty cool, but way too powerful (AKA complicated).\n\nAs for CVS: there _are_ a few use cases where CVS is just the right tool. \nThere are many more use cases where git is more than adequate, where CVS \nis not.\n\n_BUT_: there are cases where something like autoconf/jam/cmake/blablabla \nis adequate, but I still fail to see why for git, the makefile system \nshould not work. It is the most transparent way to configure a make system \nI encountered. It is short, concise, and does the job. And I understand \nit. As opposed to autoconf/jam/cmake/blablabla.\n\nHth,\nDscho\n"},{"id":"21860","messageId":"Pine.LNX.4.63.0606160105100.7480@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4511","inReplyTo":"Pine.LNX.4.64.0606151545050.5498@g5.osdl.org","subject":"Re: Autoconf/Automake","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-15T23:10:09Z","receivedAt":"2006-06-15T23:10:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jun 2006, Linus Torvalds wrote:\n\n> On Thu, 15 Jun 2006, Yann Dirson wrote:\n> > \n> > In tha case of jam, the doc issue can certainly be raised, but the\n> > most prominent problem is probably that everyone and their dog knows\n> > make,\n> \n> Oh, I agree. A \"simpler\" thing that people don't know is often much \n> inferior to a complex thing that people are generally intimately familiar \n> with.\n> \n> I just personally believe that autoconf/automake are the worst of both \n> worlds (ie it's a _complex_ thing that a lot of people don't know).\n> \n> GNU make in many ways is actually not that bad. Yeah, the makefiles get \n> more complex, but it's usually not totally unreadable, and you can do some \n> clever stuff with it. \n\nI can add to that with first-hand experience of ant and maven.\n\nA whole sh*t-load of people think make is broken. It does not live up to \nwhat they want, and it is slow.\n\nAnd then they invent a _DISEASE_ like ant, which _does not begin_ to sport \nthe features of make.\n\nIn a project I am stuck in, maven is used. It tries -- of all things -- to \nfix a few shortcomings of ant -- which was supposed to fix shortcomings of \nmake! And let's face it. Maven is complicated, slow as a dog lacking all \nfour feet, and it still does not do the things I can do in three lines \nwith make. It's a complete desaster.\n\nSo to keep the discussion on topic: tell me what you want to fix wrt the \ncurrent setup of git, and I'll try to fix it in less than 10 lines of make \ncode. If that is impossible, let's continue then and there with the \ndiscussion about a switch to a newer, less tested, replacement of make, \nokay?\n\nCiao,\nDscho\n"},{"id":"21873","messageId":"dbfc82860606152351t20b73948m646a12e2e478daaa@mail.gmail.com","threadId":"4511","inReplyTo":"Pine.LNX.4.63.0606160105100.7480@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Autoconf/Automake","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2006-06-16T06:51:22Z","receivedAt":"2006-06-16T06:51:22Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 6/16/06, Johannes Schindelin wrote:\n\n> In a project I am stuck in, maven is used. It tries -- of all things -- to\n> fix a few shortcomings of ant -- which was supposed to fix shortcomings of\n> make! And let's face it. Maven is complicated, slow as a dog lacking all\n> four feet, and it still does not do the things I can do in three lines\n> with make. It's a complete desaster.\n\nBut...it uses XML...how can it not be a panacea?\n\n nikolai\n"},{"id":"21875","messageId":"e6tso3$s3s$1@sea.gmane.org","threadId":"4511","inReplyTo":"20060615174833.GA32247@dspnet.fr.eu.org","subject":"Re: Autoconf/Automake","fromName":"Jerome Lovy","fromEmail":"rqe28bj3vfyi4eo@jetable.net","sentAt":"2006-06-16T09:06:02Z","receivedAt":"2006-06-16T09:06:02Z","isPatch":false,"sender":{"key":"rqe28bj3vfyi4eo@jetable.net","avatar":null},"body":"Olivier Galibert wrote:\n> On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:\n> \n>>These days, there aren't fifteen different versions of UNIX. There's a \n>>couple, and it's perfectly ok to actually say \"fix your damn system and \n>>just install GNU make\". It's easier to install GNU make than it is to \n>>install autoconf/automake.\n> \n> \n> You should be careful to separate autoconf and automake. Autoconf is\n> not so bad, and you can make clean, maintainable Makefile.in and\n> config.h.in files with it, because it uses simple substitution. It is\n> quite useful to detect available librairies when some are optional,\n> and also to lightly[1] ensure that prefix and friends will stay the\n> same between make and make install. Also, especially if you hack a\n> little bit to alias 'enable' and 'with', you get a sane interface to\n> optional feature selection. Oh, and to seperate compilation\n> directories too (vpath generation).\n\nI fully agree with Olivier. It seems to me that you don't have to buy \nthe whole autoconf/automake/libtool stack to leverage the autoconf \nfunctionality. autoconf alone provides the full \"autoconfiguration\" \nframework (running scriptlets and setting substitution variables \naccordingly). You still have to write Makefile.in (with statements \nlooking like: CC=@CC@). Therefore the resulting Makefile is just as \nbeautiful or as ugly as you wrote the initial Makefile.in: you have full \ncontrol over it.\n\nAs for dependencies, one shouldn't confuse what is needed on the \nautoconfiguration developer's side (in order to build the configure \nscript from the configure.in file) and what is needed on the installer's \nside to run the configure script and process the generated makefile. The \nformer needs the autoconf package which itself relies on GNU m4. The \nlatter merely needs a decently compatible Bourne shell and a decently \ncompatible make.\n\nOn the other hand, what you get with automake is a fully automatically \ngenerated makefile, with make targets conforming to the GNU standards. \nBut then you fully loose control over the Makefile: you don't write the \nMakefile.in anymore (automake does it for you) but rather the terce \nMakefile.am. In this respect, automake is like imake: you write few \nlines of (i)makefile, but then you cannot complain if you don't \nunderstand what comes in the generated makefile ;-) .\n\nJérôme Lovy\n"},{"id":"21900","messageId":"20060616182349.GF2609@pasky.or.cz","threadId":"4511","inReplyTo":"e6s7eb$78h$1@sea.gmane.org","subject":"Re: Autoconf/Automake","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-16T18:23:49Z","receivedAt":"2006-06-16T18:23:49Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Jun 15, 2006 at 08:03:56PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Does autoconf generate configure script in POSIX shell, or in bash?\n\n/bin/sh, but on such a degree that it avoids using even functions -\nwhich makes the resulting ./configure script quite awful. autoconf is\n*much* better than automake (libtool I shall refrain commenting on\nentirely; eeeek) in that you have much more free hand in bending it\nin case it does something stupid, but the resulting ./configure script\nis still mammoth and barely readable.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"},{"id":"21901","messageId":"20060616183100.GG2609@pasky.or.cz","threadId":"4511","inReplyTo":"20060615220534.GL7766@nowhere.earth","subject":"Re: Autoconf/Automake","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-16T18:31:00Z","receivedAt":"2006-06-16T18:31:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jun 16, 2006 at 12:05:34AM CEST, I got a letter\nwhere Yann Dirson said that...\n> On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:\n> > As for now, I fail to see why the current system is not adequate for git!\n> \n> I can reassure you, gazillions of people still fail to see why cvs is\n> not adequate for their project. And the ratio of devs in the\n> corporate world not knowning git to those not knowning cvs is far\n> superior to 2. And everyone here knows cvs is not more adequate than\n> git for so many tasks :)\n\nDuh. That works the same way when I replace the original question with\n\"As for now, I fail to see to see why Linux is not adequate for my\ndesktop! (In contrast with AIX.)\".\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"},{"id":"21907","messageId":"20060616201715.GM7766@nowhere.earth","threadId":"4511","inReplyTo":"Pine.LNX.4.63.0606160053560.7480@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Autoconf/Automake","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2006-06-16T20:17:15Z","receivedAt":"2006-06-16T20:17:15Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Jun 16, 2006 at 12:58:30AM +0200, Johannes Schindelin wrote:\n> > On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:\n> > > As for now, I fail to see why the current system is not adequate for git!\n> > \n> > I can reassure you, gazillions of people still fail to see why cvs is\n> > not adequate for their project. And the ratio of devs in the\n> > corporate world not knowning git to those not knowning cvs is far\n> > superior to 2. And everyone here knows cvs is not more adequate than\n> > git for so many tasks :)\n> \n> You know as well as I that this comparison is unfair. I am _NOT_ a \n> corporate person. I hope that you do not judge me as a complete airhead.\n\nWell, I have to apologize - especially after looking closer at the\ncurrent Makefile. I think I understand now why autoconf was suggested\nin the first place, but it what it would achieve would mostly moving\nthe ifdef's to configure.ac, which would not be such a gain anyway.\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"21908","messageId":"20060616204244.GH2609@pasky.or.cz","threadId":"4511","inReplyTo":"20060616201715.GM7766@nowhere.earth","subject":"Re: Autoconf/Automake","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-06-16T20:42:44Z","receivedAt":"2006-06-16T20:42:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jun 16, 2006 at 10:17:15PM CEST, I got a letter\nwhere Yann Dirson said that...\n> On Fri, Jun 16, 2006 at 12:58:30AM +0200, Johannes Schindelin wrote:\n> > > On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:\n> > > > As for now, I fail to see why the current system is not adequate for git!\n> > > \n> > > I can reassure you, gazillions of people still fail to see why cvs is\n> > > not adequate for their project. And the ratio of devs in the\n> > > corporate world not knowning git to those not knowning cvs is far\n> > > superior to 2. And everyone here knows cvs is not more adequate than\n> > > git for so many tasks :)\n> > \n> > You know as well as I that this comparison is unfair. I am _NOT_ a \n> > corporate person. I hope that you do not judge me as a complete airhead.\n> \n> Well, I have to apologize - especially after looking closer at the\n> current Makefile. I think I understand now why autoconf was suggested\n> in the first place, but it what it would achieve would mostly moving\n> the ifdef's to configure.ac, which would not be such a gain anyway.\n\nExcept that then I don't need to bother manually adding NO_EXPAT to the\nmakefile on all systems I compile git on.\n\nYes, it's not a huge bother per se, but since almost all other\nnon-obscure projects do figure these things out automagically, git kind\nof stands out negatively here. \"Wah, it needs me tweak the Makefile to\nbe able to compile it.\"\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nA person is just about as big as the things that make them angry.\n"}]}