{"thread":{"id":"3037","subject":"git binary size...","startedAt":"2006-01-11T18:26:17Z","lastAt":"2006-01-20T18:00:09Z","messageCount":18,"participants":["Linus Torvalds","Andreas Ericsson","Junio C Hamano","H. Peter Anvin","Coywolf Qi Hunt","Johannes Schindelin","Jon Loeliger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14481","messageId":"Pine.LNX.4.64.0601111021450.5073@g5.osdl.org","threadId":"3037","inReplyTo":null,"subject":"git binary size...","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-11T18:26:17Z","receivedAt":"2006-01-11T18:26:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nGuess what the difference is here?\n\n\t[torvalds@g5 ~]$ du -sh bin/\n\t14M     bin/\n\t[torvalds@g5 ~]$ du -sh bin/\n\t5.8M    bin/\n\nGive up?\n\nIn one case, \"git\" was compiled with the default options in the git \nMakefile. In the other one, the \"-g\" was removed.\n\nNow, maybe this is extra visible with PowerPC (32-bit) binaries, and it's \nnot as bad on x86, but it's still a bit distressing.\n\nThat \"-g\" doesn't buy users much of anything, and I doubt most developers \ncare that deeply most of the time either (and can easily add it when they \ndo care). It's left-over from long ago when it was much more useful.\n\nSo I'd suggest just removing it.\n\n\t\tLinus\n"},{"id":"14485","messageId":"43C558FB.3030102@op5.se","threadId":"3037","inReplyTo":"Pine.LNX.4.64.0601111021450.5073@g5.osdl.org","subject":"Re: git binary size...","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-11T19:14:03Z","receivedAt":"2006-01-11T19:14:03Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> Guess what the difference is here?\n> \n> \t[torvalds@g5 ~]$ du -sh bin/\n> \t14M     bin/\n> \t[torvalds@g5 ~]$ du -sh bin/\n> \t5.8M    bin/\n> \n> Give up?\n> \n> In one case, \"git\" was compiled with the default options in the git \n> Makefile. In the other one, the \"-g\" was removed.\n> \n> Now, maybe this is extra visible with PowerPC (32-bit) binaries, and it's \n> not as bad on x86, but it's still a bit distressing.\n> \n> That \"-g\" doesn't buy users much of anything, and I doubt most developers \n> care that deeply most of the time either (and can easily add it when they \n> do care). It's left-over from long ago when it was much more useful.\n> \n> So I'd suggest just removing it.\n> \n\nI'd suggest adding\n\nstrip:\n\tstrip $(PROGRAMS)\n\ninstall: strip\n\nto Makefile instead. That way people working on various git-tools won't \nhave to remember to override the CFLAGS when debugging new stuff.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"14490","messageId":"43C55EE4.9010103@zytor.com","threadId":"3037","inReplyTo":"43C558FB.3030102@op5.se","subject":"Re: git binary size...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-01-11T19:39:16Z","receivedAt":"2006-01-11T19:39:16Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Andreas Ericsson wrote:\n> \n> I'd suggest adding\n> \n> strip:\n>     strip $(PROGRAMS)\n> \n> install: strip\n> \n> to Makefile instead. That way people working on various git-tools won't \n> have to remember to override the CFLAGS when debugging new stuff.\n> \n\nI disagree with both of these.  Most users will not install via \"make \ninstall\", but rather via a package manager.  Package managers have long \nsince dealt with this problem; in the case of rpm, the debug information \nis stripped off into a separate package.  Having \"make install\" strip \nwould break that -- although defining $(STRIP) makes it a bit easier to \ndeal with (STRIP=: make install).\n\nHowever, if the concern is \"the average user\" I really think there is no \nreason do bother with this at all -- the average user should to \"yum \ninstall git\" or whatever is the equivalent for their distribution.  This \nain't 1990.\n\n\t-hpa\n"},{"id":"14489","messageId":"7vmzi2tuxx.fsf@assigned-by-dhcp.cox.net","threadId":"3037","inReplyTo":"43C558FB.3030102@op5.se","subject":"Re: git binary size...","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-11T19:40:10Z","receivedAt":"2006-01-11T19:40:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> I'd suggest adding\n>\n> strip:\n> \tstrip $(PROGRAMS)\n>\n> install: strip\n>\n> to Makefile instead.\n\nThat sounds sane.  Binary distribution _might_ hate us if we did\nso, though.  IIRC Debian wanted to build with -g and strip\nbefore installation themselves.  I do not know how this\ninteracts with rpmbuild.\n"},{"id":"14491","messageId":"Pine.LNX.4.64.0601111134560.5073@g5.osdl.org","threadId":"3037","inReplyTo":"43C558FB.3030102@op5.se","subject":"Re: git binary size...","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-11T19:44:32Z","receivedAt":"2006-01-11T19:44:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 11 Jan 2006, Andreas Ericsson wrote:\n> \n> strip:\n> \tstrip $(PROGRAMS)\n> \n> install: strip\n\nWell, that ends up shaving some more from the binaries, but at a much \nbigger cost than just removing \"-g\".\n\nWith stripped binaries, you can't really do _anything_. You get a \ncore-file, and you're screwed. \n\nWith non-stripped binaries you can at least see the function the SIGSEGV \nhappened in, and you usually even get a half-way decent backtrace etc.\n\n\t\tLinus\n"},{"id":"14493","messageId":"43C56278.6090105@op5.se","threadId":"3037","inReplyTo":"43C55EE4.9010103@zytor.com","subject":"Re: git binary size...","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-11T19:54:32Z","receivedAt":"2006-01-11T19:54:32Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"H. Peter Anvin wrote:\n> \n> I disagree with both of these.  Most users will not install via \"make \n> install\", but rather via a package manager.  Package managers have long \n> since dealt with this problem; in the case of rpm, the debug information \n> is stripped off into a separate package.  Having \"make install\" strip \n> would break that -- although defining $(STRIP) makes it a bit easier to \n> deal with (STRIP=: make install).\n> \n\nFair point. So how about a strip: target for just stripping the binaries \nin the directory? That way one can do \"make strip install\", but \neverything else will work as always. Better yet, make it\n\nstrip:\n\tstrip $(STRIP_OPTS) $(PROGRAMS)\n\nso Linus can set STRIP_OPTS=--strip-debug and everybody's happy.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"14494","messageId":"43C562F7.1090000@zytor.com","threadId":"3037","inReplyTo":"43C56278.6090105@op5.se","subject":"Re: git binary size...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-01-11T19:56:39Z","receivedAt":"2006-01-11T19:56:39Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Andreas Ericsson wrote:\n> H. Peter Anvin wrote:\n> \n>>\n>> I disagree with both of these.  Most users will not install via \"make \n>> install\", but rather via a package manager.  Package managers have \n>> long since dealt with this problem; in the case of rpm, the debug \n>> information is stripped off into a separate package.  Having \"make \n>> install\" strip would break that -- although defining $(STRIP) makes it \n>> a bit easier to deal with (STRIP=: make install).\n>>\n> \n> Fair point. So how about a strip: target for just stripping the binaries \n> in the directory? That way one can do \"make strip install\", but \n> everything else will work as always. Better yet, make it\n> \n> strip:\n>     strip $(STRIP_OPTS) $(PROGRAMS)\n> \n> so Linus can set STRIP_OPTS=--strip-debug and everybody's happy.\n> \n\nThe proper way to do this is:\n\nstrip:\n\t$(STRIP) $(STRIP_OPTS) $(PROGRAMS)\n\nFor \"strip\", this is frequently omitted, though.  Since \"strip\" is \narchitecture-dependent, though, this is necessary for cross-compilation.\n\n\t-hpa\n"},{"id":"14495","messageId":"43C5636D.505@zytor.com","threadId":"3037","inReplyTo":"Pine.LNX.4.64.0601111134560.5073@g5.osdl.org","subject":"Re: git binary size...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-01-11T19:58:37Z","receivedAt":"2006-01-11T19:58:37Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> Well, that ends up shaving some more from the binaries, but at a much \n> bigger cost than just removing \"-g\".\n> \n> With stripped binaries, you can't really do _anything_. You get a \n> core-file, and you're screwed. \n> \n> With non-stripped binaries you can at least see the function the SIGSEGV \n> happened in, and you usually even get a half-way decent backtrace etc.\n> \n\nThat's the really nice bit with the way e.g. RPM does it.  You don't \nhave to have the debug information around most of the time, but you can \ndo \"yum install git-debuginfo\" and suddenly you have it all -- and yet \nthe binary is unchanged, so your random core file actually matches the \ndebuginfo.\n\n\t-hpa\n"},{"id":"14496","messageId":"43C563D9.9000105@op5.se","threadId":"3037","inReplyTo":"43C562F7.1090000@zytor.com","subject":"Re: git binary size...","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-11T20:00:25Z","receivedAt":"2006-01-11T20:00:25Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"H. Peter Anvin wrote:\n> Andreas Ericsson wrote:\n>>\n>> strip:\n>>     strip $(STRIP_OPTS) $(PROGRAMS)\n>>\n>> so Linus can set STRIP_OPTS=--strip-debug and everybody's happy.\n>>\n> \n> The proper way to do this is:\n> \n> strip:\n>     $(STRIP) $(STRIP_OPTS) $(PROGRAMS)\n> \n> For \"strip\", this is frequently omitted, though.  Since \"strip\" is \n> architecture-dependent, though, this is necessary for cross-compilation.\n> \n\nDamn! I almost made it through the entire day without learning anything, \nand now you come along and spoil it all.\n\nOh well, new game tomorrow. ;)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"14547","messageId":"2cd57c900601120215pdb5da27l@mail.gmail.com","threadId":"3037","inReplyTo":"Pine.LNX.4.64.0601111134560.5073@g5.osdl.org","subject":"Re: git binary size...","fromName":"Coywolf Qi Hunt","fromEmail":"coywolf@gmail.com","sentAt":"2006-01-12T10:15:08Z","receivedAt":"2006-01-12T10:15:08Z","isPatch":false,"sender":{"key":"coywolf@gmail.com","avatar":null},"body":"2006/1/12, Linus Torvalds <torvalds@osdl.org>:\n>\n>\n> On Wed, 11 Jan 2006, Andreas Ericsson wrote:\n> >\n> > strip:\n> >       strip $(PROGRAMS)\n> >\n> > install: strip\n>\n> Well, that ends up shaving some more from the binaries, but at a much\n> bigger cost than just removing \"-g\".\n>\n> With stripped binaries, you can't really do _anything_. You get a\n> core-file, and you're screwed.\n\nAre you sure?\n\ngemini:~> file `which mke2fs`\n/sbin/mke2fs: ELF 32-bit LSB executable, Intel 80386, version 1\n(SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs),\nstripped\n\ngemini:~> file /lib/libext2fs.so.2\n/lib/libext2fs.so.2: symbolic link to `libext2fs.so.2.4'\n\ngemini:~> file /lib/libext2fs.so.2.4\n/lib/libext2fs.so.2.4: ELF 32-bit LSB shared object, Intel 80386,\nversion 1 (SYSV), stripped\n\n\nIn gdb:\n\nNo symbol table is loaded.  Use the \"file\" command.\n(gdb) bt\n#0  0xb7f16445 in ext2fs_mark_generic_bitmap () from /lib/libext2fs.so.2\n#1  0xb7f110ed in ext2fs_reserve_super_and_bgd () from /lib/libext2fs.so.2\n#2  0xb7f18353 in ext2fs_initialize () from /lib/libext2fs.so.2\n#3  0x0804b461 in ?? ()\n#4  0xbf84b9ad in ?? ()\n#5  0x00000000 in ?? ()\n\nSo with stripped binary, I still get the backtrace to locate the buggy\nfunction. IMO, Debian packages are build with -g.\n\nSo I suggest to let git go with `-g and striped' like all other packages do.\n\nAnd if we use gnu autoconf, which provides site config ability, we\ncould easily get (1) \"-g, striped\" for distros, (2) \"not striped\" for\nLinus and (3) \"-g3, -O0, no striped\" for some git developers.\n\nTo make git not tight to Linux, but cross platform, consider autoconf.\n\n>\n> With non-stripped binaries you can at least see the function the SIGSEGV\n> happened in, and you usually even get a half-way decent backtrace etc.\n>\n\nFalse, see above.\n\n>                 Linus\n\nIf I missed something in Debian, correct me.\n\n--\nCoywolf Qi Hunt\n"},{"id":"14549","messageId":"43C65E70.7090702@op5.se","threadId":"3037","inReplyTo":"2cd57c900601120215pdb5da27l@mail.gmail.com","subject":"Re: git binary size...","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-12T13:49:36Z","receivedAt":"2006-01-12T13:49:36Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Coywolf Qi Hunt wrote:\n> 2006/1/12, Linus Torvalds <torvalds@osdl.org>:\n> \n>>\n>>On Wed, 11 Jan 2006, Andreas Ericsson wrote:\n>>\n>>>strip:\n>>>      strip $(PROGRAMS)\n>>>\n>>>install: strip\n>>\n>>Well, that ends up shaving some more from the binaries, but at a much\n>>bigger cost than just removing \"-g\".\n>>\n>>With stripped binaries, you can't really do _anything_. You get a\n>>core-file, and you're screwed.\n> \n> \n> Are you sure?\n> \n> gemini:~> file `which mke2fs`\n> /sbin/mke2fs: ELF 32-bit LSB executable, Intel 80386, version 1\n> (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs),\n> stripped\n> \n> gemini:~> file /lib/libext2fs.so.2.4\n> /lib/libext2fs.so.2.4: ELF 32-bit LSB shared object, Intel 80386,\n> version 1 (SYSV), stripped\n> \n> (gdb) bt\n> #0  0xb7f16445 in ext2fs_mark_generic_bitmap () from /lib/libext2fs.so.2\n> #1  0xb7f110ed in ext2fs_reserve_super_and_bgd () from /lib/libext2fs.so.2\n> #2  0xb7f18353 in ext2fs_initialize () from /lib/libext2fs.so.2\n> #3  0x0804b461 in ?? ()\n> #4  0xbf84b9ad in ?? ()\n> #5  0x00000000 in ?? ()\n> \n> So with stripped binary, I still get the backtrace to locate the buggy\n> function. IMO, Debian packages are build with -g.\n> \n\nNo, you don't. The last three stack-frames resolve to no symbol. \nLibraries always contain symbol names. You wouldn't be able to use them \nif they didn't, because the dynamic linker uses those symbols to look up \nthe address of the function to call.\n\n> \n> To make git not tight to Linux, but cross platform, consider autoconf.\n> \n\ngit is already fairly portable without the autoconf hackery. It's easy \nenough to move some of the conditional stuff out of the Makefile without \nautoconf, but it would still require GNU Make, so there's no real point \nin doing so.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"14557","messageId":"43C693CF.3020800@zytor.com","threadId":"3037","inReplyTo":"43C65E70.7090702@op5.se","subject":"Re: git binary size...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-01-12T17:37:19Z","receivedAt":"2006-01-12T17:37:19Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Andreas Ericsson wrote:\n>>\n>> To make git not tight to Linux, but cross platform, consider autoconf.\n> \n> git is already fairly portable without the autoconf hackery. It's easy \n> enough to move some of the conditional stuff out of the Makefile without \n> autoconf, but it would still require GNU Make, so there's no real point \n> in doing so.\n> \n\nThe problem is that one really at some point end up reinventing a whole \nlot of autoconf.\n\nNow, a lot of autoconf ugliness comes from two sources:\n\n  - Not abstracting appropriately (#ifdef mess)\n  - Not using GNU make features\n\nOnce you require GNU make, you can have a top-level Makefile and have \nconfigure generating MCONFIG and config.h, and have conventional \ndependencies on those rules.  Pretty much the whole autoconstipation \nshould be confined to those two files.\n\nI might eventually try to make a clean patch for autoconf with git, and \nhopefully show that when done correctly, it's probably cleaner than the \nincreasing Makefile mess, plus it's automatic.\n\n\t-hpa\n"},{"id":"14559","messageId":"Pine.LNX.4.64.0601121011370.3535@g5.osdl.org","threadId":"3037","inReplyTo":"2cd57c900601120215pdb5da27l@mail.gmail.com","subject":"Re: git binary size...","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-12T18:12:38Z","receivedAt":"2006-01-12T18:12:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 12 Jan 2006, Coywolf Qi Hunt wrote:\n> >\n> > With stripped binaries, you can't really do _anything_. You get a\n> > core-file, and you're screwed.\n> \n> Are you sure?\n\nI'm sure.\n\n> In gdb:\n> \n> No symbol table is loaded.  Use the \"file\" command.\n> (gdb) bt\n> #0  0xb7f16445 in ext2fs_mark_generic_bitmap () from /lib/libext2fs.so.2\n\nNote where the debug info comes from. It comes from the _library_.\n\n> So with stripped binary, I still get the backtrace to locate the buggy\n> function.\n\nNo you don't. With the _non-stripped_ library you get the backtrace. \nThere's no backtrace at all for the binary itself.\n\n\t\tLinus\n"},{"id":"14560","messageId":"Pine.LNX.4.64.0601121013030.3535@g5.osdl.org","threadId":"3037","inReplyTo":"43C65E70.7090702@op5.se","subject":"Re: git binary size...","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-12T18:13:46Z","receivedAt":"2006-01-12T18:13:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 12 Jan 2006, Andreas Ericsson wrote:\n> \n> git is already fairly portable without the autoconf hackery. It's easy enough\n> to move some of the conditional stuff out of the Makefile without autoconf,\n> but it would still require GNU Make, so there's no real point in doing so.\n\nMore importantly, autoconf is a worse hack than _any_ of the config hacks \nwe do currently.\n\nRepeat after me: \"autoconf is crap\".\n\n\t\tLinus\n"},{"id":"14562","messageId":"Pine.LNX.4.63.0601121931060.24880@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3037","inReplyTo":"Pine.LNX.4.64.0601121013030.3535@g5.osdl.org","subject":"Re: git binary size...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-01-12T18:32:52Z","receivedAt":"2006-01-12T18:32:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 12 Jan 2006, Linus Torvalds wrote:\n\n> Repeat after me: \"autoconf is crap\".\n\nI tried to hold my breath for that mail, but you disappointed me. What \ntook you so long?\n\nCiao,\nDscho\n\nP.S.: Note that I am not at all detesting autoconf, but I know Linus does.\n"},{"id":"14563","messageId":"Pine.LNX.4.64.0601121033020.3535@g5.osdl.org","threadId":"3037","inReplyTo":"Pine.LNX.4.64.0601121013030.3535@g5.osdl.org","subject":"Re: git binary size...","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-12T18:46:48Z","receivedAt":"2006-01-12T18:46:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 12 Jan 2006, Linus Torvalds wrote:\n> \n> Repeat after me: \"autoconf is crap\".\n\n.. which is not to say that some _other_ autoconf-like thing might not be \ngood.\n\nThe problem I have with autoconf is that it adds absolutely horrendous \n#ifdef's etc all over the place, and the resulting makefile (and the \nconfig file itself) is just completely unreadable.\n\nThe reason autoconf sucks *ss is that it doesn't try to abstract out any \nof the differences between systems, it tries to basically \"fix up\" the \ndifferences.\n\nA real abstraction library would be a lot more preferable than autoconf. \nIt's kind of the way the git stuff works (ie using things like \n\"gitstrcasestr()\" and \"gitfakemmap()\"), but for many of the same reasons \nthat autoconf never did a good job, git itself doesn't do a good job (it \nuses \"#if\" hackery to then do things like \"#define mmap gitfakemmap\").\n\nBut I think the git kind of hackish #ifdef thing is better than the \n_insitutionalized_ horrible autoconf hackery.\n\nThere are real abstraction layers out there, but they usually do a lot \nmore than just simple autoconf things. They do full system abstraction, \nusually with support for graphical GUI stuff too: layers like Qt, \nwxVidgets, whatever..\n\nNow THAT is a good approach. \n\nSadly, for the git kind of area, I don't know of any sane toolkits like \nthat. The \"gnulib\" project could have been something, but it has been \ncorrupted by the autoconf disease, as far as I can tell.\n\nAnyway, it _should_ be possible to make a nice \"extended posix wrapper\" \nwith just a single\n\n\t#include \"libposix.h\"\n\nand having a per-system \"posix header\" that resolves all the stupid header \nfile differences, and a \"posix library\" that adds (or fixes) all the posix \nproblems for each platform.\n\nInstead, people still use autoconf ;(\n\n                 Linus\n"},{"id":"14568","messageId":"43C6AB0B.4030408@zytor.com","threadId":"3037","inReplyTo":"Pine.LNX.4.64.0601121033020.3535@g5.osdl.org","subject":"Re: git binary size...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2006-01-12T19:16:27Z","receivedAt":"2006-01-12T19:16:27Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n>>Repeat after me: \"autoconf is crap\".\n> \n> .. which is not to say that some _other_ autoconf-like thing might not be \n> good.\n> \n> The problem I have with autoconf is that it adds absolutely horrendous \n> #ifdef's etc all over the place, and the resulting makefile (and the \n> config file itself) is just completely unreadable.\n> \n> The reason autoconf sucks *ss is that it doesn't try to abstract out any \n> of the differences between systems, it tries to basically \"fix up\" the \n> differences.\n> \n> A real abstraction library would be a lot more preferable than autoconf. \n> It's kind of the way the git stuff works (ie using things like \n> \"gitstrcasestr()\" and \"gitfakemmap()\"), but for many of the same reasons \n> that autoconf never did a good job, git itself doesn't do a good job (it \n> uses \"#if\" hackery to then do things like \"#define mmap gitfakemmap\").\n> \n> But I think the git kind of hackish #ifdef thing is better than the \n> _insitutionalized_ horrible autoconf hackery.\n> \n\nYou can use autoconf in this way, though.  See my previous post on the \nmatter.\n\n\t-hpa\n"},{"id":"14956","messageId":"1137780009.17872.229.camel@cashmere.sps.mot.com","threadId":"3037","inReplyTo":"Pine.LNX.4.64.0601121013030.3535@g5.osdl.org","subject":"Re: git binary size...","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-01-20T18:00:09Z","receivedAt":"2006-01-20T18:00:09Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Thu, 2006-01-12 at 12:13, Linus Torvalds wrote:\n\n> More importantly, autoconf is a worse hack than _any_ of the config hacks \n> we do currently.\n> \n> Repeat after me: \"autoconf is crap\"\n\nAutoconf is also extraordinarily painful.\n\nIf there is actually enough configuration stuff needed,\nwould there be interest in a Kconfig-like mechanism?\nI could spare time that into existence, perhaps...?\n\njdl\n"}]}