You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by bu...@apache.org on 2001/06/27 17:46:48 UTC

[Bug 2356] New: - There are much better reasons that makefiles are evil

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2356

*** shadow/2356	Wed Jun 27 08:46:48 2001
--- shadow/2356.tmp.5254	Wed Jun 27 08:46:48 2001
***************
*** 0 ****
--- 1,48 ----
+ +============================================================================+
+ | There are much better reasons that makefiles are evil                      |
+ +----------------------------------------------------------------------------+
+ |        Bug #: 2356                        Product: Ant                     |
+ |       Status: NEW                         Version: unspecified             |
+ |   Resolution:                            Platform: All                     |
+ |     Severity: Minor                    OS/Version: All                     |
+ |     Priority: Other                     Component: Documentation           |
+ +----------------------------------------------------------------------------+
+ |  Assigned To: ant-dev@jakarta.apache.org                                   |
+ |  Reported By: dmh@tibco.com                                                |
+ |      CC list: Cc:                                                          |
+ +----------------------------------------------------------------------------+
+ |          URL: http://jakarta.apache.org/ant/index.html                     |
+ +============================================================================+
+ |                              DESCRIPTION                                   |
+ The infamous tab bug mentioned in the introduction has been fixed for years in
+ modern makes, and in any case, it's inessential.
+ 
+ Make's inherent evils include
+ 	It's almost impossible to tell what rule is going to apply
+ 	It encourages adding obscure pseudo-dependencies that exist for technical reasons
+ only
+ 	Macro expansion rules are hairy as hell and vary from flavor to flavor.  In
+ particular, it's almost impossible to tell what's going to be expanded when
+ 	Underlying much of this is a poor distinction between declarative and imperative
+ programming.  Specifying dependencies is meant to be delarative, but the actions
+ to be taken are inherently imperative.
+ 	There are the usual problems with evolving yet another ad-hoc turing complete
+ language over years -- see also the shells, awk, visual basic . . .
+ 	Actions are inherently platform dependent, while dependencies are less so,
+ leading to mammoth sets of rules in cross-platform environments.  The problem
+ here is that people tend to try to solve all cross-platform problems with make,
+ instead of abstracting build mechanisms and leaving dependencies to make.  Which
+ brings us to the most fundamental flaw . . .
+ 	Make doesn't even handle it's core task of tracking dependencies that well.  Or
+ at all.  You have to tell it explicitly that module A depends on module B, then
+ keep that information in sync with the code.  Some modern makes fix this, at
+ least on an ad hoc basis, but the sad, evil fact is that for years and years
+ make did nothing of the sort.  The best you could do was run some other tool to
+ generate a makefile, and hope make knew enough to take the changed makefile into
+ account (which it usually didn't).  This in turn led programmers to believe that
+ tracking dependencies was a hard problem, and perversely that since it was a
+ hard problem, you needed a "powerful tool" like make to help you.
+ 
+ If you condense any of the above, or your own opinions about make, into a couple
+ of polite but scathing paragraphs, I think the introduction will be the better
+ for it.
\ No newline at end of file

Re: [Bug 2356] New: - There are much better reasons that makefiles are evil

Posted by Roger Vaughn <ro...@yahoo.com>.
+1!

I have never in all my years using make had trouble with tabs.  But the stuff
mentioned here, on the other hand.....

--- bugzilla@apache.org wrote:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2356
> 
> *** shadow/2356	Wed Jun 27 08:46:48 2001
> --- shadow/2356.tmp.5254	Wed Jun 27 08:46:48 2001
> ***************
> *** 0 ****
> --- 1,48 ----
> +
>
+============================================================================+
> + | There are much better reasons that makefiles are evil                    
>  |
> +
>
+----------------------------------------------------------------------------+
> + |        Bug #: 2356                        Product: Ant                   
>  |
> + |       Status: NEW                         Version: unspecified           
>  |
> + |   Resolution:                            Platform: All                   
>  |
> + |     Severity: Minor                    OS/Version: All                   
>  |
> + |     Priority: Other                     Component: Documentation         
>  |
> +
>
+----------------------------------------------------------------------------+
> + |  Assigned To: ant-dev@jakarta.apache.org                                 
>  |
> + |  Reported By: dmh@tibco.com                                              
>  |
> + |      CC list: Cc:                                                        
>  |
> +
>
+----------------------------------------------------------------------------+
> + |          URL: http://jakarta.apache.org/ant/index.html                   
>  |
> +
>
+============================================================================+
> + |                              DESCRIPTION                                 
>  |
> + The infamous tab bug mentioned in the introduction has been fixed for years
> in
> + modern makes, and in any case, it's inessential.
> + 
> + Make's inherent evils include
> + 	It's almost impossible to tell what rule is going to apply
> + 	It encourages adding obscure pseudo-dependencies that exist for technical
> reasons
> + only
> + 	Macro expansion rules are hairy as hell and vary from flavor to flavor. 
> In
> + particular, it's almost impossible to tell what's going to be expanded when
> + 	Underlying much of this is a poor distinction between declarative and
> imperative
> + programming.  Specifying dependencies is meant to be delarative, but the
> actions
> + to be taken are inherently imperative.
> + 	There are the usual problems with evolving yet another ad-hoc turing
> complete
> + language over years -- see also the shells, awk, visual basic . . .
> + 	Actions are inherently platform dependent, while dependencies are less so,
> + leading to mammoth sets of rules in cross-platform environments.  The
> problem
> + here is that people tend to try to solve all cross-platform problems with
> make,
> + instead of abstracting build mechanisms and leaving dependencies to make. 
> Which
> + brings us to the most fundamental flaw . . .
> + 	Make doesn't even handle it's core task of tracking dependencies that
> well.  Or
> + at all.  You have to tell it explicitly that module A depends on module B,
> then
> + keep that information in sync with the code.  Some modern makes fix this,
> at
> + least on an ad hoc basis, but the sad, evil fact is that for years and
> years
> + make did nothing of the sort.  The best you could do was run some other
> tool to
> + generate a makefile, and hope make knew enough to take the changed makefile
> into
> + account (which it usually didn't).  This in turn led programmers to believe
> that
> + tracking dependencies was a hard problem, and perversely that since it was
> a
> + hard problem, you needed a "powerful tool" like make to help you.
> + 
> + If you condense any of the above, or your own opinions about make, into a
> couple
> + of polite but scathing paragraphs, I think the introduction will be the
> better
> + for it.
> \ No newline at end of file


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/