 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> 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.
Yeah, huge difference.
> 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)
Are you saying that it's impossible to have a C# source file with the
same name in two different directories and which implement a class with
the same name?
What does the compiler do? Scan your entire hard drive to see if it
finds clashing class names, and refuses to compile if it does?
> 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"?
Not really. You have to specify which source files the program is
composed of. The compiler cannot read your mind. Your example of the same
C file being in two different directories is simply bogus. It has nothing
to do with C particularly.
> > 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.
And when I write C++, same thing. So what?
> > 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".)
"I have seen the same C file in multiple places, but I have never seen
the same C# file in multiple places, hence C is clearly the inferior
language." Yes, very convincing argumentation.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
