Darren New <dne### [at] sanrrcom> wrote:
> >   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, 

> Yeah. It's one line.

> for i in (*.c); do gcc -o ${i%.c} $i; done

> (Something like that. Untested.)

> Hardly a hulking line.

  So your definition of "one-liner" has something to do with the amount of
characters. How many characters, exactly, is the upper limit for a
"one-liner" and why? When does your "one-liner" become a "two-liner" when
I add one extra character?

  Does the script become a "two-liner" if I add a newline somewhere in
between? What if I add ten newlines? Does it become an "eleven-liner"?

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

> Now you're picking nits again, just like with your arguing that "gcc -m" 
> isn't invoking the compiler.

  Perhaps because defining a "one-liner" as the number of characters in
the script is completely arbitrary?

  And "gcc -M" is invoking the C precompiler.

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

> No. Right there, above. What is that, 40 characters if that?

> And how long would it take to compile *every* program that Andrew has 
> written in C on a modern machine? If he saved as much compile time over the 
> course of his development as he spent reading the manual for make, I'd be 
> surprised.

  Yes, it's much more likely that he would learn to use the shell's 'for'
construct more easily than he would learn how to write a makefile.

  You write as if there was something wrong with learning how to use
makefiles. (Well, by now it wouldn't really surprise me.)

> >   The advantage of that over having a separate shell script for every
> > single program? 

> Your shell scripting skills must really, really suck if you think you'd need 
> a line of shell code for every single program. Just sayin'.

  The context was that I was saying that if he wanted to compile only one
of the programs, or only the programs that have a modified source, rather
than all of them.

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

> Show me a makefile shorter than that line up there.

  It seems that in your world "simpler" and "shorter" are synonymous.
Clearly you haven't looked at any IOCCC entries.

  I'm sure he could write a haskell line that is shorter than your shell
script line. Would it be simpler? (To him it probably would. Not to me.)

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

> I don't remember. Do you have to actually list the programs in the makefile 
> that you want to compile?  Is a makefile that compiles 50 programs 
> necessarily larger than one that compiles 5?

  Again with length. Nevertheless, with gnu make, this is all you need
(and you get compiler options as a bonus):

CPPFLAGS=-Wall -O3
all: program1 program2 program3

  (Of course this assumes that there's only one source file for each
program, and they are named like that, just with the appropriate file
extension. And yes, it will compile only the programs for which the
binary doesn't exist or is older than the source file.)

  (And granted, with a "standard" non-gnu makefile you would need more
than this.)

> > After all, it's impossible for the compiler to figure out which files are
> > being included just by looking at the source code.

> Yes it is. That's why you have -I and -L command-line switches.

  Well, the compiler can't look at the source code if you don't tell it
where it is in the first place. That seems rather obvious, and is true
for any language. (Well, I suppose that if you have a programming language
that doesn't support the sources and possible precompiled libraries to be
located somewhere else than the main source file, you don't need to tell
it where the sources are. You are making it sound like most other languages
don't need to be told where the libraries and source files are.)

  You always succeed in putting the most *trivial* and obvious stuff in
a negative light. "Hey, you need to tell the compiler where the source
files are if you want to compile the program. Clearly the programming
language sucks." You always seem to see problems where there really aren't
any. (Well, at least if we are talking about C or C++. Most other languages
are safe from such a witch hunting.)

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

> OK. You're just refusing to read what I actually wrote, and refusing to see 
> the fundamental difference in the two tools.  I can't tell whether you're 
> doing this intentionally out of ego or what.

  You say that you can build dependencies in XNA by specifying files and
stuff. I say that's exactly what makefiles (and project files in most
IDEs) are for, including XNA project files (although I have never used it,
but I can guess they are similar). This might be more automated with
Microsoft IDE with respect to many file formats, but that's simply a
question of how many automation tools have been embedded into the IDE.
Your only complaint seems to be that 'make' doesn't have all these same
tools embedded and instead you need to use separate tools for that.

  I think it's you who is deliberately trying to enforce a difference
that isn't really there.

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

> Well, as I said, the XNA content pipeline does exactly that, precisely 100% 
> word for word that. And yet, oddly enough, I don't manually duplicate the 
> dependency information into a separate file.

  If I run such a program from a makefile, where exactly is the duplicated
information?

  Your complaints have now shifted to duplication of file names. Exactly
where is the duplication in this particular example?

-- 
                                                          - Warp

Post a reply to this message