Verbosity of the Makefile
This is pure cosmetics, but I found that the latest CVS versions of the Parser Makefile have become somewhat verbose. Is this really needed ? Also, I'd suggest adding a line .SILENT: to the top-level Makefile to make possible errors more visible (without the parser messages the Makefile messages for a clean run fit on a 25-line display). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Like what? What has been added?
I tried this, and it's to quiet -- you don't know what's going on at all any more. If you like this, just say "make -s". --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Guido van Rossum wrote:
I was referring to this output: making Makefile in subdirectory Modules Compiling (meta-) parse tree into NFA grammar Making DFA for 'single_input' ... Making DFA for 'file_input' ... Making DFA for 'eval_input' ... Making DFA for 'funcdef' ... Making DFA for 'parameters' ... Making DFA for 'varargslist' ... Making DFA for 'fpdef' ... Making DFA for 'fplist' ... Making DFA for 'stmt' ... Making DFA for 'simple_stmt' ... Making DFA for 'small_stmt' ... ... Making DFA for 'list_for' ... Making DFA for 'list_if' ... Adding FIRST sets ... Writing graminit.c ... Writing graminit.h ...
I know, that's what I have in my .aliases file... just thought that it might be better to only see problems rather than hundreds of OS commands. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Fri, Sep 01, 2000 at 08:36:37PM +0200, M.-A. Lemburg wrote:
How about just removing the Grammar rule in releases ? It's only useful for people fiddling with the Grammar, and we had a lot of those fiddles in the last few weeks. It's not really necessary to rebuild the grammar after each reconfigure (which is basically what the Grammar does.) Repetitively-y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
This should only happen after "make clean" right? If it annoys you, we could add >/dev/null to the pgen rule.
-1. It's too silent to be a good default. Someone who first unpacks and builds Python and is used to building other projects would wonder why make is "hanging" without printing anything. I've never seen a Makefile that had this right out of the box. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
For what it's worth, lots of verbosity in the Makefile makes me happy. But I'm a verbose sort of guy... (Part of the reason for sending this is to test if my mail is going through. Looks like there's currently no route from fnal.gov to python.org, I wonder where the problem is?)
I'm going to pipe up again about non-recursive makefiles being a good thing. This is another reason. Neil
On 01 September 2000, Neil Schemenauer said:
I'm going to pipe up again about non-recursive makefiles being a good thing. This is another reason.
+1 in principle. I suspect un-recursifying Python's build system would be a pretty conclusive demonstration of whether the "Recursive Makefiles Considered Harmful" thesis hold water. Want to try to hack something together one of these days? (Probably not for 2.0, though.) Greg
Greg Ward:
To me this seems like a big waste of time. I see nothing broken with the current setup. The verbosity is taken care of by "make -s", for individuals who don't want Make saying anything. Another useful option is "make --no-print-directory"; this removes Make's noisiness about changing directories. If the pgen output really bothers you, then let's direct it to /dev/null. None of these issues seem to require getting rid of the Makefile recursion. If it ain't broken, don't fix it! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Guido van Rossum writes:
To me this seems like a big waste of time. I see nothing broken with the current setup.
I've built Python on every kind of system we have at FNAL, which means Linux, several versions of Solaris, IRIX, DEC^H^H^HCompaq OSF/1, even (shudder) WinNT, and the only complaint I've ever had with the build system is that it doesn't do a "make depend" automatically. (I don't care too much about the dependencies on system headers, but the Makefiles should at least know about the dependencies on Python's own .h files, so when you change something like opcode.h or node.h it is properly handled. Fred got bitten by this when he tried to apply the EXTENDED_ARG patch.) Personally, I think that the "recurive Mke considered harmful" paper is a bunch of hot air. Many highly successful projects - the Linux kernel, glibc, etc - use recursive Make.
If it ain't broken, don't fix it!
Amen!
Like what? What has been added?
I tried this, and it's to quiet -- you don't know what's going on at all any more. If you like this, just say "make -s". --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Guido van Rossum wrote:
I was referring to this output: making Makefile in subdirectory Modules Compiling (meta-) parse tree into NFA grammar Making DFA for 'single_input' ... Making DFA for 'file_input' ... Making DFA for 'eval_input' ... Making DFA for 'funcdef' ... Making DFA for 'parameters' ... Making DFA for 'varargslist' ... Making DFA for 'fpdef' ... Making DFA for 'fplist' ... Making DFA for 'stmt' ... Making DFA for 'simple_stmt' ... Making DFA for 'small_stmt' ... ... Making DFA for 'list_for' ... Making DFA for 'list_if' ... Adding FIRST sets ... Writing graminit.c ... Writing graminit.h ...
I know, that's what I have in my .aliases file... just thought that it might be better to only see problems rather than hundreds of OS commands. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Fri, Sep 01, 2000 at 08:36:37PM +0200, M.-A. Lemburg wrote:
How about just removing the Grammar rule in releases ? It's only useful for people fiddling with the Grammar, and we had a lot of those fiddles in the last few weeks. It's not really necessary to rebuild the grammar after each reconfigure (which is basically what the Grammar does.) Repetitively-y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
This should only happen after "make clean" right? If it annoys you, we could add >/dev/null to the pgen rule.
-1. It's too silent to be a good default. Someone who first unpacks and builds Python and is used to building other projects would wonder why make is "hanging" without printing anything. I've never seen a Makefile that had this right out of the box. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
For what it's worth, lots of verbosity in the Makefile makes me happy. But I'm a verbose sort of guy... (Part of the reason for sending this is to test if my mail is going through. Looks like there's currently no route from fnal.gov to python.org, I wonder where the problem is?)
I'm going to pipe up again about non-recursive makefiles being a good thing. This is another reason. Neil
On 01 September 2000, Neil Schemenauer said:
I'm going to pipe up again about non-recursive makefiles being a good thing. This is another reason.
+1 in principle. I suspect un-recursifying Python's build system would be a pretty conclusive demonstration of whether the "Recursive Makefiles Considered Harmful" thesis hold water. Want to try to hack something together one of these days? (Probably not for 2.0, though.) Greg
Greg Ward:
To me this seems like a big waste of time. I see nothing broken with the current setup. The verbosity is taken care of by "make -s", for individuals who don't want Make saying anything. Another useful option is "make --no-print-directory"; this removes Make's noisiness about changing directories. If the pgen output really bothers you, then let's direct it to /dev/null. None of these issues seem to require getting rid of the Makefile recursion. If it ain't broken, don't fix it! --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Guido van Rossum writes:
To me this seems like a big waste of time. I see nothing broken with the current setup.
I've built Python on every kind of system we have at FNAL, which means Linux, several versions of Solaris, IRIX, DEC^H^H^HCompaq OSF/1, even (shudder) WinNT, and the only complaint I've ever had with the build system is that it doesn't do a "make depend" automatically. (I don't care too much about the dependencies on system headers, but the Makefiles should at least know about the dependencies on Python's own .h files, so when you change something like opcode.h or node.h it is properly handled. Fred got bitten by this when he tried to apply the EXTENDED_ARG patch.) Personally, I think that the "recurive Mke considered harmful" paper is a bunch of hot air. Many highly successful projects - the Linux kernel, glibc, etc - use recursive Make.
If it ain't broken, don't fix it!
Amen!
participants (6)
-
Charles G Waldman -
Greg Ward -
Guido van Rossum -
M.-A. Lemburg -
Neil Schemenauer -
Thomas Wouters