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:
# 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)
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?
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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:
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.
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.
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.
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.
and i'd like it to just look like this:
i'm unable to find out what is printing the gcc -O -ggdb stuff, here is what my makefile looks like: