Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>>   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.
> 
>   Now you are changing your argument once again.

My argument is multi-faceted, as is most complex stances. When you only look 
at the messages I write that are answers to your specific questions, it 
looks like I'm changing what i'm saying, because you're looking through a 
pinhole at the entire argument.  When I write down in a handful of 
paragraphcs a complete and cogent description of my point, you apparently 
don't read it, as you never reply, ask about it, and then later claim that I 
never gave the examples I used in those posts.

>> I'm against (in principle) many technologies that are simple on the surface 
>> and get abused out the whazoo instead of improving the technology.
> 
>   And shell scripts, which is what you advokated instead of makefiles,
> cannot be abused nor can they be impossible to understand? I don't even
> understand your point anymore.

No, clearly not.

>   All things considered, I don't think that this simple case is all that
> complicated. (The only complicated thing is figuring this out.)

I agree. Not sure why you're making such a big thing of me pointing out that 
the simple system works fine with shell scripts.

>>>   (And granted, with a "standard" non-gnu makefile you would need more
>>> than this.)
> 
>> Another problem with make (and similar tools that get abused).
> 
>   I honestly cannot undrestand why you call this "abuse". 

Your reading comprehension is poor. Where did I say what you wrote is an 
abuse of make?  Answer: I didn't. I said that having a bunch of different 
versions is indicitive of a program whose capabilities have been expanded 
over time bit by bit without a coherent plan, in such a way that such 
extentions tend to get abused.

And in another post, I explained why such a thing gets abused, which answers 
the first question you had.

>>>   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!
> 
>   Your point being?
> 
>>> That seems rather obvious, and is true for any language. 
> 
>> Incorrectamundo!
> 
>   So there exists a compiler which indeed can read your mind so that you
> don't have to explicitly specify what it needs to compile. 

Nope. It doesn't have to read your mind.  Of course it has to know what to 
compile. The problem is not that you have to tell the compiler what to 
compile. The problem is you have to (in C) compile much more than your own 
source code in order to compile your program.

I have no problem telling a C compiler what and where my program is. I just 
don't think it's a good idea to have to tell a C compiler where everyone 
*else's* source code for libraries that are already compiled is. For some 
reason, you insist on ignoring the distinction. I suspect you do so in order 
to be able to feel you're still right.

(As far as me bashing, I find it amusing that when I bash a feature in C 
that's improved in C++, you don't get upset, but if I bash a feature in C 
that is carried over to C++, you justify it out the wazoo.)

>>> 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.
> 
>   Bullshit. Specific compilers might have *default* paths for the libraries,
> and so does a typical gcc installation in linux. That doesn't mean that
> the compiler is not being told where the libraries are.

You don't understand the word "sources" in that sentence?  Reading 
comprehension, dear.

>   You really are desperately trying to find flaws that just aren't there.

You're just ignoring my complaint and tilting at strawmen.

>> 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.
> 
>   So XNA employs this new marvelous mind-reading technology, as it is able
> to know what to include in the project without you having to explicitly
> tell it.
> 
>   How does it work? Does it scan brainwaves?

No. I already wrote an extensive post describing all the sections of an XNA 
project file, as well as the mechanisms whereby the dependencies get 
described implicitly. Which you have apparently either not read or disregarded.

>> 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.
> 
>   That's one of the most typical ways of building complex projects in unix,
> and it's precisely what makefiles are designed for (and is typically why
> command-line tools take things as command line parameters or, at worst,
> as data it reads from the standard input stream).

Yep. Of course, if your YACC grammar has something equivalent to an #include 
in it, you're back to listing dependencies in multiple places.

>> 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.
> 
>   Which is why you can *automate* the creation of the dependency rules
> rather than having to do it by hand.

The fact that you can automate (in some cases) the copying of dependencies 
from one place to another does not mean you're not copying dependencies from 
one place to another.

>   The #include file mechanism in itself is useful for other reasons,
> especially in C++, which is why it has its advantages.

Yes. In C and C++, #include is useful. It allows a number of things (like 
really powerful templates) that would be difficult (but not impossible, as 
seen in LISP and Erlang for example) to do in other ways.

>>>   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?
> 
>   I was talking about my example of a code generator creating code from
> some input files.

Right. And in *my* example, which is what I was talking about since you 
never gave a specific example, the dependencies are in the data file (like 
#includes would be) rather than on the command line.

>   Nevertheless, why should I care if some #include file information is
> duplicated, as long as it happens automatically?

Because now you need a third-party tool to automate dependency generation.

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