30 Nov, 2008, Igabod wrote in the 1st comment:
Votes: 0
i've been tooling around with my makefile trying to make it a little easier on the eyes and i've been successful so far but it shows some things i'd rather it not show. currently it looks like this when i do a make:

–>  Compiling file: update.c  <–
gcc -O -ggdb -DNOCRYPT -DQMFIXES -c -o obj/update.o update.c
[- update.c compiled OK -]


and i'd like it to just look like this:

–>  Compiling file: update.c  <–
[- update.c compiled OK -]


i'm unable to find out what is printing the gcc -O -ggdb stuff, here is what my makefile looks like:

# $Id $

CC = gcc
RM = rm
EXE = merc
PROF = -O -ggdb
CYGWIN = -DCYGWIN
ECHOCMD = echo -e
# colors.
L_RED = \e# $Id $

CC = gcc
RM = rm
EXE = merc
PROF = -O -ggdb
CYGWIN = -DCYGWIN
ECHOCMD = echo -e
# colors.
L_RED = \e[1;31m
L_BLUE = \e[1;34m
L_GREEN = \e[1;32m
L_WHITE = \e[1;37m
L_NRM = \e[0;00m
L_MAGENTA = \e[1;35m
L_YELLOW = \e[1;33m

# Use these two lines to use crypt(), ie on Linux systems.
# C_FLAGS = $(PROF) -Wall
# L_FLAGS = $(PROF) -lcrypt

# Uncomment these two lines to use plaintext passwords.
# This is how you fix the 'crypt' linking errors!
C_FLAGS = -Wall $(PROF) -DNOCRYPT -DQMFIXES
L_FLAGS = $(PROF)

# Source Files
SRC_FILES := $(wildcard *.c)

# Object Files
OBJ_DIR = obj
OBJ_FILES := $(patsubst %.c,$(OBJ_DIR)/%.o,$(SRC_FILES))

merc: $(OBJ_FILES)
@$(ECHOCMD) "$(L_RED)[- $(L_WHITE)Rebuilding MUD executable: $(L_GREEN)$(EXE)$(L_RED) -]$(L_NRM)"
$(RM) -f $(EXE)
$(CC) $(L_FLAGS) -o $(EXE) $(OBJ_FILES)

$(OBJ_DIR)/%.o: %.c
@$(ECHOCMD) "$(L_RED)–> $(L_WHITE)Compiling file: $(L_MAGENTA)$<$(L_RED) <–$(L_NRM)"
$(CC) $(C_FLAGS) -c -o $@ $<
@$(ECHOCMD) "$(L_RED)[- $(L_YELLOW)$<$(L_NRM) compiled $(L_GREEN)OK$(L_RED) -]$(L_NRM)"

clean:
@$(ECHOCMD) "$(L_RED)–> $(L_BLUE)Cleaning up for full make… $(L_NRM)\c"
$(RM) -f $(OBJ_FILES) $(EXE) *~ *.bak *.orig *.rej
$(RM) -f ../area/merc
@$(ECHOCMD) "$(L_RED)–> $(L_GREEN)done$(L_NRM). $(L_RED)<–$(L_NRM)"
make

cleanup:
@$(ECHOCMD) "$(L_RED)–> $(L_BLUE)Making clean for backing up $(L_NRM)\c"
$(RM) -f $(OBJ_FILES) $(EXE) *~ *.bak *.orig *.rej
$(RM) -f ../area/merc
@$(ECHOCMD) "$(L_RED)–> $(L_GREEN)Ready to make a backup now$(L_NRM). $(L_RED)<–$(L_NRM)"
[/code]
i tried everything i could think of but wasn't able to get it to work right. the closest i got was by removing this part (line 41 of the makefile):

[code] $(CC) $(C_FLAGS) -c -o $@ $<
[/code]
and when i do that it starts out looking the way i want it but then i get the following output:
[code]gcc: obj/update.o: No such file or directory
[/code]
for every object file. this makes me think that i removed the right thing but i also removed something important in that line so i'm only supposed to remove part of that line but i'm not sure which part needs to be removed and which needs to stay. i want it to still do the gcc -Wall -O -ggdb etc but i don't want that displayed. any ideas?
30 Nov, 2008, ghasatta wrote in the 2nd comment:
Votes: 0
By default, make echos ("announces") each command it is executing. You can suppress this for any given line by adding an '@' character to the beginning. So, change line 41 from this:

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

to this:
@$(CC) $(C_FLAGS) -c -o $@ $<


You could also do 'make -s' to run make in silent mode and disable the echoes by default.
30 Nov, 2008, Igabod wrote in the 3rd comment:
Votes: 0
that worked, thanks so much.
30 Nov, 2008, Grimble wrote in the 4th comment:
Votes: 0
You may want to have a look at…

http://make.paulandlesley.org/autodep.ht...

…to add auto-dependencies to your makefile. The way it is now, if you touch a header file, nothing gets rebuilt.
30 Nov, 2008, Igabod wrote in the 5th comment:
Votes: 0
ummm… i've been using this makefile for a few months with absolutely no problems, are you sure about that?
30 Nov, 2008, elanthis wrote in the 6th comment:
Votes: 0
Yes, he's right. Try it. Edit a .h file, but do not edit any .c file. Type make. Nothing will happen.

Admittedly it's relatively rare for a header file to change without some bit of code somewhere changing with it, but it does happen from time to time. Mostly when tweaking #define constants.

Doing automatic dependency checking and updating is a real chore, unfortunately. The simple approach will actually break if you ever remove a header file; you'd be force to delete your automatic dependency files. In order to make it all work right, you have to use some pretty ugly code. More details explained in the following link.

http://make.paulandlesley.org/autodep.ht...
01 Dec, 2008, Tyche wrote in the 7th comment:
Votes: 0
Hmmm.. yes here's an example ROM makefile that implements Makefile dependencies

Who in their right mind colorizes build output? Sheesh.
01 Dec, 2008, Lobotomy wrote in the 8th comment:
Votes: 0
Tyche said:
Who in their right mind colorizes build output? Sheesh.

Anyone that finds colorless output to be boring, obviously. I rather like having my gcc errors display in a bold red, for instance. It makes them easier to spot among all the other output.
01 Dec, 2008, Sharmair wrote in the 9th comment:
Votes: 0
Igabod said:
ummm… i've been using this makefile for a few months with absolutely no problems, are you sure about that?

As long as you do a make clean then a make after changing an .h file you will be fine.
It just will not be automatic with just make. Frankly, I would not bother with the hassle myself, but
then again I develop under windows using MSVC and only use make when uploading to the live MUD
server and compiling. At that point it is most often a clean compile as it has already been tested under
windows.
01 Dec, 2008, Igabod wrote in the 10th comment:
Votes: 0
ah well i always do a clean make when altering a header file anyway, it's what i was taught by the person who got me interested in coding. i just need to make sure any coders i hire in the future know to do this. and to tyche, i colorized it cause sometimes all the white blends together when i get a ton of errors all at once so i like to have colorized boundaries to look in so i can see which errors belong to which files easier. plus it looks a lot nicer than just a bunch of white text and it's not like i'm using garish colors or anything. just enough color to be seen easily.
01 Dec, 2008, elanthis wrote in the 11th comment:
Votes: 0
Igabod said:
ah well i always do a clean make when altering a header file anyway, it's what i was taught by the person who got me interested in coding. i just need to make sure any coders i hire in the future know to do this


Feh, and you call yourself a coder. :p Real programmers always put in a ridiculous amount of effort to save themselves the occasional 2 seconds of work down the road. :p

Quote
and to tyche, i colorized it cause sometimes all the white blends together when i get a ton of errors all at once so i like to have colorized boundaries to look in so i can see which errors belong to which files easier. plus it looks a lot nicer than just a bunch of white text and it's not like i'm using garish colors or anything. just enough color to be seen easily.


I might note that if you use a more capable editor, the editor could pick up the errors for you and take you directly to the file and line the errors are on. e.g., the :make command in Vim.
01 Dec, 2008, Grimble wrote in the 12th comment:
Votes: 0
elanthis said:
Igabod said:
ah well i always do a clean make when altering a header file anyway, it's what i was taught by the person who got me interested in coding. i just need to make sure any coders i hire in the future know to do this


Feh, and you call yourself a coder. :p Real programmers always put in a ridiculous amount of effort to save themselves the occasional 2 seconds of work down the road. :p


Doing a full build after any editing may be fine for a small project, but as it grows it will become a nuisance and you will want dependency checking in place to improve your productivity. You may eventually find yourself using make and dependencies for more than just the source code (e.g., generating a new API with swig, turning a Lua script into bytecode, etc). The technique described in the link cited earlier is trivial to integrate, so I can't imagine why anyone wouldn't do it.
02 Dec, 2008, elanthis wrote in the 13th comment:
Votes: 0
Grimble said:
Doing a full build after any editing may be fine for a small project, but as it grows it will become a nuisance and you will want dependency checking in place to improve your productivity. You may eventually find yourself using make and dependencies for more than just the source code (e.g., generating a new API with swig, turning a Lua script into bytecode, etc). The technique described in the link cited earlier is trivial to integrate, so I can't imagine why anyone wouldn't do it.


You're telling me. AweMUD (now Source MUD) is C++, comprised of 112 source files, and has several source and data files which are auto-generated from Perl and XSLT scripts from other source files or XML files. Given the heavy use of templates and the rather excessive inclusion of unnecessary headers from other headers, building any file outside of the original Lua distribution files (bundled to compile as C++ for exception support) is slower than molasses. Even a make -j4 on my quad-core machine takes 18 seconds to build the whole thing from scratch. It really needs a diet… which I've spent the last week and a half working on giving it, but it has a long ways to go.

I'd have stabbed myself in both eyeballs a week ago if I didn't have automatic dependency generation and I had to rebuilt the whole thing every time I modified a header. Heck, I ripped out Automake just because I got sick of how much build-time overhead it added compared to using the code in the link above.

Man, I was dumb when I was 16. And 18. And 22. And 25. I guess Red vs Blue put it best: "I can prove, mathematically, that you're an idiot. Take your age and subtract 10. Were you smart back then? No, you were a goddamn idiot. Truth is you're still an idiot now, it's just going to take 10 years before you realize it."
02 Dec, 2008, Tyche wrote in the 14th comment:
Votes: 0
Lobotomy said:
Tyche said:
Who in their right mind colorizes build output? Sheesh.

Anyone that finds colorless output to be boring, obviously. I rather like having my gcc errors display in a bold red, for instance. It makes them easier to spot among all the other output.

They'd be far easier to spot if one didn't introduce a rainbow of noise.
02 Dec, 2008, Lobotomy wrote in the 15th comment:
Votes: 0
Tyche said:
Lobotomy said:
Tyche said:
Who in their right mind colorizes build output? Sheesh.

Anyone that finds colorless output to be boring, obviously. I rather like having my gcc errors display in a bold red, for instance. It makes them easier to spot among all the other output.

They'd be far easier to spot if one didn't introduce a rainbow of noise.

Well, it's just as with the use of colors in normal MU* game output: moderation is key. Using too much color is just as bad as not using any.

Edit: In case there was confusion, I should note that when I previously said "It makes them easier to spot among all the other output." I was referring to it as compared to when the output is all colorless. I.e, coloring the error messages makes them stand out as opposed to purely colorless output where they are the same color as everything else.
02 Dec, 2008, Tyche wrote in the 16th comment:
Votes: 0
Okay while color is extraordinarily important to some people, this particular Makefile has a crapload of lameness…

3. CC = gcc
4. RM = rm
5. EXE = merc

merc is NOT the name of the executable on cygwin, it's merc.exe

One solution is…
# uncomment for cygwin
#EXE_SUFFIX = .exe
# uncomment for unix
#EXE_SUFFIX =
EXE = merc$(EXE_SUFFIX)

6. PROF = -O -ggdb
7. CYGWIN = -DCYGWIN

The above can also be replaced with…

CYGWIN = -DLAMENESS

and with no lame side effects.

18. # Use these two lines to use crypt(), ie on Linux systems.
19. # C_FLAGS = $(PROF) -Wall
20. # L_FLAGS = $(PROF) -lcrypt

Oh rly? Since when does one put libraries before the objects that reference them on the command line.
Lame!
see 'man ld'

Traditionally one uses something like…
LIBS = -lcrypt

21.
22. # Uncomment these two lines to use plaintext passwords.
23. # This is how you fix the 'crypt' linking errors!
24. C_FLAGS = -Wall $(PROF) -DNOCRYPT -DQMFIXES

Obviously because of the lameness above the crypt library would appear to be unresolved.

26.
27. # Source Files
28. SRC_FILES := $(wildcard *.c)

Head bangingly lame.

29.
30. # Object Files
31. OBJ_DIR = obj
32. OBJ_FILES := $(patsubst %.c,$(OBJ_DIR)/%.o,$(SRC_FILES))
33.
34. merc: $(OBJ_FILES)
35. @$(ECHOCMD) "$(L_RED)[- $(L_WHITE)Rebuilding MUD executable: $(L_GREEN)$(EXE)$(L_RED) -]$(L_NRM)"
36. $(RM) -f $(EXE)

Remove won't work on cygwin without suffix (see above).
Oh the crying lameness of removing a target so make can't decide that it does or doesn't need to build it.

37. $(CC) $(L_FLAGS) -o $(EXE) $(OBJ_FILES)

$(CC) $(L_FLAGS) -o $(EXE) $(OBJ_FILES) $(LIBS)

That's where one puts libraries.

38.
39. $(OBJ_DIR)/%.o: %.c
40. @$(ECHOCMD) "$(L_RED)–> $(L_WHITE)Compiling file: $(L_MAGENTA)$<$(L_RED) <–$(L_NRM)"
41. $(CC) $(C_FLAGS) -c -o $@ $<
42. @$(ECHOCMD) "$(L_RED)[- $(L_YELLOW)$<$(L_NRM) compiled $(L_GREEN)OK$(L_RED) -]$(L_NRM)"
43.
44. clean:
45. @$(ECHOCMD) "$(L_RED)–> $(L_BLUE)Cleaning up for full make… $(L_NRM)\c"
46. $(RM) -f $(OBJ_FILES) $(EXE) *~ *.bak *.orig *.rej
47. $(RM) -f ../area/merc
48. @$(ECHOCMD) "$(L_RED)–> $(L_GREEN)done$(L_NRM). $(L_RED)<–$(L_NRM)"
49. make

Notoriusly lame. No I really want to clean, not build.
So how do our target get into ../area and how come it's not referred to as $(EXE)
I suppose it's missing at the minimum something like…

install:
cp $(EXE) ../area/$(EXE)


50.
51. cleanup:
52. @$(ECHOCMD) "$(L_RED)–> $(L_BLUE)Making clean for backing up $(L_NRM)\c"
53. $(RM) -f $(OBJ_FILES) $(EXE) *~ *.bak *.orig *.rej
54. $(RM) -f ../area/merc
55. @$(ECHOCMD) "$(L_RED)–> $(L_GREEN)Ready to make a backup now$(L_NRM). $(L_RED)<–$(L_NRM)"

Wait what was clean for again? Freakishly lame.

:-P
02 Dec, 2008, David Haley wrote in the 17th comment:
Votes: 0
I'm not entirely sure who you're arguing with, but, err, good show? :wink:
02 Dec, 2008, Igabod wrote in the 18th comment:
Votes: 0
first off tyche, your rudeness was uncalled for, i didn't ask for someone to tear apart my makefile and make fun of everything in it, i asked for HELP with a specific part of it, which i was given. if you don't like my makefile thats fine, you don't have to use it. but you also don't have the right to put it down. while you did point out some helpful information, you did it in a piss poor way. if you were truly trying to help me out you would have left out all of the "lame" remarks and just said why what i have doesn't work. i don't know why all that hostility is directed toward me, i've never done anything to deserve it. maybe you should take a few minutes and think about what is going on in your life to make you think that was an appropriate way of addressing this issue. i do appreciate you pointing out where i have problems however so i will give you thanks for that and make the corrections where they apply to my mud. to answer a few of your questions posed in your response, it is slightly screwy cause i'm NOT experienced with makefiles (obviously) and just looked at other makefiles and did my best to take the parts i liked and use them. apparently i made some mistakes that can and will be fixed.

[edit to add] if anybody else would like to help me with this, all suggestions are welcome, just try not to be an ass about it and keep in mind that i'm still learning.
02 Dec, 2008, Cratylus wrote in the 19th comment:
Votes: 0
Quote
first off tyche, your rudeness was uncalled for,


Don't take it personal. It's part of his charm. Generally I've found
that if you disregard the parts of his posts that are offtopic, the
ontopic parts are pretty helpful.

-Crat
http://lpmuds.net
02 Dec, 2008, Igabod wrote in the 20th comment:
Votes: 0
Cratylus said:
Quote
first off tyche, your rudeness was uncalled for,


Don't take it personal. It's part of his charm. Generally I've found
that if you disregard the parts of his posts that are offtopic, the
ontopic parts are pretty helpful.

-Crat
http://lpmuds.net

oh i'm not denying the helpfulness of parts of his post, i'm just saying that i don't deserve to be disrespected like that seeing as how i show respect to everybody here, even in my previous post i was not disrespectful to tyche. at least i don't think i was. however if i am treated with disrespect i tend to lose my respect for that person if it becomes a continual thing.
0.0/85