Qeustion in Compiling

[Joonshik Kim]

Could any body help me ?

I'm trying to compile a vocoder program in school's HP-unix machine.

when I try following command.

make -f CODER.MAK (CODER.MAK was included in the vocoder source code..)

following message appears.

Make : must be a separator on rule line 31. stop


what do I have to do ?

please..

 

[Allin Cottrell]

when I try following command.

make -f CODER.MAK (CODER.MAK was included in the vocoder source code..)

following message appears.

Make : must be a separator on rule line 31. stop

what do I have to do ?

This has nothing to do with C, but what you have to do is edit
the makefile and insert a separator (probably a tab) on line 31.
If the makefile was copied and pasted from somewhere, tabs may
have got turned into spaces. Consult the "make" documentation
for details on makefile syntax.

Allin Cottrell

 

[Jens.Toerring]

I'm trying to compile a vocoder program in school's HP-unix machine.

when I try following command.

make -f CODER.MAK (CODER.MAK was included in the vocoder source code..)

following message appears.

Make : must be a separator on rule line 31. stop

'make' is a tool that is completely independend from C, so that
question has nothing at all to do with C and is off-topic here.
A better place to go to with that kind of questions would be e.g.
the newsgroup comp.unix.programmer.

<OT>
If you promise to ask questions about make in a different group,
I'll give you a hint: load the makefile into an editor, go to
line 31 and replace the spaces at the start of the line with tabs.
</OT>
Regards, Jens

 

[Dan Pop]

Could any body help me ?

I'm trying to compile a vocoder program in school's HP-unix machine.

when I try following command.

make -f CODER.MAK (CODER.MAK was included in the vocoder source code..)

following message appears.

Make : must be a separator on rule line 31. stop


what do I have to do ?

Either learn how to use the tools involved in the application building
process or ask someone else to build the application. If you don't
understand how a tool works (or, at least, how it is supposed to be used),
you have no business using it.

Dan

 

[jacob navia]

Could any body help me ?

I'm trying to compile a vocoder program in school's HP-unix machine.

when I try following command.

make -f CODER.MAK (CODER.MAK was included in the vocoder source code..)

following message appears.

Make : must be a separator on rule line 31. stop


what do I have to do ?

please..

It was around 1985-1986. My softare shop got
bought by a bigger one, CISI Telematique. The
employees and developers went to CISI's headquarters
to learn the new system, called "UNIX".

We had to discover from the scanty docs of the
Honeywell Bull manuals how to use the stuff. The
thing was to be programmed in a new language, called
"C", instead of the APL we used in the old shop.

There wasn't any interpreter any more, and you had
to specify with great detail to the machine how the
program would run. But it had its rewards, we could
develop incredible more efficient programs, at a lower
level than we were used to in APL.

The whole was organized in "Makefiles", (always with
upper case M as I was told), that a "make" utility
was supposed to swallow.

I remember now, as it was today, one afternoon of 1985,
when Jean Pierre and me spent the whole afternoon staring

"Make: must be a separator on rule line 31. stop"

Not even the wording of the message has changed in those
20 years. Not even that!

The file looked completely normal in our 3270 terminals.
The system editor displayed nothing else as what it
should be there.

AND THERE WAS NO WAY TO FIND ANY INFO ABOUT THAT
in the badly organized and always wrong manuals of
Honeywell Bull.

Bad luck for us, but eventually I got lucky and somewhere there
was a talk about a tab being needed. The file was badly translated
when uploading from the IBM/370 where it came to the mini-computer
with unix. Ahh, a tab is needed.

I remember wondering how can one design such an
interface: tab is invisible, no way to see a tab instead
of 8 spaces can you?

Ahh the good interface rules. And 20 years later the sense
of utter boredom. We are used to say that in the data
processing business everything changes so quickly...

Does it?

 

[Alan Balmer]

Either learn how to use the tools involved in the application building
process or ask someone else to build the application. If you don't
understand how a tool works (or, at least, how it is supposed to be used),
you have no business using it.

HP-UX make was not the first make I had used, but I found this message
insufficiently obvious the first time I saw it.

 

[jacob navia]

On 21 Jul 2004 16:59:12 GMT, (e-mail address removed) (Dan Pop) wrote:

HP-UX make was not the first make I had used, but I found this message
insufficiently obvious the first time I saw it.

Me too (see other post in same thread)

Today 2001, couldn't that utility be changed?

Accepting spaces instead of tabs??????

That would save millions of hours to novices.

 

[John Smith]

Either learn how to use the tools involved in the application building
process or ask someone else to build the application. If you don't
understand how a tool works (or, at least, how it is supposed to be used),
you have no business using it.

Dan

Great stuff, Dan. You're always helpful. Keep up the good work.

 

[Allin Cottrell]

John Smith wrote, re. Dan Pop's response to a question about "make":

Great stuff, Dan. You're always helpful. Keep up the good work.

Inappropriate sarcasm. The original question was totally off-topic for
c.l.c., and clueless into the bargain. Under the circumstances there
is no strong presumption that a "helpful" answer was called for.

Allin Cottrell.

 

[John Smith]

John Smith wrote, re. Dan Pop's response to a question about "make":



Inappropriate sarcasm. The original question was totally off-topic for
c.l.c., and clueless into the bargain. Under the circumstances there
is no strong presumption that a "helpful" answer was called for.

Allin Cottrell.

If no helpful answer is called for, just ignore it for Christ's
sake and save bandwidth. If this ng isn't about being helpful,
there is no reason for its existence. Being rude to naive posters
won't stop OT posting (or clulessness). It's Dan Pop's habitual
bad manners that are inappropriate. He needs to get laid, or take
a valium, or something...

 

[pete]

John Smith wrote:

If no helpful answer is called for, just ignore it for Christ's
sake and save bandwidth. If this ng isn't about being helpful,
there is no reason for its existence.

No.
If this newsgroup isn't about C,
then there is no reason for its existence.
OP was off topic.

 

[Rouben Rostamian]

If this newsgroup isn't about C,
then there is no reason for its existence.

I agree with your statement but I hope that you realize that it is
no more than a slogan.

What you wish this newsgroup were and what this newsgroup _is_ are two
very different things. Pinch yourself to wake up. The main theme
of this newsgroup is a my-dick-is-longer-than-your-dick exhibition.
C-related discussions constitute a very small fraction of the
newsgroup's volume.

The large number of irrelevant articles that flood this newsgroup are
not posted by newbies; they are posted by the regulars. Just look
at this thread. One off-topic article by a newcomer has generated
a dozen responses. What does that make the newsgroup's signal to
noise ratio? Who is contributing to the noise?

 

[pete]

One off-topic article by a newcomer has generated
a dozen responses. What does that make the newsgroup's signal to
noise ratio?

It makes it vastly greater than the S/N ratio
on groups where there are no topic cops.
Take a look at
if you want to see what a newsgroup looks like,
after being rendered totally useless
by lack of topicality enforcement.

 

[Dan Pop]

HP-UX make was not the first make I had used, but I found this message
insufficiently obvious the first time I saw it.

It doesn't matter: if you know the make syntax, all you need to know is
that you have a syntax problem on line 31.

Mismatched braces can lead to far more confusing diagnostics from C
compilers.

Dan

 

[Dan Pop]

Great stuff, Dan. You're always helpful. Keep up the good work.

Believe it or not, the advice was far more helpful than it might look on
a superficial reading.

Dan

 

[John Smith]

I agree with your statement but I hope that you realize that it is
no more than a slogan.

What you wish this newsgroup were and what this newsgroup _is_ are two
very different things. Pinch yourself to wake up. The main theme
of this newsgroup is a my-dick-is-longer-than-your-dick exhibition.
C-related discussions constitute a very small fraction of the
newsgroup's volume.

The large number of irrelevant articles that flood this newsgroup are
not posted by newbies; they are posted by the regulars. Just look
at this thread. One off-topic article by a newcomer has generated
a dozen responses. What does that make the newsgroup's signal to
noise ratio?

Amen!

Who is contributing to the noise?

A few puffed up prima donnas who believe that expertise is
license to be abusive. Note that cooler heads did make helpful
responses the the OT post by contributing information that, while
strictly OT, is valuable.

 

[John Smith]

Rouben Rostamian wrote:




It makes it vastly greater than the S/N ratio
on groups where there are no topic cops.
Take a look at
if you want to see what a newsgroup looks like,
after being rendered totally useless
by lack of topicality enforcement.

Sorry. The problem is not lack of "topicality enforcement."
sci.physics is a much broader and more popularized topic than
programming and therefore attracts more kooks and clueless
newbies. c.l.c and the other programming lang. ngs are lucky to
be in their own esoteric little niche where a relatively small
slice of the population has any interest in them.

 

[Alan Balmer]

It doesn't matter: if you know the make syntax, all you need to know is
that you have a syntax problem on line 31.

One of a number of possible errors on line 31, or line 30, or 32, or
somewhere in the same file. Sorry, I can't agree that informative
error messages "don't matter." I've yet to see a compiler with only
one message. "Compilation complete - something bad on lines 436 and
768."

 

[Dan Pop]

One of a number of possible errors on line 31, or line 30, or 32, or
somewhere in the same file.

You start by finding and fixing all the syntax errors you find on line
31. If there are none, you look at its neighbours.

Sorry, I can't agree that informative error messages "don't matter."

This is not what I said. I said that it doesn't matter if someone
doesn't understand a specific error message (that might be crystal
clear to another user). We have seen plenty of examples of users not
understanding the most clear diagnostics of gcc, so no matter what you
do, someone will fail to understand your messages. Yet, this should NOT
prevent anyone from searching and finding the problem.

I've yet to see a compiler with only
one message. "Compilation complete - something bad on lines 436 and
768."

Well, I have seen compilers reporting an error at line 768, when the
error was at line 436, which is even worse than your example.

I have used compilers that used numerical error codes as diagnostics.
It proved to be faster to look at the code and see what's wrong than
looking up the error codes in the compiler documentation (and having
them translated into almost as meaningless english text).

And the favourite error message of the first compiler I have ever used
(FORTRAN IV) was: "Syntax error".

Dan

 

[jacob navia]

On 22 Jul 2004 13:34:00 GMT, (e-mail address removed) (Dan Pop) wrote:

One of a number of possible errors on line 31, or line 30, or 32, or
somewhere in the same file. Sorry, I can't agree that informative
error messages "don't matter." I've yet to see a compiler with only
one message. "Compilation complete - something bad on lines 436 and
768."

I find your point extremely important.
Clear error messages belong to software construction and
good software design.

As I explained in another message in this thread, the
interface of make in this respect is awful since there
is NO way to see the spaces or the tabulations in a computer
screen!!!!!

You just CAN'T SEE THEM. This first interface error is coupled with
another problem: a badly worded error message. Instead of saying:

Expecting separator (tab) at start of line xx, found "space"

It will NOT tell the user what a "separator" is or what it is expecting,
but just stop with a gibberish message.

I can understand that in the cramped environment of the
original Unix implementation this was maybe necessary but
TODAY, more than 20 years later seeing this error still there
and this people completely confused AS I WAS in 1985
is discouraging.