GNU make and my thoughts on it

[RussSchultz]

I think the folks that wrote GNU make are just a bit daft.

Apparently, a rule MUST be preceded with a <TAB> character. Not spaces, not white spaces, but a <TAB>

That is SO fricking frustrating. They could have picked a visible character, like a tilde, or a dash, or a bar, or anything, but a tab.

Since I'm a bit of a make neophyte (the embedded version of nmake that I use doesn't require the tab) can any make guru explain why a tab makes so much sense?

 

[BRiT]

It's not an issue with GNU Make. The 'daft' people are the original make creators.

The specifications of the original make program requires a TAB character as the command designator. I can only venture to think they wanted to make distinguishing of commands and rules easier for the parser they had to code. The specification of a TAB serves a dual purpose, as it's easier to recognize a line as a command from the indentation.

I shared your frustrations until I've setup GNU Emacs to switch into MAKE-style mode with color hilighting. Very easy to spot tabs vs spaces.

I've been in the Java-world so long that I dont know what new tools are out, but I'd venture to say there's likely to exist other xml-style rule-based control system similar to ANT or Maven. If you're feeling adventurous, could always try out ANT with the C/C++ plugins. One downside is the host platform for your C/C++ compiler would need support for Java.

 

[epicstruggle]

i hated using make, when i was learning to program (@MSU) on unix system. Moving files from windows to unix would be a hassle since extra characters would be added or replace. The tab rule frustrated me to no ends. Especially when using vi to edit the darn thing. give me visual studio any day of the week.

later,
epic

 

[RussSchultz]

I searched on google and the usenet about this and its amazing that people still accept this as "OK" and just love lambasting newbies that they should RTFM.

Oh well.

 

[Simon F]

I think the folks that wrote GNU make are just a bit daft.

Apparently, a rule MUST be preceded with a <TAB> character. Not spaces, not white spaces, but a <TAB>

That is SO fricking frustrating. They could have picked a visible character, like a tilde, or a dash, or a bar, or anything, but a tab.

Since I'm a bit of a make neophyte (the embedded version of nmake that I use doesn't require the tab) can any make guru explain why a tab makes so much sense?

Russ,
Use xemacs to do the editing of your Makefile and it'll highlight dodgy build commands.

[Edit Ahh I see Brit already pointed that out]

I quite like GNU make - using it in combination with the gcc command to output dependencies can be a life saver!

 

[davefb]

it wouldnt be so bad if the darned thing at least gave sensible errors when you had spaces instead of tabs!
I think most linux/unix leet probably think this is some 'hilarious' trap for newbies.. As for usuing emacs or something,, well yeah, but if you've about 15 other coders who might accidently load the make file into sourcesafe , or edit, or v-c , not 'really make a change' then save the thing back into vss,, well you've got the nightmare that is being a lead

-dave-

i *really* hated that tab thing,, i just *couldnt* understand what was going on for ages..... shudder.....

 

[Simon F]

If you don't use a tab it reports:

Makefile:197: *** missing separator. Stop.

It's not that bad!

. As for usuing emacs or something,, well yeah, but if you've about 15 other coders who might accidently load the make file into sourcesafe , or edit, or v-c , not 'really make a change' then save the thing back into vss,, well you've got the nightmare that is being a lead [icon_smile.gif]

I've never used Source Safe (...well I evaluated it years ago and decided it was too dangerous...) but surely you can list the differences between file revisions? Or does it ignore white space differences?!

I "hacked" some extra tools on top of RCS to explitly list the changes as you checked in files. It was well worth the small amount of effort.

 

[RussSchultz]

Clearcase has no problem telling you which files have changed, its just the supreme danger of having editors that automatically convert tabs to spaces (which we enforce at our work, because we try to keep a consistant style/formatting within our SDK since we give it to customers and tabs get in the way of that) undoing a big makefile unwittingly.

 

[Simon F]

Might I humbly suggest that you could try:
Within the company standardise on, say, TAB==4 spaces within the editors. That way you'd avoid problems with the accidental corruption of files.

Then, when you run your packaging/export script, you use, say, a tiny awk|perl|sed script to convert tabs to spaces on *.[ch] etc. <shrug>

 

[davefb]

i think most of the problem was that once the makefiles got settled we never edited them.. until 1 day after i'd forgotten everything to do with makefiles,, then i'd be editing them again..... aarrrgghh


vss is pretty good, i never had any real problems..
except for
1.education ( people just never checking stuff in/out, or would rename files before checking them in !??).
2.network space ( it didnt like running out of space).
3.the endless "is multiple checkouts good or bad" argument.
4. we expected people to 'get latest' and ensure there was nothing wrong before doing 'checkins' , though most people kept forgetting

i prefered NO to multiple checkouts and prefered people to checkin/checkout more often..
If you can get your head around branching pin'ing it's okay. The company i worked for it must be said *did* develop their own tool, mainly since we felt it was difficult to handle medium sized changes within the main vss tool. though thats another story :-/

-dave-

*shudder* and enforcing case sensitivity or at least , 'for gods sake use lower case for filenames'

 

[Simon F]

vss is pretty good, i never had any real problems..

The thing that scared me was the version control file looked to use some compressed/encoded/encrypted storage of the source file. If the tool ever broke then I was worried that it would have locked up the code for all eternity.

 

[davefb]

I can't remmeber the source-files being 'mangled' though it might have been attempting to compress in some way and i never really looked at the server versions of files . I do recall that we had problems when somebody used the server versions of directories and checking in there ( ouch), we backed up using the internal tool and all was fine ( most lost work was just a case of carefully rechecking local copies in).
Even m$ didnt trust it for stability though, as they said it should never be seen of as being a backup tool.. We expected people to make personal backups of their local code (assets) and we made backups of the vss files as well. Both regularly using the server tape backups and less regular using the inbuild m$ tool , which frankly wasnt that nice ( though our server was a terrible 486 !)..

-dave-

 

[Anonymous]

I dislike Make as well.

'Ant' rocks..you usually make "Build.xml" and put your commands in there, it's similar, just call ant with a target but then the commands for doing stuff are a little easier and a little more flexible.

 

[Dio]

I read a quote recently on some slashdotted article that the original developer of Make realised that the TAB issue was a travesty after a few versions, but when he tried to make the change there was major objection, so TABs it is stuck with. Have absolutely no idea what it was in though.

Every now and then I like to get a bunch of people in a room and fight about make - the division between 'gods gift to programmers' and 'evil! evil!' is pretty fundamental. In fact, I've not seen any issue that is quite as likely to start a huge argument as "Isn't make shite?"

I'm on the make-hating side myself.

 

[davefb]

interesting that ant get's a mention. just 'bumped' into it whilst looking at j2me work.. From Ant's website ( ant.apache.org ) .

"Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times. Tools like Jam took care of this to a great degree, but still have yet another format to use and remember."



-dave-

 

[BRiT]

I love ANT for the Java realm. I mentioned it back in the 2nd post of this thread.

I'm a bit sadistic, so I love GNU Make and GNU AutoConf. I also liked writing my own malloc routines back in the day too. Then again, I would also tweak the assembler output of the C compiler too.

I'm of the opinion that nothing is inherently evil; aside from marketting. But a few things come close, like Rational products...

 

[Simon F]

Struth guys! You're worried about a measly little tab in Makefiles when there are far bigger stupidities in the programming world?

Take C for instance with its syntax for accessing data structures. If you have a pointer, you use prefix notation, i.e. *pData, but if it's an element in a referenced structure you switch to postfix pData->stuff. Nice and constistent and even more fun when you have a pointer to a pointer to a structure... or was it a pointer to a structure element that's a pointer. Joy.

And then, of course, there is the definition of data structures which have to be read backwards except when you find the "const" keyword, and then there are the 10Million different levels of precedence, and the dangers of people using pre/post side effect increments in expressions (!!!)....

If we can live with that rubbish, a tab here or there is a non-issue.

 

[Dio]

Ah, but at least in C the error isn't invisible.

 

[Simon F]

Maybe not, but at times it can be damned well camouflaged. :?

 

[Dio]

Well, if you want really well camoflaged errors, there's nothing like the preprocessor for those.

Try mixing #define with inline asm on MSVC. It will probably work.... briefly...