{"thread":{"id":"1434","subject":"[PATCH] Making CFLAGS compilant with GNU Coding Standards","startedAt":"2005-08-06T05:36:15Z","lastAt":"2005-08-11T04:01:33Z","messageCount":12,"participants":["Pavel Roskin","Junio C Hamano","Ryan Anderson","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"6871","messageId":"1123306575.7588.17.camel@dv.roinet.com","threadId":"1434","inReplyTo":null,"subject":"[PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-08-06T05:36:15Z","receivedAt":"2005-08-06T05:36:15Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nQuoting GNU Coding Standards (\"info standards\"):\n\n\"If there are C compiler options that _must_ be used for proper\ncompilation of certain files, do not include them in `CFLAGS'.  Users\nexpect to be able to specify `CFLAGS' freely themselves.\"\n\nThis patch renames COPTS to CFLAGS, because it's COPTS that was user\noverridable.  Also, -Wall is moved there because it's optional.  What\nwas CFLAGS is now ALL_CFLAGS, which users should not override.\n\nDefines are added to DEFINES.  Since ALL_CFLAGS is recursively expanded,\nit uses the final value of DEFINES.\n\nImplicit rules are made explicit since the implicit rules use CFLAGS\nrather than ALL_CFLAGS.  I believe that serious projects should not rely\non implicit rules anyway.  Percent rules are used because they are used\nalready and because they don't need the .SUFFIXES target.\n\nSigned-off-by: Pavel Roskin <proski@gnu.org>\n\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -34,8 +34,8 @@\n \n GIT_VERSION=0.99.3\n \n-COPTS?=-g -O2\n-CFLAGS+=$(COPTS) -Wall $(DEFINES)\n+CFLAGS ?= -g -O2 -Wall\n+ALL_CFLAGS = $(CFLAGS) $(DEFINES)\n \n prefix=$(HOME)\n bindir=$(prefix)/bin\n@@ -125,7 +125,7 @@ ifndef NO_OPENSSL\n \tLIB_OBJS += epoch.o\n \tOPENSSL_LIBSSL=-lssl\n else\n-\tCFLAGS += '-DNO_OPENSSL'\n+\tDEFINES += '-DNO_OPENSSL'\n \tMOZILLA_SHA1=1\n \tOPENSSL_LIBSSL=\n endif\n@@ -146,8 +146,8 @@ endif\n endif\n endif\n \n-CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'\n-CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT=\"$(etcgitdir)/templates\"'\n+DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'\n+DEFINES += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT=\"$(etcgitdir)/templates\"'\n \n \n \n@@ -156,9 +156,15 @@ CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRO\n all: $(PROG)\n \n \n+%.o: %.c\n+\t$(CC) -c $(ALL_CFLAGS) $<\n+\n+%.o: %.S\n+\t$(CC) -c $(ALL_CFLAGS) $<\n+\n .PRECIOUS: %.o\n git-%: %.o $(LIB_FILE)\n-\t$(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)\n+\t$(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)\n \n git-http-pull: pull.o\n git-local-pull: pull.o\n@@ -185,13 +191,13 @@ test: all\n \t$(MAKE) -C t/ all\n \n test-date: test-date.c date.o\n-\t$(CC) $(CFLAGS) -o $@ test-date.c date.o\n+\t$(CC) $(ALL_CFLAGS) -o $@ test-date.c date.o\n \n test-delta: test-delta.c diff-delta.o patch-delta.o\n-\t$(CC) $(CFLAGS) -o $@ $^\n+\t$(CC) $(ALL_CFLAGS) -o $@ $^\n \n check:\n-\tfor i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done\n+\tfor i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done\n \n \n \n\n-- \nRegards,\nPavel Roskin\n"},{"id":"6950","messageId":"7vy87c2lrv.fsf@assigned-by-dhcp.cox.net","threadId":"1434","inReplyTo":"1123306575.7588.17.camel@dv.roinet.com","subject":"Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-08T20:53:24Z","receivedAt":"2005-08-08T20:53:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin <proski@gnu.org> writes:\n\n> Quoting GNU Coding Standards (\"info standards\"):\n>\n> \"If there are C compiler options that _must_ be used for proper\n> compilation of certain files, do not include them in `CFLAGS'.  Users\n> expect to be able to specify `CFLAGS' freely themselves.\"\n\nQuoting Documentation/CodingStyle:\n\n    This is a short document describing the preferred coding style for the\n    linux kernel.  Coding style is very personal, and I won't _force_ my\n    views on anybody, but this is what goes for anything that I have to be\n    able to maintain, and I'd prefer it for most other things too.  Please\n    at least consider the points made here.\n\n    First off, I'd suggest printing out a copy of the GNU coding\n    standards, and NOT read it.  Burn them, it's a great symbolic\n    gesture.\n\nThis was only a tongue-in-cheek comment ;-).\n\nSeriously, I do not intend to discarded this patch, but I am\ncurrently not taking Makefile patches unless they fix real\nbreakage.\n\nI do want to revisit Makefile issues after 0.99.4, along with\nthe changes Pasky sent several days ago.  Please remind me about\nthem after Wednesday.\n"},{"id":"6964","messageId":"20050808231036.GA22778@mythryan2.michonline.com","threadId":"1434","inReplyTo":"7vy87c2lrv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-08-08T23:10:36Z","receivedAt":"2005-08-08T23:10:36Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Mon, Aug 08, 2005 at 01:53:24PM -0700, Junio C Hamano wrote:\n> I do want to revisit Makefile issues after 0.99.4, along with\n> the changes Pasky sent several days ago.  Please remind me about\n> them after Wednesday.\n\nWe should discuss (or just do) a reorganization of how we lay out the\nsource tree.\n\nThere's probably a few too many files in the top directory, from all the\nporcelain we've built on the plumbing. (heh)\n\nI haven't really given a lot of thought to this yet, but I was thinking\nof something along these lines:\n\nRename tools/ to mail-tools/, push git-send-email-script into that.\nCreate a \"porcelain\" directory for things like git-bisect-script\nCreate a \"core\" directory for things like \"git-commit-script\"\nCreate a \"src\" (?) directory for *.[ch]\nMaybe move documentation into the same directory as the scripts they\nbelong to.\n\nThen we can argue over where the leftover things fall.\n\nIf we can get the directory structure to make sense and start putting\nnew things into the right spots, the exact location of where *current*\nthings end up is probably not so important.\n\nI consider this post 1.0 material, personally.\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"6966","messageId":"Pine.LNX.4.63.0508090140100.3695@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1434","inReplyTo":"20050808231036.GA22778@mythryan2.michonline.com","subject":"Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-08T23:42:11Z","receivedAt":"2005-08-08T23:42:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 8 Aug 2005, Ryan Anderson wrote:\n\n> [...]\n>\n> We should discuss (or just do) a reorganization of how we lay out the\n> source tree.\n>\n> [...]\n\nI, for one, like the layout. There are not yet enough files to merit a \nhierarchy, and what's more: I can add the source-directory to my PATH and \nbe done by compiling every time I pull.\n\nBut you're right in any case, it is post 1.0 discussion material.\n\nCiao,\nDscho\n"},{"id":"6975","messageId":"7vpssnyge0.fsf@assigned-by-dhcp.cox.net","threadId":"1434","inReplyTo":"Pine.LNX.4.63.0508090140100.3695@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-09T02:48:39Z","receivedAt":"2005-08-09T02:48:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I, for one, like the layout. There are not yet enough files to merit a \n> hierarchy, and what's more: I can add the source-directory to my PATH and \n> be done by compiling every time I pull.\n>\n> But you're right in any case, it is post 1.0 discussion material.\n\nFor quite some time, I've been wanting to install some of the\nstuff under /usr/lib{,exec}/git-core/, but that is a post 1.0\nmaterial.  I do not care much about the way we organize the\nsources at this stage.\n\nJohannes, could you sanity check the commit change I have in the\nproposed updates branch when things percolate through kernel.org\nmirror network?  I ended up pushing it out before I found you\nalready did a patch.\n"},{"id":"6983","messageId":"Pine.LNX.4.63.0508091212170.6752@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1434","inReplyTo":"7vpssnyge0.fsf@assigned-by-dhcp.cox.net","subject":"Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-09T10:17:54Z","receivedAt":"2005-08-09T10:17:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 8 Aug 2005, Junio C Hamano wrote:\n\n> Johannes, could you sanity check the commit change I have in the\n> proposed updates branch when things percolate through kernel.org\n> mirror network?  I ended up pushing it out before I found you\n> already did a patch.\n\nI just checked. Three nitpicks:\n\n- I don't like the GNU way to abbreviate long options too much. Either you \n  know exactly what you're doing, and you use the short form, or you want \n  to make sure that you have spelt it correctly. Besides, it makes the \n  code less readable and more prone to errors.\n\n- Multiple -m options was actually a feature of my version of the patch.\n\n- The \"case .. in x) .. ;; esac;\" construct is sometimes more confusing \n  than a simple \"if\", or even a \"[ .. = x ] && ..\".\n\nAs I said, just nitpicks. I didn't test, though. I'll do that when the \ncommit is in the master branch :-) Maybe I'll even write my first git test \ncase, who knows?\n\nCiao,\nDscho\n"},{"id":"6988","messageId":"7vu0hzw9sx.fsf@assigned-by-dhcp.cox.net","threadId":"1434","inReplyTo":"Pine.LNX.4.63.0508091212170.6752@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-09T12:53:50Z","receivedAt":"2005-08-09T12:53:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I just checked. Three nitpicks:\n>\n> - I don't like the GNU way to abbreviate long options too much...\n\nTrue.  My bad old habit.\n\n> - Multiple -m options was actually a feature of my version of the patch.\n\nAh, OK.\n\n> - The \"case .. in x) .. ;; esac;\" construct is sometimes more confusing \n>   than a simple \"if\", or even a \"[ .. = x ] && ..\".\n\nYes sometimes.\n"},{"id":"6989","messageId":"7vk6ivw9oo.fsf@assigned-by-dhcp.cox.net","threadId":"1434","inReplyTo":"20050808231036.GA22778@mythryan2.michonline.com","subject":"Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-09T12:56:23Z","receivedAt":"2005-08-09T12:56:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson <ryan@michonline.com> writes:\n\n> I haven't really given a lot of thought to this yet, but I was thinking\n> of something along these lines:\n>\n> Rename tools/ to mail-tools/, push git-send-email-script into that.\n> Create a \"porcelain\" directory for things like git-bisect-script\n> Create a \"core\" directory for things like \"git-commit-script\"\n> Create a \"src\" (?) directory for *.[ch]\n> Maybe move documentation into the same directory as the scripts they\n> belong to.\n\nA good place to start may be to reorganize the categorized list\nof commands in Documentation/git.txt.\n"},{"id":"6991","messageId":"Pine.LNX.4.63.0508091618320.7995@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1434","inReplyTo":"7vu0hzw9sx.fsf@assigned-by-dhcp.cox.net","subject":"Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-09T14:19:13Z","receivedAt":"2005-08-09T14:19:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 Aug 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > - I don't like the GNU way to abbreviate long options too much...\n> \n> True.  My bad old habit.\n\nAn elegant method to do that:\n\ncase --some-long-option in \"$1\"*) ..; esac\n\nCiao,\nDscho\n"},{"id":"6996","messageId":"7vd5onvydk.fsf@assigned-by-dhcp.cox.net","threadId":"1434","inReplyTo":"Pine.LNX.4.63.0508091618320.7995@wgmdd8.biozentrum.uni-wuerzburg.de","subject":"Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-09T17:00:39Z","receivedAt":"2005-08-09T17:00:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> True.  My bad old habit.\n>\n> An elegant method to do that:\n>\n> case --some-long-option in \"$1\"*) ..; esac\n\nYou are almost correct, but you need to realize that I generate\nthat long \"case -s|--s|--so|--som|...\" chain using a script that\ntakes all potential option names as its arguments, and makes\ncase arms that contain only unambiguous ones, so that I can\nhandle --some-long-option and --some-other-long-option sensibly.\n\nAlso you forgot to grok --some-option-with-args=* in your\nversion ;-).\n"},{"id":"7021","messageId":"7vd5oms5tj.fsf@assigned-by-dhcp.cox.net","threadId":"1434","inReplyTo":"7vu0hzw9sx.fsf@assigned-by-dhcp.cox.net","subject":"Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-10T05:45:44Z","receivedAt":"2005-08-10T05:45:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n>> - Multiple -m options was actually a feature of my version of the patch.\n>\n> Ah, OK.\n\nI said \"OK\" and thought about it again.  While thinking about\nwhat is the right inter-message-piece separator for multiple -m\nparameters (you use \"\\n\"), I got a headache.  I decided to keep\nwhat is already there after all ;-).\n\nI'll push things out tonight and expect to tag things tomorrow\nlate afternoon to declare 0.99.4\n"},{"id":"7050","messageId":"1123732893.18644.41.camel@dv","threadId":"1434","inReplyTo":"7vy87c2lrv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-08-11T04:01:33Z","receivedAt":"2005-08-11T04:01:33Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hi, Junio!\n\nOn Mon, 2005-08-08 at 13:53 -0700, Junio C Hamano wrote:\n> Seriously, I do not intend to discarded this patch, but I am\n> currently not taking Makefile patches unless they fix real\n> breakage.\n\nTry \"make CFLAGS=-O3\"\n\n> I do want to revisit Makefile issues after 0.99.4, along with\n> the changes Pasky sent several days ago.  Please remind me about\n> them after Wednesday.\n\nIt's \"after Wednesday\" and 0.99.4 is out (many thanks).\n\n-- \nRegards,\nPavel Roskin\n"}]}