Darren New <dne### [at] sanrrcom> wrote:
> Besides, I thought you don't like C either.

  The issue was the #include scheme, which you seem to hate and I really
can't understand why.

> >   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.

  Firstly, that doesn't answer the original question. It's not like Andrew
was making a choice of programming language for his next project. He just
wanted an easy way to compile a bunch of programs. Your answer doesn't help
his problem in any way.

  Secondly, what is it exactly that allows other languages to compile only
what has changed, rather than everything every time? Right: The compiler
keeps track of changed files and compiles only what has changed.

  In a unix system this tracking has been separated into its own set of
tools, rather than being part of the compiler. *That* is essentially what
you are complaining about. In other words, the C/C++ compilers doesn't do
everything out-of-the-box, but instead you need additional tools.

  Well, if you don't like it, then don't. It's just how the unix ideology is.
You might disagree with the ideology and argue how it's antiquated, but it's
not something that bothers everybody. Some people like one tool doing one
thing, rather than one program trying to do everything.

  You are, hence, barking up the wrong tree. It's not the programming
language that is the "problem". It's the separation of compiler and
dependency file system that irks you. You are just blaming the programming
language for it because you love to hate it.

> 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.)

  Can you guess how many source code dependency definitions I have ever
written when I have used Microsoft's Visual C++ or Apple's Xcode?

  That's right. You are putting the blame on the programming language,
when what really irks you are the unix compiling tools. You just love
to hate C, so you just can't miss an opportunity to bash it.

  Yes, I hate C too, but I don't blame it for flaws that it doesn't have.

>  > (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.

  Sometimes the dependencies are more complicated. For example you could
have a program in your project which generates code, which then gets
compiled into the actual executable. That code-generation program in turn
may depend on some input files from which it generates the code.

  You only want to compile the code generating program if its source files
change. You only want to run that program if the data files change. You
only want to recompile your actual executable if either of those (or its
own source files) change.

  Obviously a compiler cannot know all this if you simply give it a list
of all the source code files. It needs slightly more elaborate rules.

  Most IDEs support creating these types of dependencies (eg. Xcode does,
Visual Studio probably does too, even though I have so far not needed to
do something like that with it). Obviously you can achieve this with a
makefile as well (after all, it's exactly what it is designed to do).
And yes, I have needed to do this, several times.

  A makefile / project file can be quite useful even further. For example,
you could have a rule to create a distribution package from your program.
The creation of this distribution package ought to have dependencies on
all the files which need to be included. Hence if you eg. change one of
those data files and then build the distribution package, the executable
binary will be compiled first, so that it's up to date. You can't do this
with a simple shell script. (And yes, I also have needed to do this.)

> >> 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.

  How did it answer the original question?

-- 
                                                          - Warp

Post a reply to this message