Darren New <dne### [at] sanrrcom> wrote:
> >>>   The issue was the #include scheme, which you seem to hate and I really
> >>> can't understand why.
> > 
> >> Experience! :-)
> > 
> >   Or lack thereof, it seems.

> Nope nope. Shell shock.  Zeno's Debugging.

  You have seen a lot of bad C code. I understand that. That's not what
I'm arguing.

> >   And which tool, exactly, did you recommend instead? I remember you
> > mentioning shell scripts. Yeah, those can track dependencies just fine.

> Indeed they can, when you don't have nested dependencies.

  "Indeed thay can"? Shell scripts don't have any kind of dependency
tracking whatsoever. I think you are somehow splitting hairs with
terminology.

>  The original 
> question wasn't about dependencies at all. His original question was how to 
> compile a bunch of .c files into corresponding executables without getting 
> a.out as the result. That has nothing to do with dependencies, and telling 
> him to use make when a simple one-line shell script works is overkill.

  Exactly how do you compile a bunch of .c files into corresponding
executables with "a simple one-line shell script"?

  Ok, you could write a 'for' loop which goes through a list of .c files
and compiles them (resolving the name of the executable by removing the
".c" part) and put all that in one line, but putting all commands into
one single long line is not what is usually meant by a "one-liner"
(except perhaps in the IOCCC). "One-liner" usually refers to being able
to express the task with one single command (a 'for' and its body are
usually considered separate commands).

  Perhaps what you meant was one line per program. That could probably
work for what he wants to do, if he doesn't mind that *every* program
will be recompiled every time he wants to recompile just one of them.

  This is exactly where a makefile would be useful: It would compile
only the program that needs recompiling, skipping the others. And even
if you wanted to go the easy way and just not have to specify any
dependencies, you can still use the makefile to compile only what you
want to compile (with something like "make program3").

  The advantage of that over having a separate shell script for every
single program? You only need to specify compiler options (eg. warnings
and optimizations) once, rather than duplicating it in each script.
(Of course you could have each script call a common script that has the
options, but that starts already being a lot more complicated than the
makefile would be, for no discernible benefit.)

  If you want to compile only one single program, or automatically compile
only the programs that need to be compiled, the *easiest* way is to use
a makefile. A shell script would be significantly more complicated. After
all, that's precisely what makefiles are for.

> I *did* answer his question. I provided him a shell script to recompile the 
> programs he wants compiled. He didn't ask about make. He asked about how to 
> name the files. Someone else said "use make". I said "make is inappropriate 
> for that."

  Which is BS. You seem to think that you can't create a makefile that
compiles programs without the dependency lists. It's not like you are
forced to provide them.

  Creating a shell script for this is the hard way.

> >>>   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.
> > 
> >> No, it's the inability to correctly figure out dependencies based on the 
> >> source files that's really the cause of the troubles.
> > 
> >   So now you are changing the argument. 

> No. The programming language is such that it is impossible to figure out by 
> looking at the source code what the dependencies are on other source code. 

  If that were true, then it would be impossible to compile the program.
After all, it's impossible for the compiler to figure out which files are
being included just by looking at the source code.

  I suppose compilers do it by magic, then.

  Besides, you *are* changing the argument. First it was "make cannot figure
it out on its own", then it was "it's not possible to correctly figure out
the dependencies" (whatever that means, as I still don't get it).

  Let's see where will you move the goalposts next.

> >   Which tool incorrectly figures out the dependencies?

> It's non-trivial to figure out the correct dependencies, to the point where 
> you (a) need a tool to do it and (b) very often need to run the entire build 
> system to figure out what gets included where.

  Oh, now "inability to correctly figure out dependencies" has been changed
to "it's non-trivial to figure out the correct dependencies".

  Keep moving the goalposts. Which fancy term will you use next?

  Why does it feel like you are desperately trying to find problems and
just can't seem to be able to decide what the actual problem is?

> >> Yet, oddly enough, that's precisely what the XNA content pipeline does, and 
> >> you just give it a list of all the source files, including the graphics and 
> >> audio and stuff. Sure, you mention the name of the code used to compile it, 
> >> but there's enough information from that to track down where the executable 
> >> and such is. It also makes it possible for the thing that's compiling your 
> >> collection of frames into an animation to say "the resultant animation 
> >> depends on this list of frames as well as the text file specifying the list 
> >> of frames", which you can't do with a makefile.
> > 
> >   I don't get it. That's exactly what you do with make,

> Nope. It's not what you do with Make, any more than writing C++ code is the 
> same thing you do when writing C code.

  Maybe *you* don't use 'make' for that, but I do.

  Then, perhaps your preferences are "right" and mine are "wrong".

> >   Maybe what irks you is that with makefiles you need to write a bit more
> > syntax to get the same effect.

> No, it is, in part, that the information in the makefiles is separate from 
> the actual build system, so you have to duplicate the information.

  But it's what allows you to generate building rules for things that don't
have any automated tools. (And yes, the same thing can be done with the
'project' files of most IDEs. They are, after all, doing basically the same
task.)

  I wrote an example earlier: Suppose you have written a program that
generates code, and it generates the code from some data files. Obviously
you would want the program to be run if (and only if) some of those data
files change. Exactly which automated tool would you use to do this?

-- 
                                                          - Warp

Post a reply to this message