Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Date: 27 Jun 2001 15:46:48 -0000
Message-ID: <20010627154648.5257.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: ant-dev@jakarta.apache.org
Cc: 
Subject: [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