Warp wrote:
>   So your definition of "one-liner" has something to do with the amount of
> characters.

Everyone who thinks a one-liner spans two lines, raise your hand!

You realize you're just picking nits, which is coming across as severely 
childish.

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

OK. So if it's a two-liner, does that seriously affect the discussion?

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

Nope. But using someone else's makefile is often problematic.

I'm against (in principle) many technologies that are simple on the surface 
and get abused out the whazoo instead of improving the technology.

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

Yep. Then it might turn into a *three* line shell script.

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

OK, so, yes, it looks like you have to list all the programs. Altho I 
suspect there's some wildcard you could put after all: to make that easier.

It wasn't about length. It was about simplicity and maintainability.

>   (Of course this assumes that there's only one source file for each
> program, and they are named like that, 

That was the original premise of the original question, yes.

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

Another problem with make (and similar tools that get abused). Instead of 
saying "this tool that handles 80% will be really ugly if we modify it to 
handle 90%", people go and add the boxes off the side that then get used in 
baroque ways.

>   Well, the compiler can't look at the source code if you don't tell it
> where it is in the first place. 

Ding ding ding!

> That seems rather obvious, and is true for any language. 

Incorrectamundo!

> You are making it sound like most other languages
> don't need to be told where the libraries and source files are.)

Generally, other languages don't need to be told where the sources for a 
particular library are stored, no.

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

Most other languages don't need to know where the source code is for the 
libraries they use. They only need to know where the source code is for the 
code you're writing.

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

No. No no no. I'm saying I can build dependencies in XNA *without* 
specifying files and such in the project file. You're just disregarding 
that.  I already listed what's in a project file for XNA C#. It 
conspicuously lacks mention of dependencies of source files on other source 
files.

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

There's a list of information that tells your "program that generates code" 
which data files to read, right? How does your "program that generates code" 
based on data files know what data files to read? I guess if it actually 
reads and parses the makefile, it could put the information there without 
duplication.

Oh, I see what you're saying. You're thinking of something like YACC, where 
the source files are passed on the command line. Yes, you're right, the 
makefile can be the sole repository of the list of dependencies, in that case.

But look at the C compiler. You have the list of dependencies in the 
makefile for invoking the compiler, and then inside the source code there's 
the list of dependencies in the form of #include files.

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

Do you deny that your makefile is going to have a list of files your main C 
code includes, and your main C code will also have that list of files? 
Isn't the -M option indeed specifically intended to duplicate that 
information in two different formats?

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