|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> Warp wrote:
>>> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |