Darren New <dne### [at] sanrrcom> wrote:
> >   I'm pretty certain most IDEs don't eg. calculate checksums of every single
> > source file to see if they have changed from the last time that it was
> > compiled. 

> In languages where it's important to be correct, like Ada, yes they do. In 
> C#, yes they do, because they don't *look* at include files, they look at 
> object files. C# doesn't *have* include files. That's the point. If you say 
> "use the types from *that* assembly" and then later you replace the assembly 
> with an incompatible version, your code will get recompiled (or will refuse 
> to start if you try to run it without recompiling).

> In Ada, you don't calculate the checksums of every source. You calculate the 
> checksum of the file you're compiling when you compile it. In C#, your file 
> is either associated with a project (i.e., with the equivalent of a 
> makefile) or it's installed in the global assembly cache with a version 
> number and a cryptographic checksum on it you can check against.

  So if you have thousands of files in your project, the compiler will
calculate the checksums of every single one of them every time you want
to compile? And it was you who complained how creating makefile rules for
C files is inefficient... Right.

> >> If you change the source file 
> >> then accidentally change the object file it fails.
> > 
> >   Yeah, and if you accidentally delete the makefile, it also fails. Duh.

> No, if you delete the makefile you get an error. If you touch the object 
> code after changing the source, you get a silent failure. There's a big 
> difference there.

  Yeah, and if your hard drive dies, you also get a failure. Also a big
difference. I still don't get your point.

  You talk as if accidentally touching an object file is a relatively
common happenstance. Well, in the fifteen or so years I have been using
makefiles, guess how many times that has happened to me. (In fact, a HD
dying has happened to be more often than that.)

> > There are like a million scenarios where you accidentally do something to
> > your files which will cause a malfunction (regardless of your IDE).

> Sure. You're apparently trying to miss my point here, which is that the idea 
> that basing dependency information and content-change information solely on 
> file timestamps is iffy.

  The situations where it causes problem are so extremely rare that it just
isn't worth the price of the compiler calculating checksums of every single
file in the project every time you want to do a quick compile. Imagine that
every time you want to compile your project, you had to wait a minute for
the compiler to check all the checksums, when with the current scheme it
can do it in a few seconds.

  Nevertheless, you are still blaming the programming language for a
defect you see in the compiling tools. All this has nothing to do with C.

> >   Of course the makefile assumes that you have specified all the necessary
> > dependencies. It cannot read your mind.

> I have never seen a makefile that lists as a dependency of my code all the 
> things that stdio.h includes.

  And that makes it impossible to create such a makefile (especially if you
are using a dendepency-generation tool)?

  Anyways, exactly why would you want to recompile your program if stdio.h
changes? You see, stdio.h is standardized, and if it was changed in such
way that programs would need to be recompiled for them to work, it would
mean that the C standard has been changed to be backwards-incompatible and
it would break basically all programs in existence.

  Yeah, very likely to happen.

  Even if stdio.h would be changed in a backwards-compatible way (eg. a
new non-standard function declaration is added) you would not need to
recompile any existing program. It would not affect them.

  If you are making an extremely rare program which truly needs to be
recompiled every time stdio.h changes, the solution to this is rather
trivial.

> >   If you are using a tool to create the dependency lists and that tool
> > fails for some reason, blame the tool, not make.

> If I'm using a tool to create makefiles, then sure, but that's just saying 
> makefiles are so useless that I have to automate their creation. Why would I 
> use a tool to create makefiles using a tool that just does the job properly?

  You could make the same argument for any program that doesn't do everything,
and needs to work in conjunction with another program in order to perform
some task. Your argument is moot.

  As for makefiles, not all things that can be done with makefiles can be
automated.

> >   There's nothing wrong in using two tools to perform a task rather than
> > one. Do you also blame 'ls' for not supporting everything that 'sed'
> > supports?

> There's really only one task going on here - dependency checking. That's the 
> one and only thing Make does.

  Make can't know if eg. a code-generating program depends on some data
files unless you tell it.

> >   'make' is not used only to compile C/C++ programs. It can be used for
> > quite many tasks, including things that have nothing to do with compiling
> > a program. 'make' is designed to be a versatile tool for these tasks.

> That's what I asked earlier. I just never found anything that *actually* 
> uses the dependency analysis of make to build something other than C-like 
> code or libraries therefrom.

> Do you have things in your makefile for processing the graphics for your 
> games? Does it only reprocess them only when the source graphics change?

  I gave an example in my other post of an actual project I have been
working in where makefiles are useful for something else besides purely
compiling C++.

> >> So you invoke the compiler to create the makefile. You're splitting hairs 
> >> here.
> > 
> >   I'm not. gcc does not "compile" the program when I run it with the -M
> > parameter. It just runs a simplified C preprocessor to track all the
> > included files. The major difference is, obviously, speed.

> Sure. But you're invoking the compiler, and with the same sets of 
> command-line options and environment variable expansions as when you do the 
> full compilation.

> I'm sorry, but if anyone in the world asked me "how do I invoke the gcc 
> compiler", I'd say "use /usr/bin/gcc" or something. I would *not* add "but 
> be careful not to pass the -M flag, because that doesn't invoke the compiler."

  Actually I'm invoking the C preprocessor. I could call it directly, but
gcc does it automatically when you specify the -M parameter. The calls
"gcc -M test.cc" and "cpp -M test.cc" produce the exact same result.
I could simply use the latter if I wanted to be pedantic.

> The point is that you're using C-specific code written by the same people 
> who wrote the compiler to figure out what the C-specific dependencies are. 
> The speed is irrelevant. What's relevant is that the C nested includes are 
> sufficiently complex that you need a tool to generate the input to the next 
> tool, where the "next tool" was supposed to stand alone on its own in 
> simpler times.  In more complex times, the stand-alone tool is mostly 
> useless. We have gotten to the point where any time "make" saves you enough 
> compilation time to be worthwhile, generating the makefiles is too complex 
> to be easily maintainable.  Make lives on not because it's good, but because 
> it's as ubiquitous as C. But environments that don't use C don't use make 
> either, because it's just not a very good tool.

  Instead, we have "project files" in IDEs which do... what? Well, exactly
the same thing as makefiles. In fact, "project files" are just makefiles,
using some other IDE-specific syntax. (They might have features that 'make'
doesn't support, but in principle they are the same thing.)

  Yes, you can use project files for things other than purely compiling
the program, such as running command-line tools to build data files and
such. Exactly what makefiles do. (And yes, I have done this at least with
Xcode project files.)

  The only difference is that most IDEs generate the dependency rules for
source code files automatically so you don't have to write the few magic
lines into the project file yourself. However, again, in principle it's
no different from a generic makefile that generates dependency rules
automatically (like the one I pasted in an earlier post).

> >> If I can't easily create the makefile by looking at the source code 
> >> I'm trying to compile, it's baroque. :-)
> > 
> >   I just can't see what's so wrong in using a tool to create the makefile
> > dependency rules. Do you really *want* to be writing makefiles by hand?

> I have no trouble at all writing makefile rules by hand when it's *not* C 
> that I'm compiling. That's exactly my point. C's dependencies are 
> sufficiently opaque that it's actually problematic just to figure out what 
> they are, to the point where one feels the need to actually write a number 
> of tools to figure it out, including modifying the compiler to help you out.

  You still can't get past the fact that in unix different tasks are
separated into different tools. Fine, you hate that. Move on.

> >   Generating the rules is pretty fast, and the need doesn't present itself
> > very often, and re-generating the rules is quite easy. I just can't see
> > the problem here.

> Regenerating the rules is only quite easy because someone added a flag to 
> GCC to make it regenerate the rules.

  Actually to the C preprocessor.

> Now, go regenerate the rules without 
> the -M flag.

  And why exactly would I want to do that? You might as well ask "compile
the program without using the compiler".

> I'm not saying that generating the dependencies, *today*, isn't 
> easy. I'm saying that the job Make was created to handle, namely recording 
> and evaluating dependencies, is obsolete.

  And how do you propose to handle dependencies on things that the compiler
does not handle, such as creating data files from some input files using
some tools (and perhaps recompile the program only if those data files
change)?

> Makefile dependency lists are, for 
> the most part, created by other tools

  Only program source code dependencies. If you have other types of
dependencies you still need to specify them by hand because no automated
tool can read your mind.

-- 
                                                          - Warp

Post a reply to this message