{"thread":{"id":"8078","subject":"Build Failure: GIT-GUI-VARS","startedAt":"2007-05-11T01:51:14Z","lastAt":"2007-05-12T00:09:46Z","messageCount":5,"participants":["Brian Gernhardt","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41804","messageId":"FF405582-7769-4A08-87A0-680F8CD165DC@silverinsanity.com","threadId":"8078","inReplyTo":null,"subject":"Build Failure: GIT-GUI-VARS","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-05-11T01:51:14Z","receivedAt":"2007-05-11T01:51:14Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\"make all\" fails with \"NO_TCLTK=y\" because gitk-wish depends on GIT- \nGUI-VARS which is defined inside the ifndef block.\n\nAFAICT, either gitk-wish should be moved inside a ifndef block or an  \nelse should be added with a phony GIT-GUI-VARS.  I don't know which  \nis preferred.\n\nActually, I can't tell why make is trying to build it in the first  \nplace.  :-/  gitk-wish is added to OTHER_PROGRAMS inside a NO_TCLTK  \nblock. (Debian oldstable, GNU Make 3.80, git repo v1.5.2-rc3)\n\nAnd, while I'm poking through here, there's a line labeled \"Backward  \ncompatibility -- to be removed after 1.0\".  Git IDs itself as  \n1.5.2.rc3.  Isn't that after 1.0?  :-)\n\n~~ Brian\n"},{"id":"41805","messageId":"7v8xbwgkia.fsf@assigned-by-dhcp.cox.net","threadId":"8078","inReplyTo":"FF405582-7769-4A08-87A0-680F8CD165DC@silverinsanity.com","subject":"Re: Build Failure: GIT-GUI-VARS","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-11T02:30:05Z","receivedAt":"2007-05-11T02:30:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gernhardt <benji@silverinsanity.com> writes:\n\n> Actually, I can't tell why make is trying to build it in the first\n> place.  :-/  gitk-wish is added to OTHER_PROGRAMS inside a NO_TCLTK\n> block.\n\nI do not either, and obviously does not reproduce for me.  Time\nfor you to try \"make -d\" perhaps?\n"},{"id":"41835","messageId":"5F2FFEA3-0D62-432D-98F7-8BE896937067@silverinsanity.com","threadId":"8078","inReplyTo":"7v8xbwgkia.fsf@assigned-by-dhcp.cox.net","subject":"Re: Build Failure: GIT-GUI-VARS","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-05-11T14:08:40Z","receivedAt":"2007-05-11T14:08:40Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn May 10, 2007, at 10:30 PM, Junio C Hamano wrote:\n\n> I do not either, and obviously does not reproduce for me.  Time\n> for you to try \"make -d\" perhaps?\n\nSorry for the semi-coherent message.  It started out as \"we should  \nfix this\" and I ended up going \"why is it broken\", all a little too  \nlate at night.  I'm also not used to debugging Makefiles.\n\nAnd I figured it out (make -p actually was more useful than -d):   \nIt's another issue with doing things before including config.mak.  My  \nconfig.mak includes the \"NO_TCLTK=y\" line, which takes effect at  \nMakefile:485.  But gitk-wish is getting included in OTHER_PROGRAMS at  \nMakefile:272.  So gitk-wish gets included because NO_TCLTK isn't  \ndefined at that point, but all the other rules involving gitk don't  \nget executed because they're after the NO_TCLTK definition.\n\nI think we need to be including the config.mak much earlier in the  \nMakefile as this is not the first time issues like this have come up  \nfor me.  And they tend to be issues that only come up with specific  \nconfigurations and are therefore harder to track down.  Things I can  \nsee being an issue for people who put their options in config.mak:\n\n149: ifeq ($(prefix),/usr)\n224: ifdef WITH_P4IMPORT\n271: ifndef NO_TCLTK   # My issue today\n279-285: ifndef {SHELL,PERL,PYTHON}_PATH\n\n~~ Brian\n"},{"id":"41840","messageId":"7v3b23cmm5.fsf@assigned-by-dhcp.cox.net","threadId":"8078","inReplyTo":"5F2FFEA3-0D62-432D-98F7-8BE896937067@silverinsanity.com","subject":"Re: Build Failure: GIT-GUI-VARS","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-11T17:10:26Z","receivedAt":"2007-05-11T17:10:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gernhardt <benji@silverinsanity.com> writes:\n\n> On May 10, 2007, at 10:30 PM, Junio C Hamano wrote:\n>\n>> I do not either, and obviously does not reproduce for me.  Time\n>> for you to try \"make -d\" perhaps?\n>\n> Sorry for the semi-coherent message.  It started out as \"we should fix\n> this\" and I ended up going \"why is it broken\", all a little too  late\n> at night.  I'm also not used to debugging Makefiles.\n>\n> And I figured it out (make -p actually was more useful than -d):  It's\n> another issue with doing things before including config.mak.\n\nAhh, config.mak.\n\nI have not been very sympathetic to config.mak from the\nbeginning, although people seem to want it.  As I try to arrange\nvariable overrides to be passed from the command line anyway,\nI've not used config.mak myself.\n\n> I think we need to be including the config.mak much earlier in the\n> Makefile as this is not the first time issues like this have come up\n> for me.\n\nHowever, it needs to be able to override NO_*, NEEDS_* and\nfriends which means it should come after platform specific\ndefaults.  But one platform wants to change the default\nbehaviour depend on the settings of NO_*, possibly set in\nconfig.mak.\n\nIt is a mess.  Moving it around would fix one person's problem\nwhile breaking others.  I think the best course of action is\n\n (1) first for somebody more fluent in speaking Makefile than me\n     to volunteer to tackle this problem, and ask help from the\n     list;\n\n (2) have people on various \"non-stock\" configurations sign-up\n     as testers; this does not have to cover the systems listed\n     in the ifeq ($(uname_S),XXX) part of the current Makefile;\n     what is of interest is to see what kind of variables are\n     overridden on the real-world systems via config.mak;\n\n (3) The volunteer cooks up an improved Makefile, using\n     config.mak \"non-stock\" testers have.\n\nThis would be something that \"volunteer\" would be deciding, but\nI have a feeling that we can have two config.mak include in the\nmakefile, one early and one late.  But I suspect that picking\nthe right two places would have the same \"moving would fix one\nwhile breaking another\" issue.\n"},{"id":"41872","messageId":"20070512000946.GB19282@coredump.intra.peff.net","threadId":"8078","inReplyTo":"7v3b23cmm5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Build Failure: GIT-GUI-VARS","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-12T00:09:46Z","receivedAt":"2007-05-12T00:09:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 11, 2007 at 10:10:26AM -0700, Junio C Hamano wrote:\n\n> I have not been very sympathetic to config.mak from the\n> beginning, although people seem to want it.  As I try to arrange\n> variable overrides to be passed from the command line anyway,\n> I've not used config.mak myself.\n>\n> [...]\n>\n>  (3) The volunteer cooks up an improved Makefile, using\n>      config.mak \"non-stock\" testers have.\n\nI wonder if we would be better served by moving these sorts of\nbuild-time configuration decisions into the actual make dependency\ntree.  E.g., something like:\n\n  openssl.lib: mklib-openssl.sh conf-openssl\n    sh mklib-openssl.sh <conf-ssl >openssl.lib\n\n  program: main.o openssl.lib:\n    cc -o \"$@\" main.o `cat openssl.lib`\n\nwhere conf-openssl specifies the user's preference (either actual\nlibrary paths, \"auto\" for autodetection, or \"none\" not to use it at\nall), and mklib-openssl is a script that converts that into the command\nline options for the link.\n\nYou can of course do the same with creating a .h file to choose an\nimplementation (you just make a file that #define's the correct thing).\n\nThe nice thing about this approach is that:\n  1. You move configuration cruft out of the Makefile, making it much\n     easier to read. Instead, you have a series of very small and\n     obvious shell scripts.\n  2. The dependency chain is actually correct. If I edit conf-openssl,\n     then that should trigger a re-link for everything which compiles\n     against it.\n\nYou can also use this for portability fixes:\n\n  program: main.o strcasestr.o\n    cc -o \"$@\" main.o strcasestr.o\n\n  strcasestr.o choose try_strcasestr.c compat/strcasestr.c\n    sh choose try_strcasestr.c compat/strcasestr.c\n\nwhere choose is a script that compiles and runs some test program and\nuses the result to choose a source file to become strcasestr.c. Thus you\n_always_ link against strcasestr.o, it's just that sometimes there's an\nimplementation of strcasestr in it (if required by the platform) and\nsometimes it's empty (or an alternate implementation, etc).\n\nI have used this technique many times, and would be happy to be involved\nin changing the Makefile. However, it's going to be quite a large\nchange, and I recognize that this style is not familiar to most people,\nso obviously that should be taken into account.\n\n-Peff\n"}]}