Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> Darren New <dne### [at] sanrrcom> wrote:
>>>> Besides, I thought you don't like C either.
>>>   The issue was the #include scheme, which you seem to hate and I really
>>> can't understand why.
> 
>> Experience! :-)
> 
>   Or lack thereof, it seems.

Nope nope. Shell shock.  Zeno's Debugging.

I had a function that looked something like this:

RMint open(RMchar* name)
{
    RMerr err;
    RMthing = RMDoThing1(name);
    RMother = RMDoOther(name, RMthing);
    RMstuff = RMStuff(RMthing);
    .....
    return (RMint) 0;
failure:
    return err;
}

And what was coming back from that function was 0x19382. And I had to figure 
out which function was doing that.

Nowhere in the function do we actually have a goto, nor do we assign to err. 
Nowhere in any source file anywhere was there the number 19382 or its 
decimal or octal equivalent.

I attempted to use the debugger, but there were calls to precompiled 
libraries without debugging information that was calling back to this 
routine, so that didn't work.

After I figured out that RMDoThing1 and ilk were actually macros that 
assigned to err and did "goto failure" if it wasn't zero, I then had to do a 
full recompile of all the code with stdout redirected to a file, then track 
down the name of the .c file this code appeared in, then look thru the 
command line arguments to gcc to see which include file directories appeared 
in what order, then look at each of the dozen RMblah.h files in those 
directories in the right order (because each of them appeared in several 
directories) and do that recursively looking for the definition of each of 
those files to find the one that actually had each of those macros in it. 
(In hindsight, I probably should have used -E to see if I could figure it 
out, but that probably would have failed the way my luck was going.)

*Then* I had to figure out that somewhere in the dozens and dozens of 
include files was a line that said
    #define char }}}}
because they didn't want you using a char, they wanted you using a RMui8 or 
some such nonsense. Spend half a day trying to figure out why
    extern int write(int,char*,int);
won't compile at the top of your file and see how much you like C #includes.

Once I tracked that down, I had to figure out what the string was for that 
error message. I.e., what the defined symbol was. But the actual value 
didn't appear in any of the files. Indeed, the #include files wwere full of 
crap likle

#define ERR_NOTFOUND (ERRCURR+1)
#define ERRCURR (ERRCURR+1)

which means if you included the include files in a different order, or added 
one or left it out, your error numbers would change.

OK, so finally add -E.  Nope, sorry, the makefile depends on environment 
variables passed down from several makefiles above, *and* parts of it get 
recreated as part of that process, so changes you make to this makefile get 
clobbered. You have to go track down the source code for the makefile that's 
actually compiling the code. Good thing you saved the complete log of stdout 
and stderr while you were compiling so you could see which makefile in the 
process clobbers the makefile you're trying to modify, and see where it's 
coming from, assuming they didn't put an @ in front of that bit.


Over a week of work to track down which function call was returning the 
error and what it meant, due directly to #include, #define, and makefiles. 
And, admittedly, really really *bad* programming of those things.



So, in summary, no, not everyone who disagrees with your conclusions is a 
fool with no knowledge of the process.


>   It just looks to me that whenever there is a problem with something,
> you just love to blame it on C/C++ if it's somehow involved.

I believe that's because you don't look at what I'm saying objectively, and 
instead you simply say "Oh, Darren's on about C again, and since I don't 
have problems with it, he must just not know what he's talking about."

>   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.  The original 
question wasn't about dependencies at all. His original question was how to 
compile a bunch of .c files into corresponding executables without getting 
a.out as the result. That has nothing to do with dependencies, and telling 
him to use make when a simple one-line shell script works is overkill.

Really. Go back and read the first post. Nowhere in there is a question 
about dependency tracking.

>   You *could* have a separate dependency rule creation tool that does
> nothing else. On the other hand, it was easier to add that to the C
> preprocessor, so they did that.

Or, you could have the tools generate dependency information as they compile 
the first time.

>>> *That* is essentially what
>>> you are complaining about. In other words, the C/C++ compilers doesn't do
>>> everything out-of-the-box, but instead you need additional tools.
> 
>> Nope. Other languages have separate tools too. It's just built into the 
>> compiler for simple cases.
> 
>   So when other languages have dependency rule generation built in, it's ok,
> but when the C compiler has, it's somehow not ok.

You're completely ignoring the point I'm making, apparently solely to be 
right.

>>>   Well, if you don't like it, then don't. 
> 
>> And *that*, my friend, is how this discussion started.
> 
>   In other words, you didn't answer his question, which is my point.

I *did* answer his question. I provided him a shell script to recompile the 
programs he wants compiled. He didn't ask about make. He asked about how to 
name the files. Someone else said "use make". I said "make is inappropriate 
for that."

>> Andrew asked about 
>> make, I said "You won't like it, so use something else", and you got upset 
>> that I explained why he won't like it. :-)
> 
>   And what exactly is that "something else"? How was your answer helpful
> in any way?

You said "if you find yourself compiling the same programs over and over, 
that's what Make is for."  No, make is for tracking dependencies.  I 
suggested he hit the up-arrow key, or use !!, or put the command line to 
compile all his programs into a shell script, all of which would answer hsi 
original question of "how do I take a .c file and turn it into an object 
file with the same name as the .c file without the extension."

Yes, Make can do that.  But a shell script is easier for someone who doesn't 
want to learn make.

>>>   You are, hence, barking up the wrong tree. It's not the programming
>>> language that is the "problem". It's the separation of compiler and
>>> dependency file system that irks you.
> 
>> No, it's the inability to correctly figure out dependencies based on the 
>> source files that's really the cause of the troubles.
> 
>   So now you are changing the argument. 

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. 
Most other systems don't have that feature.  In Java, the .class file 
depends on the .java file, for example, and nothing else.

 > First the problem was that you
> need a separate tool to generate the dependency rules, but now the problem
> is "the inability to *correctly* figure out dependencies", whatever that
> means.

If I give you a collection of source files, you can't tell by looking at 
them what the dependencies are. That information isn't stored in or with the 
program itself.

>   Which tool incorrectly figures out the dependencies?

It's non-trivial to figure out the correct dependencies, to the point where 
you (a) need a tool to do it and (b) very often need to run the entire build 
system to figure out what gets included where.

>   Why does it feel that you are desperately trying to pile up more and more
> perceived problems to the issue?

Because you keep dismissing the problems I present as "not a problem", so I 
keep backing farther and farther up the chain of causality until you go 
"yes, I agree that happens."

>>  > You just love
>>> to hate C, so you just can't miss an opportunity to bash it.
> 
>> I actually like C.
> 
>   You are certainly making a very good job at hiding it.

There are things with C that cause problems. This is one of them. It's 
something you have to be very careful about. Building big systems in C is a 
difficult thing to do and takes great care, and I have been burned many 
times in my life working on big systems in C that

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

 >  Why does it feel that you are desperately trying to pile up more and more
 > perceived problems to the issue?

Why does it seem you're off-hand dismissing significant differences without 
even thinking about what I'm saying?


>   Maybe what irks you is that with makefiles you need to write a bit more
> syntax to get the same effect.

No, it is, in part, that the information in the makefiles is separate from 
the actual build system, so you have to duplicate the information.

>> You can achieve it with a makefile, yes, but primarily not by having the 
>> dependency stuff going on, but by building them as different projects. That 
>> is, one tends to have a top-level makefile that says "first run make on the 
>> content generator, then run make on the content, then run make on the 
>> packaging directory."
> 
>   I suppose you could do that, but I don't think it's necessary.

I've never seen it done differently. I suppose you could have one giant 
makefile for a complex project, but most times I've seen it done with 
recursive makefile invocation. Indeed, there are entire sections of the make 
manual and options to makefile variables that provide for this usage, so 
it's not exactly uncommong.

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