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.

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

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

  From a two-line makefile. The advantage is left to anybody's guess.

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

  You can use wildcards if you don't mind going a bit to the cryptic side
of gnu make (and AFAIK it requires one additional line because I think the
wildcard cannot be embedded in the rule):

CPPFLAGS=-Wall -O3
SOURCES=$(wildcard *.cc)
all: $(SOURCES:.cc=)

  If you are ok with writing the program's name you want to compile
(ie. "make program3") you could just have the CPPLFAGS (and possibly
LDFLAGS if you need some special linker parameters) line in the makefile
and nothing else, to get the command line options you want.

  (All this works because there's a big bunch of implicit rules in gnu make.
I think there was actually a command-line option to list them.)

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

> >   (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". This is *precisely*
what 'make' has been designed for. How can you "abuse" a tool for a purpose
it was specifically designed for?

> >   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. Never heard of
such an innovation. Is there a scientific paper somewhere about mind-reading
software?

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

  When I compile a C++ program, I don't need to tell gcc where eg. <iostream>
is located. However, that doesn't mean that nothing is telling. Of course
something is telling it, else it would not be able to find it. Just because
the path has been pre-configured in this linux distro doesn't change the
fact.

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

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

  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?

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

> 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. I know you don't like that 'make'
doesn't have built-in support for this kind of automation, but it just
causes a few extra steps to be necessary. I don't think it's such a big
deal.

  Most IDEs do this automation out-of-the-box when you have a project in
C or C++ (or Objective-C). It might be a bit easier with those IDEs, but
in principle it's not much different.

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

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

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

-- 
                                                          - Warp

Post a reply to this message