Invisible wrote:
> Short of a tool to actually analyse a source tree and figure out 
> all the dependencies, it's difficult to handle this properly. 

And that's why I've been saying that Make isn't really a very good tool for 
maintaining that sort of thing.

> You would 
> need a tool to read the entire source and compute the dependencies.

You already have that tool. It just doesn't output its results in a form 
that Make can consume. Certainly the tools that generate the documentation 
files know which output files depends on which other files.

> Thus, if any compiler source code changes, 

Sure. I was asking whether if you change a test case, does "make test" just 
run that one test case?  I've never seen that done.

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

Warp wrote:
>   Never miss a chance to bash C.

I don't understand how me describing a problem that caused me not to like 
certain features of C is "never missing a chance to bash C."

>   Of course it cannot know which files a something depends on unless you
> tell it. Seems rather obvious to me.

OK, at this point, you're just refusing to understand what I'm saying.

>> Right now, for example, I have an XML file I use to specify the levels for 
>> my game. In those XML files I include the lists of animations going on in 
>> different places, the textures, etc etc etc.
> 
>> Know what? Make doesn't handle that.
> 
>   Sounds like something 'make' was specifically designed for.

Not really. Make only handles it if I manually duplicate that information 
into a different format.  If I add something to the XML and not to the 
makefile, it's not going to work any more.

Are you telling me that the need for duplicating that sort of information is 
a *good* idea? Or do you admit that needing that information in two 
different places in two different forms is indeed a limitation that it would 
be desirable to eliminate?

>   You don't seem to understand that 'make' is a generic tool. Or more
> precisely, you don't seem to understand what the word "generic" means.

I'm fully aware of what "generic" means. You ask me why I don't like A, and 
I say "it leads to problems with B", and you say "make up your mind whether 
it's A or B you're going to bash."

>   And the best part of all this? So far you haven't given even a single
> alternative that would do everything that 'make' does and is better by
> your definition (whichever that might be). And preferably one that can
> be run in most systems.

And you know what? There will never be such an alternative by folks who 
think that anyone pointing out a limitation with their tools are simply 
bashing for the sake of bashing.

That said, there are many alternatives to make, some of which even generate 
makefiles as output.

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

Warp wrote:
>>>   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.

Sure. There's /bin/test for stuff like that, if you really care to do that. 
The idea that Andrew is writing C systems big enough to worry about compile 
time while not already have a makefile built for them is kind of unlikely, 
methinks.

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

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

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

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

If you really want to worry about dependencies:

for i in (*.c) ; do if test $i -nt ${i%.c} ; then gcc -o %{i%.c} $i ; fi ; done

OK, that one wrapped. Still not significantly more complicated, especially 
if you already know bash but don't already know make.

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

>   Creating a shell script for this is the hard way.

It's not hard. It's trivial. I wrote both of those off the top of my head 
without looking anything up. They're *equally* trivial.

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

No, because you provide more to the compiler than the source code.

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

>   I suppose compilers do it by magic, then.

Nope. Compilers look at stuff that isn't in the source files.

>   Besides, you *are* changing the argument. First it was "make cannot figure
> it out on its own", 

That's correct.

> then it was "it's not possible to correctly figure out
> the dependencies" (whatever that means, as I still don't get it).

... from looking at the source code.  You keep leaving that bit off.

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

Maybe because I'm trying to explain an elephant to a blind man who refuses 
to believe it even exists?

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

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

Or, if you really wanted to knurl your gears, you could imagine a tool that 
runs the compiler (or whatever program you specified) and uses strace to 
track what files it opens for reading and what files it creates, and from 
that track dependencies automatically. This would work with any tool, would 
automatically track every dependency (perhaps too much, granted), and would 
not need anything changed in any tools you use. But that would be admitting 
that make has some limitations.

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

Warp wrote:
>> 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.

Here are three C source files. Please compile them and tell me what it 
prints. Or do you think this code is impossible to compile? Or do you admit 
that it's impossible to figure out by looking at the source code what the 
dependencies are on other source code?

/tmp/main.c:

#include "xyz.h"
#include <stdio.h>
int main()
{ printf("Answer=%s\n", ANSWER); return 0; }


/tmp/one/xyz.h:

#define ANSWER "Hello"

/tmp/two/xyz.h:

#define ANSWER "World"




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

Warp wrote:
> "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).

Say this in a brogue for me:  "I see. No *true* one-line script uses a for 
loop. It's not *really* a one-liner just because you can fit it on one line!"

Yes, at this point, I'm making fun of you trying desperately to show that 
I'm wrong by making up arbitrary silly No-True-Scotsman distinctions. And 
here you say *I* am moving the goalposts.

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

>> Short of a tool to actually analyse a source tree and figure out all
>> the dependencies, it's difficult to handle this properly.
>
> And that's why I've been saying that Make isn't really a very good tool
> for maintaining that sort of thing.

More precisely, Make only solves half of the problem.

>> You would need a tool to read the entire source and compute the
>> dependencies.
>
> You already have that tool. It just doesn't output its results in a form
> that Make can consume. Certainly the tools that generate the
> documentation files know which output files depends on which other files.

Interestingly, GHC can generate a Makefile containing a description of 
the *source code* dependencies. Just not *documentation* dependencies. I 
suppose because nobody needs it, because Haddock can do it for you.

>> Thus, if any compiler source code changes,
>
> Sure. I was asking whether if you change a test case, does "make test"
> just run that one test case? I've never seen that done.

Erm... It might do, actually. I'm not sure. I'd have to go check.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Never miss a chance to bash C.

> I don't understand how me describing a problem that caused me not to like 
> certain features of C is "never missing a chance to bash C."

  The discussion was about makefiles and resolving include file dependencies,
and as a "side note" you mentioned how some #defines can mess up code
really badly in C.

  Yes, I know that you can create really, really obfuscated code in C by
abusing the preprocessor, and that there exists lots and lots of C code
out there that abuses this to horrendous extremes. How is this related
to the question of makefiles?

> >   Of course it cannot know which files a something depends on unless you
> > tell it. Seems rather obvious to me.

> OK, at this point, you're just refusing to understand what I'm saying.

  You are saying that 'make' cannot know which files something depends on
unless you tell it (eg. by manually listing the files or by using a tool).
I'm saying the same thing. What is it that I'm not understanding?

  The difference is that you are somehow expecting 'make' to know about
a myriad of file formats and how they are used and how they depend on other
files, while I'm saying that 'make' is a generic tool, not a tool specific
to certain programs or file formats. You don't like 'make' being a generic
tool.

> >> Right now, for example, I have an XML file I use to specify the levels for 
> >> my game. In those XML files I include the lists of animations going on in 
> >> different places, the textures, etc etc etc.
> > 
> >> Know what? Make doesn't handle that.
> > 
> >   Sounds like something 'make' was specifically designed for.

> Not really. Make only handles it if I manually duplicate that information 
> into a different format.  If I add something to the XML and not to the 
> makefile, it's not going to work any more.

  So your complain is, once again, not about makefiles per se, but about
the need to use tools to automatically create and update the dependencies.

  How would you enhance the whole makefile process so that it *would*
conform to your needs?

> Are you telling me that the need for duplicating that sort of information is 
> a *good* idea? Or do you admit that needing that information in two 
> different places in two different forms is indeed a limitation that it would 
> be desirable to eliminate?

  Exactly how would you eliminate the need?

  What happens if you have a custom format which has similar kinds of
dependencies? How do you expect it to work then?

  You still can't get over the fact that 'make' is a generic tool.

> >   And the best part of all this? So far you haven't given even a single
> > alternative that would do everything that 'make' does and is better by
> > your definition (whichever that might be). And preferably one that can
> > be run in most systems.

> And you know what? There will never be such an alternative by folks who 
> think that anyone pointing out a limitation with their tools are simply 
> bashing for the sake of bashing.

> That said, there are many alternatives to make, some of which even generate 
> makefiles as output.

  So you do and don't oppose the idea of using third-party tools to generate
the dependencies. Double-think?

-- 
                                                          - Warp

Post a reply to this message

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

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

> Here are three C source files. Please compile them and tell me what it 
> prints. Or do you think this code is impossible to compile? Or do you admit 
> that it's impossible to figure out by looking at the source code what the 
> dependencies are on other source code?

  So essentially you want the compiler to know what to compile without
you specifying what to compile.

  AFAIK mind-reading technology has still not been invented.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > "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).

> Say this in a brogue for me:  "I see. No *true* one-line script uses a for 
> loop. It's not *really* a one-liner just because you can fit it on one line!"

  Exactly how long is your "line", and why exactly? Why do you choose such
an arbitrary limit?

  If I use an editor with a width of 150 characters, would that be the limit?
What if I narrow it?

  In fact, most editors don't have any limit for line lengths. Does that
mean that every program can be written as a one-liner?

> Yes, at this point, I'm making fun of you trying desperately to show that 
> I'm wrong by making up arbitrary silly No-True-Scotsman distinctions. And 
> here you say *I* am moving the goalposts.

  You know, throwing an accusation back to the person who made it is just
a childish "no I'm not, you are!" argument.

-- 
                                                          - Warp

Post a reply to this message