Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> Darren New <dne### [at] sanrrcom> wrote:
>>>> Actually, the primary problem with makefiles is actually C's bizarre 
>>>> #include rules, where source files depend on other source files which aren't 
>>>> evident from looking at the source files.
>>>   Never miss a chance to belittle C-like languages.
> 
>> How come C is the only language from the 1970s that you get upset at my 
>> pointing out technology-induced limitations?
> 
>   It's not that you belittle it. It's the frequency with which you do it,
> and the situations where you do it.

It's the only language from that time that's still in popular use. :-)

Besides, I thought you don't like C either.

>   Just count your posts belittling eg. COBOL and the onces belittling C or
> C++. I bet the difference is something like two orders of magnitude.

Sure. Now count the number of posts talking about COBOL vs talking about 
C++. Heck, we even have a whole newsgroup about C++. ;-)

>   Also, in this particular case, what was the point? It did not add anything
> relevant or interesting to the thread, nor did it answer the original
> question.

Sorry you didn't understand the point.  The point is that most of the other 
languages out there don't have the sort of nested include behavior that C 
has, and hence don't need makefiles that are anything more than simply the 
list of source files that compile into each object library or executable.

In C# for example, the equivalent of the makefile says "here's the source 
files to compile. Here's the name of the DLL to create. Here's the global 
DLLs to link against (specified by content, not path). Here's the list of 
makefiles for other possibly-uncompiled sources I depend on. Here's the 
#define symbols to define and other compiler options." There's no list of 
chunks of source code unrelated to the object code that this compilation 
depends on. There's no big long list of which libraries link against other 
libraries, or what order to search them in, or what order to compile things 
in, or which source files use which types, or a 5000-character long compile 
line specifying the source code locations of every declaration used anywhere 
in your program.  (And yes, I've had individual makefile compilation lines 
that spanned several pages.)

And it deals with stuff that isn't compiled yet (since the reference to some 
other object file that might need compilation actually points that the 
equivalent of the *makefile* and not the equivalent of the DLL), and it 
deals with object code that has changed but still has an older date (like 
reverting a subversion repository), and it deals with changes in compilation 
(like changing #define values between compilations), and it deals with 
standard object files being updated or moved, all of which need external 
tools for make.

Basically, the *interesting* problems, Make can't handle, which is why you 
see qmake cmake ant autoconf and so on. The problem of specifying the list 
of dependencies is trivial in compiled languages that don't have nested 
source files: the object file depends on the source, the library depends on 
all the object files.

The problem that Make solves is letting you manually specify which nested 
#include files that might change but aren't easily found affect the 
compilation of this program. Every other change that affects the compilation 
of this program, Make can't handle. Hence, Make really doesn't make sense 
for languages other than those whose dependencies aren't trivially deducible 
by looking at the code.

 > (this is, afaik, what gcc does when you run it with the -M option)

BTW, why not just build this into the compiler? Then you wouldn't need 
makefiles. You'd have a three-line shell script: "compile everything that 
needs compiling. If the library is older than any of the object files, put 
the object files into a temp library file. Replace the existing library file 
if it's different from the temp library file."

>   I hate Java. Do you see me taking every opportunity to bash it?
> I sometimes do it, but I don't remember doing it at every possible
> opportunity.

I don't do it in every possible situation either.  I do it when people are 
talking about the difficulty of using a tool designed to compensate for 
limitations built into old programming languages.

>> When someone asked why the C 
>> standard limited global names to six characters and I said it was because of 
>> FORTRAN-based linkers, you didn't seem to mind.
> 
>   Perhaps because it was a relevant answer to a presented question?

Sure. As was this.

>> You don't seem to object 
>> when people make fun of COBOL's wordiness.
> 
>   How many times has that happened, exactly?

At least a couple times. :-)


-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message