 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote:
> > 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.
Since you will not understand what I'm saying above, let me clarify
before you make your inevitable indignated response:
Suppose you have two C# source files of the same name, in different
directories, and they implement a class of the same name, but the
implementations are different. Then you have a third C# source file
that uses that class.
Can you tell me, by looking at the source codes, which version of the
class will be used?
How do you resolve this? That's right: You tell the compiler which files
it needs to compile.
Exactly how is this situation different from your example?
Once again you manage to find an inexistent flaw in C, even though it's
a completely trivial thing that exists in *all* languages, including your
greatly beloved C#. Somehow this triviality is not a flaw in C#, but it
is in C. You just love to find inexistent flaws in it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> What is it that I'm not understanding?
I've already explained it every way possible. I don't think explaining it
again is going to make you understand, because for you, "understand" seems
to mean "agree with."
> How would you enhance the whole makefile process so that it *would*
> conform to your needs?
I already gave several examples of this as well.
>> 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?
I've given several examples of how to do this.
> What happens if you have a custom format which has similar kinds of
> dependencies? How do you expect it to work then?
I've given several examples of how to do this.
> You still can't get over the fact that 'make' is a generic tool.
Oddly enough, so are many of the other build systems that nevertheless don't
require you to list dependencies in multiple places. Several examples of
which I have already given.
>> 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?
No. That would be silly. I think generating makefiles as output from such
third-party tools is limiting and error-prone. But for some reason, you
seem to think "generating dependencies" and "makefiles" are the same thing.
They're not, in ways in which I've given several examples. I don't object
to tools that fix some of the problems with Make. That doesn't mean Make is
a good tool.
--
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:
> So your definition of "one-liner" has something to do with the amount of
> characters.
Everyone who thinks a one-liner spans two lines, raise your hand!
You realize you're just picking nits, which is coming across as severely
childish.
> Perhaps because defining a "one-liner" as the number of characters in
> the script is completely arbitrary?
OK. So if it's a two-liner, does that seriously affect the discussion?
> 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.
I'm against (in principle) many technologies that are simple on the surface
and get abused out the whazoo instead of improving the technology.
> 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.
>>> 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
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.
It wasn't about length. It was about simplicity and maintainability.
> (Of course this assumes that there's only one source file for each
> program, and they are named like that,
That was the original premise of the original question, yes.
> (And granted, with a "standard" non-gnu makefile you would need more
> than this.)
Another problem with make (and similar tools that get abused). Instead of
saying "this tool that handles 80% will be really ugly if we modify it to
handle 90%", people go and add the boxes off the side that then get used in
baroque ways.
> 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!
> That seems rather obvious, and is true for any language.
Incorrectamundo!
> 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.
> 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."
Most other languages don't need to know where the source code is for the
libraries they use. They only need to know where the source code is for the
code you're writing.
>> 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.
> 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?
There's a list of information that tells your "program that generates code"
which data files to read, right? How does your "program that generates code"
based on data files know what data files to read? I guess if it actually
reads and parses the makefile, it could put the information there without
duplication.
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.
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.
> 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?
--
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:
> 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.
Nope. I specified that you want to compile "main".
Look at my statement: "It's impossible to figure out from the source code
what other source files it depends on."
You're intentionally misinterpreting exactly what I'm saying, which is why I
put a *trivial* example in a separate post. You're standing here agreeing
that it's impossible to look at the source code and tell what depends on
what, because there's not enough information in the source code to determine
that. And now you're mocking me for pointing it out, in spite of the fact
that other systems don't seem to have this problem, because other systems
don't have bits and pieces of library source code compiled as part of the
process of compiling your own source code.
--
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:
> How do you resolve this? That's right: You tell the compiler which files
> it needs to compile.
Nope. You tell the compiler which *object* file goes with the appropriate
*source* file. Either they're all compiled together (in which case you
shouldn't be stupid enough to do that because it won't compile at all), or
one or the other is in a library, at which point you don't need to know
where the source code is or which one was actually used, because it's
already compiled.
Do you really not see the difference between saying "each time I compile
something, I have to pick which source file to compile" and saying "each
time I compile something, I have to pick the right source files that go with
the corresponding libraries of every library I'll eventually link this with"?
> Exactly how is this situation different from your example?
Because the object code of the file in question is used during the
compilation of your source code. Hence, the declarations and definitions are
united in one file, which is checksummed if distributed outside the project
to ensure what version you're using.
Indeed, when I use the C# equivalent of stdio (or any other third-party
library), I don't need any source code I didn't write myself, nor do I need
to specify where to find the libraries. I merely say which version of what
implementation I want.
> an inexistent flaw in C
I'm happy for you that this flaw has never bitten you in the butt. But it's
far from "inexistent." (Incidentally, the word would be "nonexistent".)
--
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:
> Exactly how is this situation different from your example?
Or, to phrase it a different way, compiling *your* C code can wind up
depending on the quality of the source code provided by every "pre-compiled"
library author whose code you're using. Not only does their library object
code have to work as advertised, but you have to recompile vital pieces of
it every time you compile your code.
I find this to be a disturbingly problematic lack of modularity in large
projects taking advantage of lots of pre-built code. And most other
languages don't really make you care what some third party's coding standard
is, as long as the library runs, because you don't get their source code.
Does that clarify the fundamental problem?
Or, look at it a different way, if you're *really* interested in pursuing
understanding what I'm saying: Why do you #include stdio in your program?
As you said, it's part of the standard. You can't change it without breaking
lots of programs. Also, you can't pick a different function to be called
"printf" without breaking any library that expects "printf" to mean the one
from stdio. (I.e., C's linker has a flat namespace, so if *anyone* includes
stdio, then the symbols from stdio will preclude using that name anywhere
else to mean something different.) So why does one have to recompile
stdio.h every time you compile a program?
I know the *technical* reason, as in "because that's how C works." I'm
asking you to try to understand why working that way is not as good as
simply telling the compiler you're using the standard library and symbols
come from there. You see the fact that you're recompiling bits and pieces of
the standard-mandated standard libraries (that you correctly acknowledge
can't be changed anyway) every single time you compile your program, yes?
And that doesn't sound like a strange idea?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/31/2011 11:18 AM, Warp wrote:
> Patrick Elliott<sel### [at] npgcablecom> wrote:
>> A project file is just another name for a MAKE file (at least
>> on Windows).
>
> Not according to Darren.
>
Well. Don't entirely disagree with his argument against headers and the
like either. Been down roads like that before. Only thing *worse* is
having done something like me, where I knew Basic, so got VB, but VB
didn't include the C headers, so even though I could look up, and use,
system calls that where not directly handled by the standard VB
functions, there was no "documentation", as such, in any book, manual,
or help file, for *any* of the flags. The books might tell you what the
flag name was, but they *assumed* you would be doing this in VC++, and
that you would include the headers for that library, and that, thus, the
compiler would take care of figuring out what they flag's value actually
was. :p
Almost as insane as trying, on the Apple IIGS to write working menu in
PASCAL, using a book showing the flags for C, without any mention in
either the PASCAL help files, or the book, that PASCAL would muck with
the numbers, on some way, resulting in the wrong parameters, so nothing
you could do would *ever* work, if you used the values. Interestingly,
**that** book actually told you what the frak the values for the flag
you might use in each system call where, rather than relying on the
headers to do it. Microsoft's various "Blah API Bible" books came as a
nasty shock when I got one. lol
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Patrick Elliott <sel### [at] npgcablecom> wrote:
>> A project file is just another name for a MAKE file (at least
>> on Windows).
>
> Not according to Darren.
Incidentally, it's comments like this that convince me that trying to
explain my point of view to you is usually useless. Given that I wrote an
extensive message detailing why I thought this which you apparently ignored.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > How would you enhance the whole makefile process so that it *would*
> > conform to your needs?
> I already gave several examples of this as well.
You mentioned some XML file format used by XNA. You want built-in support
in 'make' for that format?
> >> 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?
> I've given several examples of how to do this.
By adding built-in support for every single such format in existence to
'make'?
All your examples are of the type "I'm doing a project in [some IDE]
and there are some [IDE-specific] resources and, surprise surprise, the
IDE has support for automatically tracking the dependencies of those
resources". You have not given any *generic* answer to the question, only
very *specific* ones.
> > What happens if you have a custom format which has similar kinds of
> > dependencies? How do you expect it to work then?
> I've given several examples of how to do this.
I don't remember a single one. You just talked about some XML files which
are specific to XNA.
> > You still can't get over the fact that 'make' is a generic tool.
> Oddly enough, so are many of the other build systems that nevertheless don't
> require you to list dependencies in multiple places. Several examples of
> which I have already given.
You seem to be obsessed now with the "dependencies in multiple places"
thing, yet when I ask where exactly is the duplication in the example
I gave, you don't answer.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Patrick Elliott <sel### [at] npgcablecom> wrote:
> >> A project file is just another name for a MAKE file (at least
> >> on Windows).
> >
> > Not according to Darren.
> Incidentally, it's comments like this that convince me that trying to
> explain my point of view to you is usually useless. Given that I wrote an
> extensive message detailing why I thought this which you apparently ignored.
So what I wrote above is not false, yet it still somehow bad?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
