 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've got a couple of Unix questions...
#1: Consider the following:
~$ /usr/bin/time --format="%C\n%E wall time, %P CPU, %M KB maximum"
./Prog1
./Prog1
0:15.27 wall time, 89% CPU, 1608592 KB maximum
The program *actually* used about 400MB of RAM. So WTF is %M actually
measuring? Because it sure as hell isn't "maximum resident set size of
the process during its lifetime, measured in Kilobytes".
(Also, why do %D, %K and %X all return 0 for every program?)
More generally, how do I make time tell me HOW MUCH RAM WAS USED?
#2: You can compile a C++ program with
g++ program.c++
However, for reasons beyond my comprehension, the result is always named
"a.out". You can tediously fix this using the -o option. Alternatively,
you can write a makefile:
prog1: prog1.c++
g++ prog1.c++ -o prog1
prog2: prog2.c++
g++ prog2.c++ -o prog2
prog3: prog3.c++
g++ prog3.c++ -o prog3
Is there any way of automating this absurd tedium?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 27/01/2011 11:33, Invisible a écrit :
> I've got a couple of Unix questions...
>
>
> #1: Consider the following:
>
> ~$ /usr/bin/time --format="%C\n%E wall time, %P CPU, %M KB maximum"
> ./Prog1
> ./Prog1
> 0:15.27 wall time, 89% CPU, 1608592 KB maximum
>
> The program *actually* used about 400MB of RAM. So WTF is %M actually
> measuring? Because it sure as hell isn't "maximum resident set size of
> the process during its lifetime, measured in Kilobytes".
But there is more than 400MB of data in the RSS.
First, you have the program itself (what is the filesize ?)
Next, all the shared libraries (and their cascades).
And if 400MB is your malloc... there is also the function's stack to
allocate: calling a function with an array or a structure in C++ is
allowed, and if you do not push for a reference, you might get the value
copied on the stack...
Recursion in functions is another deepener.
>
> (Also, why do %D, %K and %X all return 0 for every program?)
15 seconds is a very short time. Also, even if supported on the command
line, the man page states:
"Not all resources are measured
by all versions of Unix, so some of the values might be reported
as zero. "
>
> More generally, how do I make time tell me HOW MUCH RAM WAS USED?
>
What is RAM used for ?
RSS is the answer, for program, lib & data.
>
>
> #2: You can compile a C++ program with
>
> g++ program.c++
>
> However, for reasons beyond my comprehension, the result is always named
> "a.out". You can tediously fix this using the -o option. Alternatively,
> you can write a makefile:
>
> prog1: prog1.c++
> g++ prog1.c++ -o prog1
>
> prog2: prog2.c++
> g++ prog2.c++ -o prog2
>
> prog3: prog3.c++
> g++ prog3.c++ -o prog3
>
> Is there any way of automating this absurd tedium?
Yes.
Use the target naming in your makefile's rules
(have a search about $* $< $> ... in make tutorial)
--
Software is like dirt - it costs time and money to change it and move it
around.<br/><br/>
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 0:15.27 wall time, 89% CPU, 1608592 KB maximum
>>
>> The program *actually* used about 400MB of RAM. So WTF is %M actually
>> measuring? Because it sure as hell isn't "maximum resident set size of
>> the process during its lifetime, measured in Kilobytes".
>
> But there is more than 400MB of data in the RSS.
> First, you have the program itself (what is the filesize ?)
> Next, all the shared libraries (and their cascades).
> And if 400MB is your malloc... there is also the function's stack to
> allocate: calling a function with an array or a structure in C++ is
> allowed, and if you do not push for a reference, you might get the value
> copied on the stack...
>
> Recursion in functions is another deepener.
I ran an interactive resource monitor while the program was running, and
saw that free memory decreased by 400MB while the program was running.
That's how I know it used roughly 400MB. (I don't know what it used it
*for*, but I would presume mostly heap space.)
If the figure reported ("1608592") really is in KB, that's 1.6GB - which
far exceeds the available physical memory. That can't be right.
If the figure is actually bytes, then that's 1.6MB - which is *still* wrong.
>> (Also, why do %D, %K and %X all return 0 for every program?)
>
> 15 seconds is a very short time.
It's several eternities for a computer.
> Also, even if supported on the command line, the man page states:
> "Not all resources are measured
> by all versions of Unix, so some of the values might be reported
> as zero. "
Right. So Linux doesn't suppose this information. That's OK.
>> More generally, how do I make time tell me HOW MUCH RAM WAS USED?
>
> What is RAM used for ?
> RSS is the answer, for program, lib& data.
Then why do the answers not match reality?
>> Is there any way of automating this absurd tedium?
>
> Yes.
> Use the target naming in your makefile's rules
> (have a search about $* $< $> ... in make tutorial)
I don't particularly want to spend three weeks reading through the
obtuse reference manual. It would be quicker to just keep typing this
stuff by hand. I just wondered whether somebody already happens to know
the answer to this (presumably) very common problem...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 27/01/2011 15:35, Invisible a écrit :
>> Use the target naming in your makefile's rules
>> (have a search about $* $< $> ... in make tutorial)
>
> I don't particularly want to spend three weeks reading through the
> obtuse reference manual. It would be quicker to just keep typing this
> stuff by hand. I just wondered whether somebody already happens to know
> the answer to this (presumably) very common problem...
Fish, eating, learning,... all that old metaphore.
here a little makefile for gnu-make, but YMMV, to generate png picture
from every dot file in the current directory.
I guess you can adapt it for your c++ compilation.
(hint: dot -o outputfile inputfile)
all: $(patsubst %.dot,%.png,$(wildcard *.dot))
.SUFFIXES: .dot .png
.dot.png:
dot -Tpng -o $@ $<
--
Software is like dirt - it costs time and money to change it and move it
around.<br/><br/>
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I don't particularly want to spend three weeks reading through the
>> obtuse reference manual. It would be quicker to just keep typing this
>> stuff by hand. I just wondered whether somebody already happens to know
>> the answer to this (presumably) very common problem...
>
> Fish, eating, learning,... all that old metaphore.
Well yes, if I was likely to use make ever again, learning how it works
might be beneficial. Since I'm most unlikely to ever touch it again...
it's rather a lot of effort for little benefit.
> here a little makefile for gnu-make, but YMMV, to generate png picture
> from every dot file in the current directory.
>
> I guess you can adapt it for your c++ compilation.
> (hint: dot -o outputfile inputfile)
> all: $(patsubst %.dot,%.png,$(wildcard *.dot))
>
> .SUFFIXES: .dot .png
> .dot.png:
> dot -Tpng -o $@ $<
Hmm, never mind. Apparently renaming all the *.c++ files to *.cpp
enables Make to automatically figure out what to do. Go figure.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> #2: You can compile a C++ program with
> g++ program.c++
> However, for reasons beyond my comprehension, the result is always named
> "a.out". You can tediously fix this using the -o option.
How else do you suggest the binary be named? "The same as the source
file" is not a good answer because there may be (and often is) more than
one source file. You can easily compile a multi-sourced program with
"g++ *.cc". The -o parameter exists to tell the compiler the name of
the binary.
Anyways, if you find yourself compiling the same program again and again,
that's exactly what makefiles are for, so you can simply write "make".
> Alternatively,
> you can write a makefile:
> prog1: prog1.c++
> g++ prog1.c++ -o prog1
> prog2: prog2.c++
> g++ prog2.c++ -o prog2
> prog3: prog3.c++
> g++ prog3.c++ -o prog3
> Is there any way of automating this absurd tedium?
A makefile is, basically, what other SDKs call a "project" file. You can
specify dependencies between files and rules on how to build files from
other files (the idea, as with "project" files in other SDKs, is that files
are built only if their source files change rather than every time).
Writing a makefile by hand can be somewhat tedious, but you only have
to do it once. (Also, like most "project" files, it has a lot of flexibility.
Makefiles are not exclusively used to compile programs, but can be used for
a lot of other things where files are created from other files, or simply
programs are run based on certain rules.)
Gnu make offers some shortcuts which you can use to abbreviate some things,
such as for example:
myprogram: source1.cc source2.cc source3.cc
g++ $^ -o $@
Of course that rule is incomplete in that if any of those source files
depends eg. on a header file, it won't take that into account (in other
words, if you change the header file, the program will not be recompiled).
If you simply want it to recompile the program every time you run make,
you can "trick" make to do it by giving a rule which is named differently
from the resulting file, and leaving the conditions out, like:
all:
g++ source1.cc source2.cc source3.cc -o myprogram
(This works because there is no file named 'all' in the current directory,
so make will try to "build" it by running the command. Since the command
doesn't create it, it will do so also the next time you run make, and so on.)
Of course this is good only if you really want to recompile everything
every time.
A full-fledged makefile would build object files from each single source
file, and then link those object files into the final binary. This allows
compiling only those object files that really need it, so if there are
many source files, it will speed up compilation.
Of course the rules for this to work become very complicated, and nobody
in their right minds would write them by hand. There exist tools to
automatically create a makefile from a bunch of source files (think
automake is such a tool), or you could use gnu make in conjunction with
gcc's dependency-generation features to do it with them. I use this
generic makefile a lot for this exact purpose. Simply add it inside the
directory where your source files are, and 'make' will do the rest. (The
only defect is that if dependencies change, this will not notice it. You'll
have to remove the .dep file and it will start working again.)
#------------------------------------------------------------
# List source files (not headers!) and binary name:
SOURCES=$(wildcard *.cc)
BINARY=programname
# Set up compiler and compiler options:
CXX=g++
LD=g++
CXXFLAGS=-Wall -Wextra -pedantic -ansi -O3
LDFLAGS=-s
LDLIBS=
# --- No need to modify anything below this line ---
all: .dep $(BINARY)
$(BINARY): $(SOURCES:.cc=.o)
$(LD) $^ -o $@ $(LDFLAGS) $(LDLIBS)
clean:
rm -f .dep $(BINARY) $(SOURCES:.cc=.o)
.dep:
g++ -MM $(SOURCES) > .dep
-include .dep
#------------------------------------------------------------
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/01/2011 03:26 PM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> #2: You can compile a C++ program with
>
>> g++ program.c++
>
>> However, for reasons beyond my comprehension, the result is always named
>> "a.out". You can tediously fix this using the -o option.
>
> How else do you suggest the binary be named? "The same as the source
> file" is not a good answer because there may be (and often is) more than
> one source file. You can easily compile a multi-sourced program with
> "g++ *.cc". The -o parameter exists to tell the compiler the name of
> the binary.
I still don't see why it couldn't default to the name of the source file
for the common case where only one is supplied, but anyway...
> Anyways, if you find yourself compiling the same program again and again,
> that's exactly what makefiles are for, so you can simply write "make".
> A makefile is, basically, what other SDKs call a "project" file. You can
> specify dependencies between files and rules on how to build files from
> other files (the idea, as with "project" files in other SDKs, is that files
> are built only if their source files change rather than every time).
Yes, I know what Make does and why that's useful. It's just that for
what I'm trying to do, it's overkill. All I want to do is be able to
quickly recompile a program each time I edit the source, without having
to type in long complex commands.
> Writing a makefile by hand can be somewhat tedious, but you only have
> to do it once.
...except that every time I add another program, I end up having to add
another line to the Makefile to handle it.
I've got half a dozen trivial little C++ programs, and I want to be able
to quickly recompile any of them. It's frustrating me that it's this
difficult to do something so trivial.
The solution, as I just discovered, is to name the files *.cpp rather
than *.c++; this apparently enables Make's implicit rules to fire. (I
thought *.c++ was one of the "recognised" names, but apparently not...)
> (This works because there is no file named 'all' in the current directory,
> so make will try to "build" it by running the command. Since the command
> doesn't create it, it will do so also the next time you run make, and so on.)
...or you could just mark "all" as a phony target. (Yes, I read that
far. I've actually got a "clean" target in my Makefile, for example...)
> A full-fledged makefile would build object files from each single source
> file, and then link those object files into the final binary. This allows
> compiling only those object files that really need it, so if there are
> many source files, it will speed up compilation.
>
> Of course the rules for this to work become very complicated, and nobody
> in their right minds would write them by hand. There exist tools to
> automatically create a makefile from a bunch of source files
...which is all very interesting, but overkill for what I'm trying to do.
I've played with things like the Makefile for GHC, which supports
compiling the compiler, compiling the compiler with the compiler you
just compiled, running the test suite, building the user manual,
building the library documents, running the standard benchmark set, and
polishing your shoes for you. It's neat that you can do all that, but
it's far beyond my simple needs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> The solution, as I just discovered, is to name the files *.cpp rather
> than *.c++; this apparently enables Make's implicit rules to fire.
Not a good solution because you are not getting warnings nor
optimizations.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I still don't see why it couldn't default to the name of the source file
> for the common case where only one is supplied, but anyway...
It could. It doesn't.
> quickly recompile a program each time I edit the source, without having
> to type in long complex commands.
That's what !! or the up arrow key is for. Lacking that, that's what a shell
script is for. If your program consists of a single file, you don't need
Make at all.
>> Writing a makefile by hand can be somewhat tedious, but you only have
>> to do it once.
>
> ...except that every time I add another program, I end up having to add
> another line to the Makefile to handle it.
No you don't. That's what wildcards are for.
> I've got half a dozen trivial little C++ programs, and I want to be able
> to quickly recompile any of them. It's frustrating me that it's this
> difficult to do something so trivial.
It's a one-line shell script to recompile every .c++ file into the
corresponding executable file name.
>> Of course the rules for this to work become very complicated, and
>> nobody
>> in their right minds would write them by hand. There exist tools to
>> automatically create a makefile from a bunch of source files
Actually, the primary problem with makefiles is actually C's bizarre
#include rules, where source files depend on other source files which aren't
evident from looking at the source files.
--
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:
> Actually, the primary problem with makefiles is actually C's bizarre
> #include rules, where source files depend on other source files which aren't
> evident from looking at the source files.
Never miss a chance to belittle C-like languages.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Actually, the primary problem with makefiles is actually C's bizarre
>> #include rules, where source files depend on other source files which aren't
>> evident from looking at the source files.
>
> Never miss a chance to belittle C-like languages.
I'm not. I'm just pointing out why Make is so baroque. The fact that all the
stuff in the makefile is something you can't automate, and which in practice
you wide up actually having to compile everything twice, the first time just
to create the makefile.
Even *you* have to admit that nested #include files located solely via
environment variables is not the best way to manage type information at
compile time.
--
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:
>> Actually, the primary problem with makefiles is actually C's bizarre
>> #include rules, where source files depend on other source files which aren't
>> evident from looking at the source files.
>
> Never miss a chance to belittle C-like languages.
How come C is the only language from the 1970s that you get upset at my
pointing out technology-induced limitations? When someone asked why the C
standard limited global names to six characters and I said it was because of
FORTRAN-based linkers, you didn't seem to mind. You don't seem to object
when people make fun of COBOL's wordiness.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron wrote:
> here a little makefile for gnu-make, but YMMV, to generate png picture
> from every dot file in the current directory.
Does anyone really do this as part of a production system, btw? I've often
seen people claim "Make is good because you can compile things other than
code with it", but I've never actually seen a makefile that does anything
sophisticated like that. Does anyone actually work on a code base that (say)
invokes ImageMagik or some audio converter or some CD layout program or
something like that as part of their product and *does* use Make for it?
--
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 28/01/2011 04:44 PM, Darren New wrote:
> Does anyone really do this as part of a production system, btw? I've
> often seen people claim "Make is good because you can compile things
> other than code with it", but I've never actually seen a makefile that
> does anything sophisticated like that. Does anyone actually work on a
> code base that (say) invokes ImageMagik or some audio converter or some
> CD layout program or something like that as part of their product and
> *does* use Make for it?
GHC uses Make to invoke the tools for generating various documentation
files, running the test programs and benchmarks, and so forth. That's
the closest example I can think of off the top of my head...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> GHC uses Make to invoke the tools for generating various documentation
> files, running the test programs and benchmarks, and so forth. That's
> the closest example I can think of off the top of my head...
Fair enough. Now that you mention it, I remember seeing a "test" target in
many makefiles.
But here's a question: Does it only regenerate the pages of documentation
for the files where the source of the documentation has changed? Does it
only re-run test cases for code that has been recompiled since it last ran
test cases? Or is it more like "this would be a shell script, but we already
have a makefile so we might as well put it in there"?
--
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:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Actually, the primary problem with makefiles is actually C's bizarre
> >> #include rules, where source files depend on other source files which aren't
> >> evident from looking at the source files.
> >
> > Never miss a chance to belittle C-like languages.
> I'm not. I'm just pointing out why Make is so baroque.
That claim doesn't make any sense. All IDE project files are like makefiles
(just with a different format). It's not like a makefile is somewhat special
and different from any project file.
> The fact that all the
> stuff in the makefile is something you can't automate,
What do you mean you can't automate? Of course you can. There are tons of
tools to automatically create makefiles (and makefile rules).
> and which in practice
> you wide up actually having to compile everything twice, the first time just
> to create the makefile.
You don't need to "compile" anything to create the makefile rules. You
simply need to run a subset of the C preprocessor in order to see what
includes what (this is, afaik, what gcc does when you run it with the -M
option). It's not like it's an extremely heavy operation.
Besides, you only have to create the rules once. If the dependencies
don't change, you don't need to create them every time you want to compile.
> Even *you* have to admit that nested #include files located solely via
> environment variables is not the best way to manage type information at
> compile time.
I didn't understand anything in that sentence.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Actually, the primary problem with makefiles is actually C's bizarre
> >> #include rules, where source files depend on other source files which aren't
> >> evident from looking at the source files.
> >
> > Never miss a chance to belittle C-like languages.
> How come C is the only language from the 1970s that you get upset at my
> pointing out technology-induced limitations?
It's not that you belittle it. It's the frequency with which you do it,
and the situations where you do it.
Just count your posts belittling eg. COBOL and the onces belittling C or
C++. I bet the difference is something like two orders of magnitude.
Also, in this particular case, what was the point? It did not add anything
relevant or interesting to the thread, nor did it answer the original
question.
I hate Java. Do you see me taking every opportunity to bash it?
I sometimes do it, but I don't remember doing it at every possible
opportunity.
> When someone asked why the C
> standard limited global names to six characters and I said it was because of
> FORTRAN-based linkers, you didn't seem to mind.
Perhaps because it was a relevant answer to a presented question?
> You don't seem to object
> when people make fun of COBOL's wordiness.
How many times has that happened, exactly?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> I'm not. I'm just pointing out why Make is so baroque.
>
> That claim doesn't make any sense. All IDE project files are like makefiles
> (just with a different format). It's not like a makefile is somewhat special
> and different from any project file.
There are lots of ways in which make is inferior to most of the other build
tools. For one, the only out-dated-ness information it tracks is file
timestamps. If you change environment variables, it fails. If you restore an
older version of an include file, it fails. If you change the source file
then accidentally change the object file it fails. If you change a file your
compilation depends on that isn't listed as a dependency (like stdio.h say)
it fails.
>> The fact that all the
>> stuff in the makefile is something you can't automate,
>
> What do you mean you can't automate? Of course you can. There are tons of
> tools to automatically create makefiles (and makefile rules).
The existence of tools to generate a makefile is exactly the point I'm
making. At that point, you're no longer using Make. You have a makefile as
an intermediate step in your compilation. That's not automating something
with make. That's automating something with a makefile generator.
>> and which in practice
>> you wide up actually having to compile everything twice, the first time just
>> to create the makefile.
>
> You don't need to "compile" anything to create the makefile rules. You
> simply need to run a subset of the C preprocessor in order to see what
> includes what (this is, afaik, what gcc does when you run it with the -M
> option). It's not like it's an extremely heavy operation.
So you invoke the compiler to create the makefile. You're splitting hairs
here. If I can't easily create the makefile by looking at the source code
I'm trying to compile, it's baroque. :-)
> Besides, you only have to create the rules once. If the dependencies
> don't change, you don't need to create them every time you want to compile.
You have to create the rules every time you change anything that might
affect the compilation, whether that includes the .c file you're compiling
or not.
--
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:
>>> Darren New <dne### [at] sanrrcom> wrote:
>>>> Actually, the primary problem with makefiles is actually C's bizarre
>>>> #include rules, where source files depend on other source files which aren't
>>>> evident from looking at the source files.
>>> Never miss a chance to belittle C-like languages.
>
>> How come C is the only language from the 1970s that you get upset at my
>> pointing out technology-induced limitations?
>
> It's not that you belittle it. It's the frequency with which you do it,
> and the situations where you do it.
It's the only language from that time that's still in popular use. :-)
Besides, I thought you don't like C either.
> Just count your posts belittling eg. COBOL and the onces belittling C or
> C++. I bet the difference is something like two orders of magnitude.
Sure. Now count the number of posts talking about COBOL vs talking about
C++. Heck, we even have a whole newsgroup about C++. ;-)
> Also, in this particular case, what was the point? It did not add anything
> relevant or interesting to the thread, nor did it answer the original
> question.
Sorry you didn't understand the point. The point is that most of the other
languages out there don't have the sort of nested include behavior that C
has, and hence don't need makefiles that are anything more than simply the
list of source files that compile into each object library or executable.
In C# for example, the equivalent of the makefile says "here's the source
files to compile. Here's the name of the DLL to create. Here's the global
DLLs to link against (specified by content, not path). Here's the list of
makefiles for other possibly-uncompiled sources I depend on. Here's the
#define symbols to define and other compiler options." There's no list of
chunks of source code unrelated to the object code that this compilation
depends on. There's no big long list of which libraries link against other
libraries, or what order to search them in, or what order to compile things
in, or which source files use which types, or a 5000-character long compile
line specifying the source code locations of every declaration used anywhere
in your program. (And yes, I've had individual makefile compilation lines
that spanned several pages.)
And it deals with stuff that isn't compiled yet (since the reference to some
other object file that might need compilation actually points that the
equivalent of the *makefile* and not the equivalent of the DLL), and it
deals with object code that has changed but still has an older date (like
reverting a subversion repository), and it deals with changes in compilation
(like changing #define values between compilations), and it deals with
standard object files being updated or moved, all of which need external
tools for make.
Basically, the *interesting* problems, Make can't handle, which is why you
see qmake cmake ant autoconf and so on. The problem of specifying the list
of dependencies is trivial in compiled languages that don't have nested
source files: the object file depends on the source, the library depends on
all the object files.
The problem that Make solves is letting you manually specify which nested
#include files that might change but aren't easily found affect the
compilation of this program. Every other change that affects the compilation
of this program, Make can't handle. Hence, Make really doesn't make sense
for languages other than those whose dependencies aren't trivially deducible
by looking at the code.
> (this is, afaik, what gcc does when you run it with the -M option)
BTW, why not just build this into the compiler? Then you wouldn't need
makefiles. You'd have a three-line shell script: "compile everything that
needs compiling. If the library is older than any of the object files, put
the object files into a temp library file. Replace the existing library file
if it's different from the temp library file."
> I hate Java. Do you see me taking every opportunity to bash it?
> I sometimes do it, but I don't remember doing it at every possible
> opportunity.
I don't do it in every possible situation either. I do it when people are
talking about the difficulty of using a tool designed to compensate for
limitations built into old programming languages.
>> When someone asked why the C
>> standard limited global names to six characters and I said it was because of
>> FORTRAN-based linkers, you didn't seem to mind.
>
> Perhaps because it was a relevant answer to a presented question?
Sure. As was this.
>> You don't seem to object
>> when people make fun of COBOL's wordiness.
>
> How many times has that happened, exactly?
At least a couple times. :-)
--
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:
> If you change environment variables, it fails.
I'm not exactly sure which environment variables a compiler depends on
which would affect the compilation process. Usually command-line arguments
(to the compiler) are used to affect the compilation.
Well, I suppose you could make the makefile use some environment variables
to affect the compilation. Seems rather contrived and counter-productive
(because you are now putting part of your project settings outside of your
"project file", which is usually were they should be).
If you want changes to the makefile itself cause everything to be
recompiled, you could add the makefile to the dependency rules.
> If you restore an
> older version of an include file, it fails.
I'm pretty certain most IDEs don't eg. calculate checksums of every single
source file to see if they have changed from the last time that it was
compiled. In a project with thousands of files it could take a while to
calculate checksums for all of them.
> If you change the source file
> then accidentally change the object file it fails.
Yeah, and if you accidentally delete the makefile, it also fails. Duh.
There are like a million scenarios where you accidentally do something to
your files which will cause a malfunction (regardless of your IDE).
> If you change a file your
> compilation depends on that isn't listed as a dependency (like stdio.h say)
> it fails.
And if you don't specify any dependencies at all, it will also fail, duh.
Of course the makefile assumes that you have specified all the necessary
dependencies. It cannot read your mind.
If you are using a tool to create the dependency lists and that tool
fails for some reason, blame the tool, not make.
> >> The fact that all the
> >> stuff in the makefile is something you can't automate,
> >
> > What do you mean you can't automate? Of course you can. There are tons of
> > tools to automatically create makefiles (and makefile rules).
> The existence of tools to generate a makefile is exactly the point I'm
> making. At that point, you're no longer using Make. You have a makefile as
> an intermediate step in your compilation. That's not automating something
> with make. That's automating something with a makefile generator.
I'm sure you are pretty well aware of the unix philosophy that tasks are
often distributed among separate tools, rather than having one single program
that tries to do everything.
There's nothing wrong in using two tools to perform a task rather than
one. Do you also blame 'ls' for not supporting everything that 'sed'
supports?
'make' is not used only to compile C/C++ programs. It can be used for
quite many tasks, including things that have nothing to do with compiling
a program. 'make' is designed to be a versatile tool for these tasks.
Many IDEs also support this, but they aglomerate everything into one
single program. That's just not the typical unix ideology.
> >> and which in practice
> >> you wide up actually having to compile everything twice, the first time just
> >> to create the makefile.
> >
> > You don't need to "compile" anything to create the makefile rules. You
> > simply need to run a subset of the C preprocessor in order to see what
> > includes what (this is, afaik, what gcc does when you run it with the -M
> > option). It's not like it's an extremely heavy operation.
> So you invoke the compiler to create the makefile. You're splitting hairs
> here.
I'm not. gcc does not "compile" the program when I run it with the -M
parameter. It just runs a simplified C preprocessor to track all the
included files. The major difference is, obviously, speed.
> If I can't easily create the makefile by looking at the source code
> I'm trying to compile, it's baroque. :-)
I just can't see what's so wrong in using a tool to create the makefile
dependency rules. Do you really *want* to be writing makefiles by hand?
> > Besides, you only have to create the rules once. If the dependencies
> > don't change, you don't need to create them every time you want to compile.
> You have to create the rules every time you change anything that might
> affect the compilation, whether that includes the .c file you're compiling
> or not.
Generating the rules is pretty fast, and the need doesn't present itself
very often, and re-generating the rules is quite easy. I just can't see
the problem here.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> > Also, in this particular case, what was the point? It did not add anything
> > relevant or interesting to the thread, nor did it answer the original
> > question.
> Sorry you didn't understand the point. The point is that most of the other
> languages out there don't have the sort of nested include behavior that C
> has, and hence don't need makefiles that are anything more than simply the
> list of source files that compile into each object library or executable.
Firstly, that doesn't answer the original question. It's not like Andrew
was making a choice of programming language for his next project. He just
wanted an easy way to compile a bunch of programs. Your answer doesn't help
his problem in any way.
Secondly, what is it exactly that allows other languages to compile only
what has changed, rather than everything every time? Right: The compiler
keeps track of changed files and compiles only what has changed.
In a unix system this tracking has been separated into its own set of
tools, rather than being part of the compiler. *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.
Well, if you don't like it, then don't. It's just how the unix ideology is.
You might disagree with the ideology and argue how it's antiquated, but it's
not something that bothers everybody. Some people like one tool doing one
thing, rather than one program trying to do everything.
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. You are just blaming the programming
language for it because you love to hate it.
> In C# for example, the equivalent of the makefile says "here's the source
> files to compile. Here's the name of the DLL to create. Here's the global
> DLLs to link against (specified by content, not path). Here's the list of
> makefiles for other possibly-uncompiled sources I depend on. Here's the
> #define symbols to define and other compiler options." There's no list of
> chunks of source code unrelated to the object code that this compilation
> depends on. There's no big long list of which libraries link against other
> libraries, or what order to search them in, or what order to compile things
> in, or which source files use which types, or a 5000-character long compile
> line specifying the source code locations of every declaration used anywhere
> in your program. (And yes, I've had individual makefile compilation lines
> that spanned several pages.)
Can you guess how many source code dependency definitions I have ever
written when I have used Microsoft's Visual C++ or Apple's Xcode?
That's right. You are putting the blame on the programming language,
when what really irks you are the unix compiling tools. You just love
to hate C, so you just can't miss an opportunity to bash it.
Yes, I hate C too, but I don't blame it for flaws that it doesn't have.
> > (this is, afaik, what gcc does when you run it with the -M option)
> BTW, why not just build this into the compiler? Then you wouldn't need
> makefiles.
Sometimes the dependencies are more complicated. For example you could
have a program in your project which generates code, which then gets
compiled into the actual executable. That code-generation program in turn
may depend on some input files from which it generates the code.
You only want to compile the code generating program if its source files
change. You only want to run that program if the data files change. You
only want to recompile your actual executable if either of those (or its
own source files) change.
Obviously a compiler cannot know all this if you simply give it a list
of all the source code files. It needs slightly more elaborate rules.
Most IDEs support creating these types of dependencies (eg. Xcode does,
Visual Studio probably does too, even though I have so far not needed to
do something like that with it). Obviously you can achieve this with a
makefile as well (after all, it's exactly what it is designed to do).
And yes, I have needed to do this, several times.
A makefile / project file can be quite useful even further. For example,
you could have a rule to create a distribution package from your program.
The creation of this distribution package ought to have dependencies on
all the files which need to be included. Hence if you eg. change one of
those data files and then build the distribution package, the executable
binary will be compiled first, so that it's up to date. You can't do this
with a simple shell script. (And yes, I also have needed to do this.)
> >> When someone asked why the C
> >> standard limited global names to six characters and I said it was because of
> >> FORTRAN-based linkers, you didn't seem to mind.
> >
> > Perhaps because it was a relevant answer to a presented question?
> Sure. As was this.
How did it answer the original question?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> If you change environment variables, it fails.
>
> I'm not exactly sure which environment variables a compiler depends on
> which would affect the compilation process. Usually command-line arguments
> (to the compiler) are used to affect the compilation.
http://www.gnu.org/software/hello/manual/make/Implicit-Variables.html#Implicit-Variables
Stuff like CFLAGS and LDFLAGS and LIBS and INCLUDEPATH, all of which tends
to come from outside the environment. Sure, you *can* get around it, but in
practice people don't.
> Well, I suppose you could make the makefile use some environment variables
> to affect the compilation. Seems rather contrived and counter-productive
> (because you are now putting part of your project settings outside of your
> "project file", which is usually were they should be).
>
> If you want changes to the makefile itself cause everything to be
> recompiled, you could add the makefile to the dependency rules.
Unless it's in a different project, sure. If you want your kernel module to
recompile any time the C runtime library or the different bits of the kernel
it depends on changes, you have a bit of tracking down to do.
Besides, have you *ever* seen someone actually do this in a hand-generated
makefile?
>> If you restore an
>> older version of an include file, it fails.
>
> I'm pretty certain most IDEs don't eg. calculate checksums of every single
> source file to see if they have changed from the last time that it was
> compiled.
In languages where it's important to be correct, like Ada, yes they do. In
C#, yes they do, because they don't *look* at include files, they look at
object files. C# doesn't *have* include files. That's the point. If you say
"use the types from *that* assembly" and then later you replace the assembly
with an incompatible version, your code will get recompiled (or will refuse
to start if you try to run it without recompiling).
In Ada, you don't calculate the checksums of every source. You calculate the
checksum of the file you're compiling when you compile it. In C#, your file
is either associated with a project (i.e., with the equivalent of a
makefile) or it's installed in the global assembly cache with a version
number and a cryptographic checksum on it you can check against.
> In a project with thousands of files it could take a while to
> calculate checksums for all of them.
When it's important, you compile the header file separately, like in Ada.
That's my problem with the way C does #include. Ada header files aren't
chunks of arbitrary source code that you include nested in other chunks of
source code. Ada external type declarations aren't a byproduct of compiling
something unrelated to the type you're declaring. They're a separate piece
of code that can be version controlled and dependency analyzed on its own.
If you recompile a header file and don't recompile everything that depends
on it in Ada, your code won't link, regardless of date stamps.
>> If you change the source file
>> then accidentally change the object file it fails.
>
> Yeah, and if you accidentally delete the makefile, it also fails. Duh.
No, if you delete the makefile you get an error. If you touch the object
code after changing the source, you get a silent failure. There's a big
difference there.
> There are like a million scenarios where you accidentally do something to
> your files which will cause a malfunction (regardless of your IDE).
Sure. You're apparently trying to miss my point here, which is that the idea
that basing dependency information and content-change information solely on
file timestamps is iffy. Yes, there's a lot of ways to break code, but
those aren't relevant to the discussion we're having about Make. There
aren't a whole lot of scenarios where you accidentally do something to your
Ada code and wind up with an executable that doesn't match the sources you
compiled it from.
> Of course the makefile assumes that you have specified all the necessary
> dependencies. It cannot read your mind.
I have never seen a makefile that lists as a dependency of my code all the
things that stdio.h includes.
> If you are using a tool to create the dependency lists and that tool
> fails for some reason, blame the tool, not make.
If I'm using a tool to create makefiles, then sure, but that's just saying
makefiles are so useless that I have to automate their creation. Why would I
use a tool to create makefiles using a tool that just does the job properly?
> There's nothing wrong in using two tools to perform a task rather than
> one. Do you also blame 'ls' for not supporting everything that 'sed'
> supports?
There's really only one task going on here - dependency checking. That's the
one and only thing Make does.
> 'make' is not used only to compile C/C++ programs. It can be used for
> quite many tasks, including things that have nothing to do with compiling
> a program. 'make' is designed to be a versatile tool for these tasks.
That's what I asked earlier. I just never found anything that *actually*
uses the dependency analysis of make to build something other than C-like
code or libraries therefrom.
Do you have things in your makefile for processing the graphics for your
games? Does it only reprocess them only when the source graphics change?
It's not like "make test" only runs if you recompiled something (or, better,
only tests the modules you changed), or "make clean" doesn't delete *.o
instead of going through each file to see if it's there first.
> Many IDEs also support this, but they aglomerate everything into one
> single program.
Well, no, not really. In simple situations (like a directory full of Java
source), they just give it to the compiler to figure out, because the
compiler already knows all the dependencies. In complex situations, they
have to do more than just look at timestamps.
>> So you invoke the compiler to create the makefile. You're splitting hairs
>> here.
>
> I'm not. gcc does not "compile" the program when I run it with the -M
> parameter. It just runs a simplified C preprocessor to track all the
> included files. The major difference is, obviously, speed.
Sure. But you're invoking the compiler, and with the same sets of
command-line options and environment variable expansions as when you do the
full compilation.
I'm sorry, but if anyone in the world asked me "how do I invoke the gcc
compiler", I'd say "use /usr/bin/gcc" or something. I would *not* add "but
be careful not to pass the -M flag, because that doesn't invoke the compiler."
The point is that you're using C-specific code written by the same people
who wrote the compiler to figure out what the C-specific dependencies are.
The speed is irrelevant. What's relevant is that the C nested includes are
sufficiently complex that you need a tool to generate the input to the next
tool, where the "next tool" was supposed to stand alone on its own in
simpler times. In more complex times, the stand-alone tool is mostly
useless. We have gotten to the point where any time "make" saves you enough
compilation time to be worthwhile, generating the makefiles is too complex
to be easily maintainable. Make lives on not because it's good, but because
it's as ubiquitous as C. But environments that don't use C don't use make
either, because it's just not a very good tool.
>> If I can't easily create the makefile by looking at the source code
>> I'm trying to compile, it's baroque. :-)
>
> I just can't see what's so wrong in using a tool to create the makefile
> dependency rules. Do you really *want* to be writing makefiles by hand?
I have no trouble at all writing makefile rules by hand when it's *not* C
that I'm compiling. That's exactly my point. C's dependencies are
sufficiently opaque that it's actually problematic just to figure out what
they are, to the point where one feels the need to actually write a number
of tools to figure it out, including modifying the compiler to help you out.
But even back in the MS-DOS 3 days, I was writing editor macros to suck
#include declarations out of C sources to generate makefiles, simply because
of the need for *correctness* rather than complexity.
>>> Besides, you only have to create the rules once. If the dependencies
>>> don't change, you don't need to create them every time you want to compile.
>
>> You have to create the rules every time you change anything that might
>> affect the compilation, whether that includes the .c file you're compiling
>> or not.
>
> Generating the rules is pretty fast, and the need doesn't present itself
> very often, and re-generating the rules is quite easy. I just can't see
> the problem here.
Regenerating the rules is only quite easy because someone added a flag to
GCC to make it regenerate the rules. Now, go regenerate the rules without
the -M flag. I'm not saying that generating the dependencies, *today*, isn't
easy. I'm saying that the job Make was created to handle, namely recording
and evaluating dependencies, is obsolete. Makefile dependency lists are, for
the most part, created by other tools, and they're inadequate to actually
capture all the dependencies that people have in modern code. It was a fine
tool back when you had a dozen C files and a half-dozen include files in
your project, and your choice was whether you wanted the compiler to
optimize or not. Nowadays,
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
http://www.boost.org/doc/libs/1_45_0/libs/config/doc/html/boost_config/rationale.html#boost_config.rationale.the_problem
You're arguing that the dependency rules for C's #include directive isn't
complicated because the compiler can figure it out for you. In your words,
"well, duh." That doesn't make the rules easy. It just means that the
complexity is encapsulated in the compiler. And that means if you're
compiling a different language with different dependency rules, the sorts of
things Make does just aren't the best way of doing it. C# needs something
more than timestamps to determine dependencies. Java doesn't need makefiles
at all for the code itself. Ada needs a completely different process, not
infrequently involving a database. All the interpreted languages have their
own thing going on.
(It also ignores the fact that you have to figure such crap out when you
write the code, too. I mean, really, three #include files to invoke "open"?
How would you even guess what include files the various #defines were in if
it wasn't a system library documented all over the place? It's entirely
possible for someone to give you a blob of source code and you have no way
of even knowing how to correctly generate the dependencies from it: for
example, it wasn't unusual at the last place to have a bunch of different
include files with different values for the same #define in different
directories, and spend a couple days trying to figure out which include path
to use to get it to link correctly against the pre-compiled libraries also
included. But that's also due to the nature of not putting type information
into object code files as much as #include per se.)
--
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:
>> 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! :-)
I have explained it numerous times, with specific examples and general
descriptions, so I'm going to assume it's one of those things you just won't
ever understand. I think sometimes you fail to understand things that you
disagree with.
> Firstly, that doesn't answer the original question. It's not like Andrew
> was making a choice of programming language for his next project. He just
> wanted an easy way to compile a bunch of programs. Your answer doesn't help
> his problem in any way.
It does. "Make is not appropriate for your task." :-)
Granted, the conversation has progressed since then. But the basic comment
was "by the time you need make, make will be inadequate to the task." Then I
explained why, which is what we're arguing about now.
> Secondly, what is it exactly that allows other languages to compile only
> what has changed, rather than everything every time? Right: The compiler
> keeps track of changed files and compiles only what has changed.
Sometimes. Other times, not. When it *is* the compiler doing it, it's using
a dependency analysis more sophisticated than just file timestamps, which is
all that make supports.
> In a unix system this tracking has been separated into its own set of
> tools, rather than being part of the compiler.
Except for, you know, that pesky -M switch. That's what I'm talking about.
The tracking *is* built into the compiler. It would be a pain in the butt to
use make to track dependencies without it being built into the compiler.
> *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.
> Well, if you don't like it, then don't.
And *that*, my friend, is how this discussion started. 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. :-)
> 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.
> That's right. You are putting the blame on the programming language,
> when what really irks you are the unix compiling tools.
We were talking about make. I said "make was designed to deal with C's
#include mess." The fact that there are other tools that deal with C's
#include mess better than make does doesn't mean C's #include mess is less
messy, nor does it mean that make is the right tool for dealing with other
dependency issues. Which is what we're discussing.
> You just love
> to hate C, so you just can't miss an opportunity to bash it.
I actually like C. It just has a number of legacy flaws, one of which is
using #include instead of having actual compiled declarations stored anywhere.
> Obviously a compiler cannot know all this if you simply give it a list
> of all the source code files. It needs slightly more elaborate rules.
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. (At least, not without
writing the -M equivalent for your personal processors and remembering to
run it when you change the list of frames.)
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."
Maybe it's just because every single makefile I've ever seen in my entire
life really, really sucks and doesn't work right either that I'm down on make.
--
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:
> The issue was the #include scheme, which you seem to hate and I really
> can't understand why.
Let's see if I can express it simply and clearly enough:
1) Every source file should generate object code when compiled. In other
words, declarations should generate output when you pass them to the
compiler. Not necessarily *executable* statements, mind, but some sort of .o
file.
2) It should be possible to deduce from object code what types that object
code implements, without reference to the source code, well enough to
determine if two object files can inter-operate (i.e., can be correctly
linked together). This implies that linking incompatible compilations of the
same type can also be noticed - i.e., if the caller passes packed structures
to a callee that expects unpacked structures, this should be caught.
When you're lacking property #1, there's no clear and obvious "type" in your
system. All you have is declarations which may or may not have been changed
and which may or may not match your definitions. (Otherwise, people would
not need to be encouraged to include xyz.h in their xyz.c file.)
C lacks property #1, which leads to #include files because manually
repeating the code is too error-prone. This leads to the need to track
dependencies between source files that come from different authors.
Without property #1, a consumer of a C-enabled library has to track
dependencies on *source* code written by the provider of the library, and
that *source* code is (by the time it's on the consumer's machine) unrelated
in any way to the library code the consumer is trying to consume. I.e.,
there's no practical way for the consumer to use the library without a .h
file, but that .h file is not part of the actual library code that gets
deployed. It's entirely possible that the .h source code doesn't match the
.o/.lib code you wind up linking against.
When you're lacking property #2, you not only need to have the object code
library, but you need to know how to compile your code to make it work with
that object code library. So now you have three things to harmonize: the .h
file for the library, the .so file for the library, and the compile-time
arguments for the library, and you have to pick compile time arguments for
your own compilation that are compatible.
Most implementations of C also lack property #2, which means you actually
have to track down the correct library source code and compilation options
to use an already-compiled library. Interestingly enough, one of the
criticisms of C++ is that each compiler tends to implement (to the extent it
does) property #2 somewhat differently.
In other words, with #includes, using a library means you have to figure out
how to correctly compile someone else's code, in an environment that the
library author never tried compiling in, just to invoke "already compiled" code.
Also:
In *shitty* code, the fact that #include's aren't restricted to type
declarations but rather can arbitrarily change the syntax of the language
you're using is also a problem. Languages should strive to make it difficult
to write shitty code, *especially* shitty code that makes people who write
*good* code have a harder job of it. Again, this isn't a problem where one
does not need to compile someone else's code in order to use pre-compiled code.
I hope that answers it. You may *disagree* it's a problem, but I hope you
understand it.
--
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/29/2011 1:21 PM, Darren New wrote:
> Warp wrote:
>>> I'm not. I'm just pointing out why Make is so baroque.
>>
>> That claim doesn't make any sense. All IDE project files are like
>> makefiles
>> (just with a different format). It's not like a makefile is somewhat
>> special
>> and different from any project file.
>
> There are lots of ways in which make is inferior to most of the other
> build tools. For one, the only out-dated-ness information it tracks is
> file timestamps. If you change environment variables, it fails. If you
> restore an older version of an include file, it fails. If you change the
> source file then accidentally change the object file it fails. If you
> change a file your compilation depends on that isn't listed as a
> dependency (like stdio.h say) it fails.
>
>>> The fact that all the stuff in the makefile is something you can't
>>> automate,
>>
>> What do you mean you can't automate? Of course you can. There are tons of
>> tools to automatically create makefiles (and makefile rules).
>
> The existence of tools to generate a makefile is exactly the point I'm
> making. At that point, you're no longer using Make. You have a makefile
> as an intermediate step in your compilation. That's not automating
> something with make. That's automating something with a makefile generator.
>
Yeash.. Remember a damn mess with some MUD I was trying to run at one
point. Only versions I could find pre-compiled for Windows all had ANSI
disabled, and, worse, unlike some newer ones, anything you did add had
to be compiled into the core. Makefile was for like VC++4.0, which
VC++5.0 didn't like, but I didn't even know that initially, because I
had to first find a copy of Bison for Windows, because the make file
made a make file, as one of its steps, along with a bunch of
libraries/changes, to compile under Windows, instead of *nix, and...
well, things just went increasingly bad from there.. lol
Trying to work out what went wrong, and why, from the damn code, and the
code that built the code, and the code that ran the code, that built the
code... o.O
--
void main () {
If Schrödingers_cat is alive or version > 98 {
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> Trying to work out what went wrong, and why, from the damn code, and the
> code that built the code, and the code that ran the code, that built the
> code... o.O
Precisely. When the configuration file to create the build tools is based on
turing-complete macro processing, you're gonna just be screwed if there's
anything wrong.
--
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:
> > I'm pretty certain most IDEs don't eg. calculate checksums of every single
> > source file to see if they have changed from the last time that it was
> > compiled.
> In languages where it's important to be correct, like Ada, yes they do. In
> C#, yes they do, because they don't *look* at include files, they look at
> object files. C# doesn't *have* include files. That's the point. If you say
> "use the types from *that* assembly" and then later you replace the assembly
> with an incompatible version, your code will get recompiled (or will refuse
> to start if you try to run it without recompiling).
> In Ada, you don't calculate the checksums of every source. You calculate the
> checksum of the file you're compiling when you compile it. In C#, your file
> is either associated with a project (i.e., with the equivalent of a
> makefile) or it's installed in the global assembly cache with a version
> number and a cryptographic checksum on it you can check against.
So if you have thousands of files in your project, the compiler will
calculate the checksums of every single one of them every time you want
to compile? And it was you who complained how creating makefile rules for
C files is inefficient... Right.
> >> If you change the source file
> >> then accidentally change the object file it fails.
> >
> > Yeah, and if you accidentally delete the makefile, it also fails. Duh.
> No, if you delete the makefile you get an error. If you touch the object
> code after changing the source, you get a silent failure. There's a big
> difference there.
Yeah, and if your hard drive dies, you also get a failure. Also a big
difference. I still don't get your point.
You talk as if accidentally touching an object file is a relatively
common happenstance. Well, in the fifteen or so years I have been using
makefiles, guess how many times that has happened to me. (In fact, a HD
dying has happened to be more often than that.)
> > There are like a million scenarios where you accidentally do something to
> > your files which will cause a malfunction (regardless of your IDE).
> Sure. You're apparently trying to miss my point here, which is that the idea
> that basing dependency information and content-change information solely on
> file timestamps is iffy.
The situations where it causes problem are so extremely rare that it just
isn't worth the price of the compiler calculating checksums of every single
file in the project every time you want to do a quick compile. Imagine that
every time you want to compile your project, you had to wait a minute for
the compiler to check all the checksums, when with the current scheme it
can do it in a few seconds.
Nevertheless, you are still blaming the programming language for a
defect you see in the compiling tools. All this has nothing to do with C.
> > Of course the makefile assumes that you have specified all the necessary
> > dependencies. It cannot read your mind.
> I have never seen a makefile that lists as a dependency of my code all the
> things that stdio.h includes.
And that makes it impossible to create such a makefile (especially if you
are using a dendepency-generation tool)?
Anyways, exactly why would you want to recompile your program if stdio.h
changes? You see, stdio.h is standardized, and if it was changed in such
way that programs would need to be recompiled for them to work, it would
mean that the C standard has been changed to be backwards-incompatible and
it would break basically all programs in existence.
Yeah, very likely to happen.
Even if stdio.h would be changed in a backwards-compatible way (eg. a
new non-standard function declaration is added) you would not need to
recompile any existing program. It would not affect them.
If you are making an extremely rare program which truly needs to be
recompiled every time stdio.h changes, the solution to this is rather
trivial.
> > If you are using a tool to create the dependency lists and that tool
> > fails for some reason, blame the tool, not make.
> If I'm using a tool to create makefiles, then sure, but that's just saying
> makefiles are so useless that I have to automate their creation. Why would I
> use a tool to create makefiles using a tool that just does the job properly?
You could make the same argument for any program that doesn't do everything,
and needs to work in conjunction with another program in order to perform
some task. Your argument is moot.
As for makefiles, not all things that can be done with makefiles can be
automated.
> > There's nothing wrong in using two tools to perform a task rather than
> > one. Do you also blame 'ls' for not supporting everything that 'sed'
> > supports?
> There's really only one task going on here - dependency checking. That's the
> one and only thing Make does.
Make can't know if eg. a code-generating program depends on some data
files unless you tell it.
> > 'make' is not used only to compile C/C++ programs. It can be used for
> > quite many tasks, including things that have nothing to do with compiling
> > a program. 'make' is designed to be a versatile tool for these tasks.
> That's what I asked earlier. I just never found anything that *actually*
> uses the dependency analysis of make to build something other than C-like
> code or libraries therefrom.
> Do you have things in your makefile for processing the graphics for your
> games? Does it only reprocess them only when the source graphics change?
I gave an example in my other post of an actual project I have been
working in where makefiles are useful for something else besides purely
compiling C++.
> >> So you invoke the compiler to create the makefile. You're splitting hairs
> >> here.
> >
> > I'm not. gcc does not "compile" the program when I run it with the -M
> > parameter. It just runs a simplified C preprocessor to track all the
> > included files. The major difference is, obviously, speed.
> Sure. But you're invoking the compiler, and with the same sets of
> command-line options and environment variable expansions as when you do the
> full compilation.
> I'm sorry, but if anyone in the world asked me "how do I invoke the gcc
> compiler", I'd say "use /usr/bin/gcc" or something. I would *not* add "but
> be careful not to pass the -M flag, because that doesn't invoke the compiler."
Actually I'm invoking the C preprocessor. I could call it directly, but
gcc does it automatically when you specify the -M parameter. The calls
"gcc -M test.cc" and "cpp -M test.cc" produce the exact same result.
I could simply use the latter if I wanted to be pedantic.
> The point is that you're using C-specific code written by the same people
> who wrote the compiler to figure out what the C-specific dependencies are.
> The speed is irrelevant. What's relevant is that the C nested includes are
> sufficiently complex that you need a tool to generate the input to the next
> tool, where the "next tool" was supposed to stand alone on its own in
> simpler times. In more complex times, the stand-alone tool is mostly
> useless. We have gotten to the point where any time "make" saves you enough
> compilation time to be worthwhile, generating the makefiles is too complex
> to be easily maintainable. Make lives on not because it's good, but because
> it's as ubiquitous as C. But environments that don't use C don't use make
> either, because it's just not a very good tool.
Instead, we have "project files" in IDEs which do... what? Well, exactly
the same thing as makefiles. In fact, "project files" are just makefiles,
using some other IDE-specific syntax. (They might have features that 'make'
doesn't support, but in principle they are the same thing.)
Yes, you can use project files for things other than purely compiling
the program, such as running command-line tools to build data files and
such. Exactly what makefiles do. (And yes, I have done this at least with
Xcode project files.)
The only difference is that most IDEs generate the dependency rules for
source code files automatically so you don't have to write the few magic
lines into the project file yourself. However, again, in principle it's
no different from a generic makefile that generates dependency rules
automatically (like the one I pasted in an earlier post).
> >> If I can't easily create the makefile by looking at the source code
> >> I'm trying to compile, it's baroque. :-)
> >
> > I just can't see what's so wrong in using a tool to create the makefile
> > dependency rules. Do you really *want* to be writing makefiles by hand?
> I have no trouble at all writing makefile rules by hand when it's *not* C
> that I'm compiling. That's exactly my point. C's dependencies are
> sufficiently opaque that it's actually problematic just to figure out what
> they are, to the point where one feels the need to actually write a number
> of tools to figure it out, including modifying the compiler to help you out.
You still can't get past the fact that in unix different tasks are
separated into different tools. Fine, you hate that. Move on.
> > Generating the rules is pretty fast, and the need doesn't present itself
> > very often, and re-generating the rules is quite easy. I just can't see
> > the problem here.
> Regenerating the rules is only quite easy because someone added a flag to
> GCC to make it regenerate the rules.
Actually to the C preprocessor.
> Now, go regenerate the rules without
> the -M flag.
And why exactly would I want to do that? You might as well ask "compile
the program without using the compiler".
> I'm not saying that generating the dependencies, *today*, isn't
> easy. I'm saying that the job Make was created to handle, namely recording
> and evaluating dependencies, is obsolete.
And how do you propose to handle dependencies on things that the compiler
does not handle, such as creating data files from some input files using
some tools (and perhaps recompile the program only if those data files
change)?
> Makefile dependency lists are, for
> the most part, created by other tools
Only program source code dependencies. If you have other types of
dependencies you still need to specify them by hand because no automated
tool can read your mind.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> I have explained it numerous times, with specific examples and general
> descriptions, so I'm going to assume it's one of those things you just won't
> ever understand. I think sometimes you fail to understand things that you
> disagree with.
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.
> > Firstly, that doesn't answer the original question. It's not like Andrew
> > was making a choice of programming language for his next project. He just
> > wanted an easy way to compile a bunch of programs. Your answer doesn't help
> > his problem in any way.
> It does. "Make is not appropriate for your task." :-)
> Granted, the conversation has progressed since then. But the basic comment
> was "by the time you need make, make will be inadequate to the task." Then I
> explained why, which is what we're arguing about now.
And which tool, exactly, did you recommend instead? I remember you
mentioning shell scripts. Yeah, those can track dependencies just fine.
> > In a unix system this tracking has been separated into its own set of
> > tools, rather than being part of the compiler.
> Except for, you know, that pesky -M switch. That's what I'm talking about.
> The tracking *is* built into the compiler. It would be a pain in the butt to
> use make to track dependencies without it being built into the compiler.
It's actually in the C preprocessor, which is a separate tool.
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.
> > *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.
> > 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.
> 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 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. 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.
Which tool incorrectly figures out the dependencies?
Why does it feel that you are desperately trying to pile up more and more
perceived problems to the issue?
> > 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.
> > Obviously a compiler cannot know all this if you simply give it a list
> > of all the source code files. It needs slightly more elaborate rules.
> 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, which was exactly
my point (and exactly why I'm comparing it to the "project files" of other
IDEs).
You seem to be desperately trying to find flaws that just aren't there.
Maybe what irks you is that with makefiles you need to write a bit more
syntax to get the same effect.
> 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Patrick Elliott wrote:
> > Trying to work out what went wrong, and why, from the damn code, and the
> > code that built the code, and the code that ran the code, that built the
> > code... o.O
> Precisely. When the configuration file to create the build tools is based on
> turing-complete macro processing, you're gonna just be screwed if there's
> anything wrong.
So let me get this straight: He was trying to compile a program with
Visual C++, the project did not have a Visual C++ project file, he was
trying to compile it in Windows which is not Unix and hence does not use
the same core tools, and consequently he had big problems in compiling
the program. Yet this is still somehow a problem with makefiles.
It seems to me that anybody could make a post with any random problem
they had, and if a makefile was somehow involved, you would immediately
rush to agree with a "precisely!" answer regardless of what was the real
cause of the problem.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> In Ada, you don't calculate the checksums of every source. You calculate the
>> checksum of the file you're compiling when you compile it. In C#, your file
>> is either associated with a project (i.e., with the equivalent of a
>> makefile) or it's installed in the global assembly cache with a version
>> number and a cryptographic checksum on it you can check against.
>
> So if you have thousands of files in your project, the compiler will
> calculate the checksums of every single one of them every time you want
> to compile? And it was you who complained how creating makefile rules for
> C files is inefficient... Right.
Read the second sentence again. You calculate the checksum of the file when
you compile it. You then store that in the object code.
If you have library A and B, and program C that uses them, then you compile
the headers for A and B, generating two checksums in the object code. Then
you compile the body of library A, which puts the checksum for the header
for A into the body of A, along with the checksum for the body of A. Same
with B. Then you compile C against the headers for A and B, and generate a
checksum for C into C, along with storing the checksums for A and B's header
object code.
When you link, the linker checks that every reference to A's object code has
the same checksum, that every reference to B's object code has the same
checksum, etc.
If you change A's header file and recompile it, you'll have a different
checksum in A's header file object code, and you'll have to recompile both
A's body and C before you can relink. You can, however, recompile A's
implementation without having to recompile C.
> Yeah, and if your hard drive dies, you also get a failure. Also a big
> difference. I still don't get your point.
That you know the code you're running isn't the code you have the source for.
> You talk as if accidentally touching an object file is a relatively
> common happenstance.
So you've never updated a library that you'd already compiled against? What
do you think "DLL Hell" is?
If I compile, today, against September's libraries, then I install
November's libraries, stuff doesn't recompile.
> in the fifteen or so years I have been using
> makefiles, guess how many times that has happened to me.
It *can* work OK, if everything is done carefully and you're not using
pre-compiled stuff for half of what you're doing. C has always been pretty
good as long as you have all the source code and everyone working on it is
careful.
>>> There are like a million scenarios where you accidentally do something to
>>> your files which will cause a malfunction (regardless of your IDE).
>
>> Sure. You're apparently trying to miss my point here, which is that the idea
>> that basing dependency information and content-change information solely on
>> file timestamps is iffy.
>
> The situations where it causes problem are so extremely rare that it just
> isn't worth the price of the compiler calculating checksums of every single
> file in the project every time you want to do a quick compile.
Nobody does that, tho. Nobody *needs* to, because type information and
declarations are actually stored in object files. Neither Ada nor C#
calculate any checksums except when they compile the code they're
calculating the checksums for. Given that calculating the checksum is
undoubtedly faster than even -M on gcc, and you only do it when you actually
recompile something, I'm not sure why you think it would be a bad idea.
You can't do it in C because there's no place to store the checksum from a
.h file, because a .h file doesn't create code. (Generally speaking, of course.)
> Imagine that
> every time you want to compile your project, you had to wait a minute for
> the compiler to check all the checksums, when with the current scheme it
> can do it in a few seconds.
Yeah, that would suck. Good thing nobody works it that way.
Of course, the projects I've worked on spent at least that much time
recursing into makefiles just to check, so that's no biggy.
> Nevertheless, you are still blaming the programming language for a
> defect you see in the compiling tools. All this has nothing to do with C.
See above. C doesn't generate object files for .h files, so *if* you wanted
to use checksums, then yes, you *would* have to do it this sucky way. But
the languages that don't use #include don't have to do it this sucky way.
You have pointed out exactly what my point in this part of the discussion
is, and exactly why C (and other source-include macro languages) sucks in
this particular respect.
>>> Of course the makefile assumes that you have specified all the necessary
>>> dependencies. It cannot read your mind.
>
>> I have never seen a makefile that lists as a dependency of my code all the
>> things that stdio.h includes.
>
> And that makes it impossible to create such a makefile (especially if you
> are using a dendepency-generation tool)?
No. I'm just saying that in practice, it doesn't happen, so in practice,
there are still times when you have to either do a make-clean or risk having
broken code.
> Anyways, exactly why would you want to recompile your program if stdio.h
> changes? You see, stdio.h is standardized, and if it was changed in such
> way that programs would need to be recompiled for them to work, it would
> mean that the C standard has been changed to be backwards-incompatible and
> it would break basically all programs in existence.
Nope. All I need to do is redefine O_RDWR to have a different value or
something like that. (OK, not stdio.h, because that's very modularized.)
Or, if you want, errno.h or any of the other less-well-thought-out include
files.
Of course, if someone comes along and does a #define in some include file
that conflicts with something in stdio.h, then you're screwed too. Ever
spend three days trying to figure out why putting
extern int write(int,char*,int);
at the top of your source code so you could print some debugging info throws
a compiler error saying "too many close braces"?
>>> If you are using a tool to create the dependency lists and that tool
>>> fails for some reason, blame the tool, not make.
>
>> If I'm using a tool to create makefiles, then sure, but that's just saying
>> makefiles are so useless that I have to automate their creation. Why would I
>> use a tool to create makefiles using a tool that just does the job properly?
>
> You could make the same argument for any program that doesn't do everything,
> and needs to work in conjunction with another program in order to perform
> some task. Your argument is moot.
No. I'm saying that make only does one thing, and it does it so poorly that
almost nobody actually uses it manually. I'm not against independent tools.
> As for makefiles, not all things that can be done with makefiles can be
> automated.
No. And those things that can be done with makefiles like that shouldn't be
using makefiles to start with, because it's probably the wrong tool.
>> There's really only one task going on here - dependency checking. That's the
>> one and only thing Make does.
>
> Make can't know if eg. a code-generating program depends on some data
> files unless you tell it.
Yep! And there's the problem.
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. Know what else? The tool I'm using
does, because as I compile that XML file into the internal format, I'm
telling the build system "By the way, the results of compiling this XML also
depends on that texture, that sound effect, and those two animations."
If I were to try to do this with Make, I'd either be repeating all the
information manually, or I'd have to write a program to parse that XML file
and pull out the appropriate dependencies, except output them in a different
way.
> I gave an example in my other post of an actual project I have been
> working in where makefiles are useful for something else besides purely
> compiling C++.
Yes, I think we crossed in the mail.
>> I'm sorry, but if anyone in the world asked me "how do I invoke the gcc
>> compiler", I'd say "use /usr/bin/gcc" or something. I would *not* add "but
>> be careful not to pass the -M flag, because that doesn't invoke the compiler."
>
> Actually I'm invoking the C preprocessor. I could call it directly, but
> gcc does it automatically when you specify the -M parameter. The calls
> "gcc -M test.cc" and "cpp -M test.cc" produce the exact same result.
> I could simply use the latter if I wanted to be pedantic.
I'll just let this one drop, if you're actually going to argue that "C
preprocessor" isn't a part of the compiler.
> Instead, we have "project files" in IDEs which do... what? Well, exactly
> the same thing as makefiles.
No. They solve the same problem that makefiles are supposed to solve. They
don't do the same thing as makefiles. And that's the distinction I'm making.
It's like saying "C++ does exactly the same thing as C: It takes a fairly
machine-oriented source file and turns it into machine code." But you would
give me grief for saying that without pointing out that C++ does it much
*better* than C, and solves some of the problems that C simply can't handle,
right?
> In fact, "project files" are just makefiles,
No, they're not.
> using some other IDE-specific syntax. (They might have features that 'make'
> doesn't support, but in principle they are the same thing.)
And in principle, C++ is the same thing as C, it just has some features that
C doesn't support, right?
> The only difference is that most IDEs generate the dependency rules for
> source code files automatically so you don't have to write the few magic
> lines into the project file yourself.
No. Most of them have a different way of both specifying and evaluating
dependency rules.
> However, again, in principle it's
> no different from a generic makefile that generates dependency rules
> automatically (like the one I pasted in an earlier post).
No, that's exactly what I'm saying. Did you even read what I wrote is in the
"makefile" of a C# project? In what sense is that "the same thing as a
makefile", other than it solves the problem of only recompiling what needs
to be recompiled?
In C#'s project files, there are names of neither source code files nor
object code files, other than "here's the list of files to compile into this
project". They're just not in there. You don't have to specify other files
you depend on. You don't have a list saying "this file depends on that file
and the other file".
> You still can't get past the fact that in unix different tasks are
> separated into different tools. Fine, you hate that. Move on.
You're completely ignoring what I'm saying. Fine, move on.
Actually, now that I think about it, yes, this actually is part of the
problem. The problem is that the thing that actually *depends* on those
dependencies is indeed independent of the build system, and that means you
have to put the same dependency information in two different places.
Thinking on it (see the end of this mess), this is exactly how the Visual
Studio build system gets around the problem, regardless of the complexity of
the dependency chain. The first time you compile the program, it saves what
other files it depended on. So, basically, the first "make" creates the
makefile for you. It also, incidentally, thus knows what the output files
are that were created and can safely delete them when you clean without
accidentally clobbering something else.
I prefer the DRY principle, where my dependencies are only held in one
place, especially when that place is checked automatically. Your suggesting
that -M is sufficient is simply making the thing ass-backwards, building the
dependency list for the compiler instead of vice versa. You're basically
running the code thru the compiler to figure out what the dependencies are,
then using those dependencies to run the code through the compiler *again*.
Other build systems eliminate that first step, which is one less set of
duplicated data you have to manually keep up to date right there.
>> Now, go regenerate the rules without
>> the -M flag.
>
> And why exactly would I want to do that? You might as well ask "compile
> the program without using the compiler".
And you'd complain if one of the steps of compiling the program was to tell
the compiler what machine code to generate for different parts of your code,
right?
>> I'm not saying that generating the dependencies, *today*, isn't
>> easy. I'm saying that the job Make was created to handle, namely recording
>> and evaluating dependencies, is obsolete.
>
> And how do you propose to handle dependencies on things that the compiler
> does not handle, such as creating data files from some input files using
> some tools (and perhaps recompile the program only if those data files
> change)?
Yet, oddly enough, that's what I've been doing all week. Funny, that.
Certainly I say what compiler handles each kind of source code: I can't run
a PNG file through gcc. But that's just setting a default rule for a
particular piece of code.
>> Makefile dependency lists are, for
>> the most part, created by other tools
>
> Only program source code dependencies. If you have other types of
> dependencies you still need to specify them by hand because no automated
> tool can read your mind.
No, this is just factually incorrect. I have no need to specify by hand
that my animation as specified in my XML depends on those six files. (Well,
obviously, I'm specifying it in the XML just like I'd be writing #include
into my C sources. I'm not specifying it anywhere outside my own data files,
tho.)
Note also that this means when I change compiler options (like whether I
have debugging or optimization turned on, etc) then I can recompile the
code, because the compiler has the opportunity to store a dependency on its
own command-line arguments, or at least the command-line arguments that
might make a difference in whether the object code will be different.
--
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:
>> Patrick Elliott wrote:
>>> Trying to work out what went wrong, and why, from the damn code, and the
>>> code that built the code, and the code that ran the code, that built the
>>> code... o.O
>
>> Precisely. When the configuration file to create the build tools is based on
>> turing-complete macro processing, you're gonna just be screwed if there's
>> anything wrong.
>
> Yet this is still somehow a problem with makefiles.
Where did I say makefiles in there?
I'm railing against arbitrarily complex build systems where you can't look
at the configuration file and figure out what it's going to compile. It's
the same thing I have against C include files: if they were limited to
declarations, it would be far, far less of a problem.
--
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:
>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Warp wrote:
>>> In Ada, you don't calculate the checksums of every source. You
>>> calculate the checksum of the file you're compiling when you compile
>>> it. In C#, your file is either associated with a project (i.e., with
>>> the equivalent of a makefile) or it's installed in the global
>>> assembly cache with a version number and a cryptographic checksum on
>>> it you can check against.
>>
>> So if you have thousands of files in your project, the compiler will
>> calculate the checksums of every single one of them every time you want
>> to compile? And it was you who complained how creating makefile rules for
>> C files is inefficient... Right.
>
> Read the second sentence again. You calculate the checksum of the file
> when you compile it. You then store that in the object code.
Oh, and just as an aside, GNAT did it this way for a while, and then they
found it really was faster to actually re-read the header file and generate
the checksum and (essentially) recompile it than it was to track a separate
object file for the header file. So, yeah, in practice, not a problem. Read
their documentation for details. :-)
--
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/30/2011 1:54 AM, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>> Patrick Elliott wrote:
>>> Trying to work out what went wrong, and why, from the damn code, and the
>>> code that built the code, and the code that ran the code, that built the
>>> code... o.O
>
>> Precisely. When the configuration file to create the build tools is based on
>> turing-complete macro processing, you're gonna just be screwed if there's
>> anything wrong.
>
> So let me get this straight: He was trying to compile a program with
> Visual C++, the project did not have a Visual C++ project file, he was
> trying to compile it in Windows which is not Unix and hence does not use
> the same core tools, and consequently he had big problems in compiling
> the program. Yet this is still somehow a problem with makefiles.
>
> It seems to me that anybody could make a post with any random problem
> they had, and if a makefile was somehow involved, you would immediately
> rush to agree with a "precisely!" answer regardless of what was the real
> cause of the problem.
>
It did have a VC++ project file, unfortunately that project file
included calls to Unix tools, to generate the changes needed to make it
compile. A project file is just another name for a MAKE file (at least
on Windows). It has processing logic, and can call externals, etc.
--
void main () {
If Schrödingers_cat is alive or version > 98 {
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/01/2011 05:28 PM, Darren New wrote:
> But here's a question: Does it only regenerate the pages of
> documentation for the files where the source of the documentation has
> changed?
There are two kinds of documentation to consider.
GHC comes with a User Guide and a handful of other miscellaneous files,
which are written in DocBook. GHC also comes with a small handful of
Haskell libraries, which each have API reference documentation embedded
in the source code. This is extracted and turned into HTML by a tool
called Haddock.
Due to the amount of cross-referencing possible, editing any single
source file can potentially affect an arbitrary number of documentation
files. Short of a tool to actually analyse a source tree and figure out
all the dependencies, it's difficult to handle this properly. You would
need a tool to read the entire source and compute the dependencies.
GHC doesn't bother. If any source file changes, the whole documentation
is rebuilt. Notice, however, that if the source for document X changes,
only document X is rebuilt. So some level of dependency analysis *is*
being done. (And especially since the documentation is of more than one
form, so you have to know how to rebuild it correctly.)
> Does it only re-run test cases for code that has been
> recompiled since it last ran test cases?
AFAIK, all of the test cases work by running the final, finished
compiler. I don't think there are any "unit tests" that test just one
program module or something. Thus, if any compiler source code changes,
the entire compiler is recompiled, and the entire test suite rerun. Same
for the benchmarks. (Benchmarks of course depend on almost every part of
the compiler, so it would be infeasible to do it any other way.)
> Or is it more like "this would
> be a shell script, but we already have a makefile so we might as well
> put it in there"?
Well, to some extent, yes. Although Make is selecting the correct shell
script to run in each case...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > Anyways, exactly why would you want to recompile your program if stdio.h
> > changes? You see, stdio.h is standardized, and if it was changed in such
> > way that programs would need to be recompiled for them to work, it would
> > mean that the C standard has been changed to be backwards-incompatible and
> > it would break basically all programs in existence.
> Nope. All I need to do is redefine O_RDWR to have a different value or
> something like that. (OK, not stdio.h, because that's very modularized.)
> Or, if you want, errno.h or any of the other less-well-thought-out include
> files.
And you would immediately break like every single program in your system.
Way to go. (And please don't claim that you don't know why they would break.)
> Of course, if someone comes along and does a #define in some include file
> that conflicts with something in stdio.h, then you're screwed too. Ever
> spend three days trying to figure out why putting
> extern int write(int,char*,int);
> at the top of your source code so you could print some debugging info throws
> a compiler error saying "too many close braces"?
Never miss a chance to bash C.
> > Make can't know if eg. a code-generating program depends on some data
> > files unless you tell it.
> Yep! And there's the problem.
The problem is that 'make' cannot read your mind, it seems.
Of course it cannot know which files a something depends on unless you
tell it. Seems rather obvious to me.
> 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.
> Know what else? The tool I'm using
> does, because as I compile that XML file into the internal format, I'm
> telling the build system "By the way, the results of compiling this XML also
> depends on that texture, that sound effect, and those two animations."
> If I were to try to do this with Make, I'd either be repeating all the
> information manually, or I'd have to write a program to parse that XML file
> and pull out the appropriate dependencies, except output them in a different
> way.
You are constantly shifting the goalposts, and don't seem to be able to
decide if you want to bash makefiles or C, whether what you want is
impossible to do with makefiles or simply more laborious, whether the
problem is that what you want to do is not possible solely with 'make' but
instead you need a third-party tool, or what.
Sometimes it's "make sucks because of the include file system in C",
sometimes it's "make sucks because it can't do this", sometimes it's
"make sucks because while you can do this, it's more laborious than with
this other fancy tool I have", sometimes it's "make sucks because you
need to use the compiler to generate dependencies".
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.
You seem to think that it should mean "supports all programming and
markup languages in existence out-of-the-box, and is able to read your
mind". That's not what "generic" means.
You have made it abundantly clear that you don't like the fact that
you need, oh gosh, third-party tools if you want to automatically create
dependency lists for some specific file formats. "Hey, I have these files
in this format, and I have this specialized tool that tracks dependencies
on them automatically, and 'make' cannot do that automatically, hence
'make' sucks." Way to miss the point.
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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> >>> 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.
You have seen a lot of bad C code. I understand that. That's not what
I'm arguing.
> > 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.
> 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.
Exactly how do you compile a bunch of .c files into corresponding
executables with "a simple one-line shell script"?
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, but putting all commands into
one single long line is not what is usually meant by a "one-liner"
(except perhaps in the IOCCC). "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).
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.
This is exactly where a makefile would be useful: It would compile
only the program that needs recompiling, skipping the others. And even
if you wanted to go the easy way and just not have to specify any
dependencies, you can still use the makefile to compile only what you
want to compile (with something like "make program3").
The advantage of that over having a separate shell script for every
single program? You only need to specify compiler options (eg. warnings
and optimizations) once, rather than duplicating it in each script.
(Of course you could have each script call a common script that has the
options, but that starts already being a lot more complicated than the
makefile would be, for no discernible benefit.)
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. After
all, that's precisely what makefiles are for.
> 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."
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.
Creating a shell script for this is the hard way.
> >>> 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.
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.
Besides, you *are* changing the argument. First it was "make cannot figure
it out on its own", then it was "it's not possible to correctly figure out
the dependencies" (whatever that means, as I still don't get it).
Let's see where will you move the goalposts next.
> > 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.
Oh, now "inability to correctly figure out dependencies" has been changed
to "it's non-trivial to figure out the correct dependencies".
Keep moving the goalposts. Which fancy term will you use next?
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?
> >> 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.
Then, perhaps your preferences are "right" and mine are "wrong".
> > 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.
But it's what allows you to generate building rules for things that don't
have any automated tools. (And yes, the same thing can be done with the
'project' files of most IDEs. They are, after all, doing basically the same
task.)
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?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
