 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] 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.
--
- 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
|
|
| |
| |
|
|
|
|
| |
