 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
