|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> Warp wrote:
>>> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |