I understand the basics. But lines like this:

   $(CC) $(CFLAGS) -o $@ -c $<

Just look like nonsense. This (from my own makefile):

   TEMP   = $(wildcard *.cpp)
   FILES  = $(if $(TEMP), $(TEMP), $(error No source code found!))
   OBJS   = $(addsuffix .o, $(basename $(FILES)))

Also confuses the puss out of me. I more or less understand that basic rules/dependancy stuff, but if I take a peek in Allegro's makefiles, there's some scary stuff in there ...

EDIT: BTW, when you say "simple", I think "higher-level" is more appropriate. I remember setting compiler flags in RHIDE long before I knew what a makefile was, because you can call them up in a window and check off the ones you want. It's not a whole lot better since you still need to know what the flags mean, but if RH had put a short description after each one ((-s) strips out debugging information) then it would have been perfect. No need to know makefile syntax; just click and go. Now that's what I'm talkin' about!

Um, no. I have the ability to see the bad in something regardless of whether or not I use the product frequently. Also, VC++ would not be an actual development environment if it exposed the makefile directly to you.

I, personally, don't care whether VC++ uses a .dsp or a makefile internally behind the scenes. As long as I don't have to interact with it, it could be using a FORTRAN script to compile my code for all I care.

Um, I don't see what good a C/C++ library is to a Java developer. As for MacOS X developers... they deserve pity, not libraries. As for Unix developers, they were the start of the whole makefile crap to begin with.

My point is that, if you're going to give out a library that is, ostensibly, for multiple platforms, then actually give it out for multiple platforms. Don't give it out for make environments, then tell me that, "Oh, I've certified that it compiles under VC++."

For example, any library I release will come with VC++ compiled binaries, and a .dsp project. However, I also don't advertise that it is a Linux (or non-VC++) library either; if they can get it up and running with their OS/dev environment of choice, good for them.

Which, of course, matters little.

What's the point of being able to type in a single command line that does something powerful? Is it somehow better than doing it in multiple lines? Or with the equivalent operations in multiple programs?

It may be faster, but consider what it took to write this command line:

First, it took a firm understanding of the concept of "grep". That, in and of itself, requires a good 2 weeks of study to comprehend. Then, you have to understand Perl, which is hardly the easiest scripting language to get a grasp on. Finally, you have to understand the concept of command-line piping.

While some may be impressed by that, I am not among them. Demonstraiting knowledge on esotheric concepts like Grep, Perl, etc, is not particularly impressive, or even useful. The fact that you merely can do something powerful in a single line doesn't mean that this is truly meaningful in any way.

If you want to fairly and honestly evaluate tools, here is how to do it:

1: Does it perform the function required of them? Otherwise, it is a broken tool.
2: Does it require a great deal of specialized knowledge that is, otherwise, useless?
3: Is the tool difficult, or otherwise onerous, to use?
4: How much resources (time, space, etc) does the tool require to accomplish the task?
5: Can you afford the tool?

Do makefiles perform the function? Yes. That's good.

Do they require specialized knowledge that is, outside of using makefiles, useless? Yes. You have to know how to write the internals of a makefile. As such, you must understand them. That's bad.

Are makefiles difficult to use? Yes. For a Win32 machine, you have to go find UNIX tools and compilers (which you are never going to use for anything else). That's bad.

The resources for a makefile, outside of the 100MB of Unix tools, are not particularly onerous.

Makefiles, and that style of development, is free.

The only advantage makefiles have over VC++, and other integrated development environments, is cost. Consider that there is no feature that makefiles offer (a real feature towards compiling a C/C++ program) that VC++, and many other IDE's, do not also offer. If you have special, non-compiler, build steps, you can set these up.

Remember, the goal is to compile a C/C++ project, not to learn a new language. If your tool requires learning a new language to do something that is offerred elsewhere in a much simpler, but no less powerful, fashion, then perhaps you should use that instead.

I'm not into these long post; I normally just scan through them. So sorry in advance if what I'm saying is already covered.

HA! Heaven forbid VC++ makes you look at a makefile!
Hopefully in the next version you won't need to look at any of the other code either. Right? A nice click and play interface. That's what development environments should be like, right? No one needs to customize any code anyway, they just need out-of-the-box software.
like I said: HA!

You need 'Specialized knowledge' like that for practically anything you do! C++ programming itself requires a LOT of specialized knowledge that is useless outside of C++ programming.
Besides, understanding how code is put together is important to most programmers, and that's about all it takes to understand a makefile.

For the basics, makefiles very simple to use. A programmer can be taught to use a makefile in less than 5 mins. However, if you want them to do more complicated things it takes longer.
The same applies for anything else. You still need to learn to use VC++, the skills for which are useless for anything else.
Also, finding unix tools is a few mins on the internet. Going to a shop to buy VC++ is more than that.

Try 6MB. As compared to VC++ 100MB min.

---
You know what? If you think makefiles are so terrible, DON'T USE THEM!

---

Mine don't either.

---
I can write long posts as well!

Do you have any idea how condescending and arrogant that sounds?

Perhaps you'd also like to switch to a different programming language than C? C was developped alongside UNIX, you know.

How am I going to release something with an MSVC build environment if I don't have MSVC? I can release binaries of my games for Windows (and I do) compiled with gcc, which is good enough for me.

Actually, it is. Doing a batch job from the commandline and combining multiple commands into one makes it easier to go on doing other things. I have yet to see a GUI that offers the flexibility of the commandline. If you don't need that flexibility, fine, you don't have to use the commandline. If you do, it's there, ready to use.

It takes you two weeks to understand the concept of a program that searches for strings in files? Wow!

I'll be sure to quote you on that.

Not really. Borland compilers came with their own version of make (which was rather crippled and unusable, but that's beside the point) and I'm pretty sure at least older versions of Microsoft's compilers came with a version of make too.

Mine, unfortunately, do, at least for the more exotic commands `make depend' and `make clean'. At least the latter could use del instead of rm on Windows, though, but I lack motivation to fix it for now

@IronBob: if you still need the UNIX tools, do a google on `fileutils for win32' - it turns up a number of download sites.

Grrr; I did!

I don't recall seeing anything on them. I believe I found the makefile docs assumed too much of my knowledge. Spellcaster's post up there makes more sense, though that still seems unnecessarily confusing I agree with him; 'make' should use a better syntax.

If you say so ...

Just a little part of the first info page. (comes in html too...)

Heres the Varaibles section:

I'd quote the entire info file, but its quite large, and is even installed commpressed.

The point (that, I admit, I danced around) that I'm trying to make is that makefiles are not the beginning and end of compiling C/C++ code. Nowadays, even forgetting IDE's, there could be much friendlier compilation utilities than makefiles.

For example, you can write build utilities as Perl/Python scripts. Or, you can make a Lua-based tool for building. Or, you could make up a language that is far cleaner and more C/C++ like (and therefore use current knowledge, as opposed to new knowledge that is, fundamentally, useless outside of make) than make.

If you take the Perl or Lua approach, you're getting people to learn something that is actually useful, rather than simply forcing random, ultimately fruitless, knowledge down people's throats.

To say that learning make is like learning C++ is absolutely wrong. After I learn make, all I can use it for is writing makefiles. After I learn C++, I can use it for writing any program, including make utilities. Ergo, learning C++ is far more useful than learning make.

Also, consider that learning make is, typically, done as a means to an end (that end being compiling C/C++). Whereas learning C/C++ is the means to doing low-level programming. While there are a number of alternatives, both possible and currently existing, to make, there are no viable alternatives to C/C++ in the area of low-level, performance-based programming. As such, if you want to do this kind of programming, you have no choice but to learn C/C++. Whereas learning make is, ultimately, a dead-end knowledge.

As it turns out, no. Most of the time, the standard configuration of a project is perfectly fine. Indeed, you can get pretty far in programming without altering any of the compilation switches in your development environment.

It depends on how you define "use".

Being able to type, "make *" is only the beginning of being able to "use" makefiles. After all, if said person can't make a makefile on his own, what good is the make dev environment doing for him? He can't create new projects.

If people didn't force me to, I would happily do so.

Libraries are different from games. Libraries need to be compiled for different compilers; games need to be compiled for OS's. As such, a Win32 .exe will always work on a Win32 machine, regardless of which compiler was used on it. By contrast, a '.a' file can't be used with VC++. Ergo, in order to use the library, I have to compile it myself.

Granted that it's Microsoft, it was called "nmake", and it used a different, probably more cryptic, form of the make language. Also, given that it requires VC++, they don't make you edit it by hand; which is the objectionable part.

Aha! 23 admits that there's something good about DJGPP!

BD: Did I ever say otherwise? I cut my teeth on DJGPP, although I like MinGW better now ...

23: You keep telling people to ditch DJGPP

Miquel: I know

Bobby: you think these posts are long? Clicky.

• great built-in debugger

• nice project management

• nice font and colours

• built in info-file access (Allegro's docs were integrated perfectly)

It just worked really well. And it's hard to get the typical Borland DOS IDE look with your typical windows program.