|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |