Learn C the Hard Way – Making and making and GNUmaking and throwing things across the room

Ex 2 of Learn C the Hard Way introduces how the makefile works. I’ve tried and failed to use this before, when trying to make an Arch package, so it’ll be good to work out how to do that. I’m not looking forward to failure, of course. This blog is basically a lie.

emacs Makefile

and I created the file as I was told to. My ex1 still has

#include<stdio.h>

in it, so it didn’t throw up any warnings, but when I commented that line out, it did. So my computer’s now in much the same state as what Zed was using to write, and I’m not getting my compiler screaming where his wasn’t. I did have to read down his page to a note saying that he had an unfixed ex1, but I was pretty sure that’s what had happened. I’d put that note up at the top.

If I have two tabs instead of none, I don’t have any errors thrown. This is unlike Python’s unexpected indent. I wonder why it needs an indent at all, but I’m going to go with BECAUSE and ignore that for the moment.

I had to go looking for more information for extra credit. According to
www.cs.colby.edu/maxwell/courses/tutorials/maketutor
‘make’ on its own will execute the first command in the file. So, my first attempt at putting all: ex1 into the file was after clean: and it didn’t work. My second attempt had line breaks, which was a guess at how to separate functions. I then went without separating functions at all. -o is a flag that should take one file name, and then the next bit of info should be separate by default. And whaddyaknow, this works. I have, readers may have noticed, a way of making things difficult for myself, mostly by assuming they will be more complicated than they actually are.

I’ve decided I want to add -d to the makefile flags, if that does what I think it will. I like debugging info.
-o seems to mean we’ve got an old file, which is… odd. So it must be that the internal makefile syntax and the syntax we use to call it are different. It sort of makes sense.

man make

has a typo in it.

$ man cc

– no manual entry for cc. Yerwhat? I assume cc is the c compiler…

$ which cc

– /usr/bin/cc . So I have it. I just don’t have a man page.

$ man -k '^cc$'

– nothing appropriate. This isn’t about an adult filter, either. This man page isn’t in my distro. So, over to

https://www.ma.utexas.edu/cgi-bin/man-cgi?cc+1

to get my fix. And aaaah. ‘gcc’ exists.

$ man gcc

– Result! And wow, that’s complicated. I mean, that’s a whole set of stuff that I could do, with huge options lists I can’t (yet) hope to comprehend. But here I am failing in public, so let’s look at the last bit of the Extra Credit. I don’t know what ‘better’ means in this case, for a future case of what a Makefile does.

Online research – http://mrbook.org/blog/tutorials/make/ is helpful. It’s coming from the angle of people who can code and want to automate it, but it’s still explaining things simply. all: is a default. Anything after the colon is dependencies. I think this should be expanded and explained more. I’m not getting it from Zed’s explanation, and a couple of sentences there would have made the first part of the Extra Credit much easier to understand. I think I’m learning too far ahead of things, though. I went back and stopped ex1 from being a dependency of all: and that’s where I’m leaving it. I’ve cruised through a few examples, but there’s too much to hold in my head to stay here. I need to move on and see how it works.

Learn C the Hard Way – I do everything the hard way

For those joining me in my world record yak shaving attempt, today I started poking at Learn C The Hard Way by Zed Shaw. It’s currently in its beta form, as he’s writing it in public so people can look and learn and proof-read, and I have a reason to learn enough C to get by. Sparky, the Spark Eroder, needs an output method to help me understand what’s going on in his insides. I can’t afford an oscilloscope, so a £3 microprocessor is going to do the job.

I say ‘a’ microprocessor, but when I bricked the first, I ordered two more. If I’d bricked an oscilloscope, two more would have come in beyond budget.

So, Zed has written up the two cases of Debian and RPM based Fedora, for the installation of what I’ll need. I work on Arch. There are reasons. They are not and can never be adequate reasons, but I’m sticking to them. So, the first thing I did was Exercise 1, to see what would break. If I could make Ex 1 work, then I’d be set up right. If not, I’d have error messages.

I had error messages!

ex1.c: In function 'main':
ex1.c:3: warning: implicit declaration of function 'puts'

Well, he explains this in the Ex 1 page – I’ve got flags set that will show errors. This one is a warning, and if I were on Debian or Fedora or in fact anything sane, it (probably) wouldn’t be a problem. But I’m not, and it is. So now I have to work out WTF the flags have to be. He can show me how to turn the flags /on/ and break things. I’m looking to turn the flags /off/ and mend things, or at least suppress them so I live in bliss and ignorance.

Turning flags off in the future is probably a bad idea, and I’m going top be keeping them on in general, so if I run into this again I can flag it up, but I want to know how it’s going wrong. It also meant I didn’t type the version with the flags turned on.

$ man make

It seems that there’s a –warn-undefined-variables flag, but I can’t work out how to turn it off. There’s also a –touch flag, which is interesting. It’ll just poke (and possible create, I wasn’t doing more than skimming) files so they have updated timings for when I want to make a latest version of a set of files. That’s probably not useful for me yet, but the notion that

make

is so powerful is written all over the manual file. I can define different files as the ones to use, regardless of which are most recent, and I can deliberately override dependencies. So that tells me that make handles dependencies and stuff like that.

On with the show. I can make, and use, ‘ex1.c’. It prints ‘Hello World.’. It’s a capital letter on the second word because that’s how I roll. Oddly, I’ve found that the tighter my copying of code gets, and the more I’m concentrating, the more likely I am to typo in the parts where there’s no penalty for error.

Extra Credit:

I didn’t edit the original exercise file. I made a second file so I’d be typing the same things again, so I’ve got ex1a as well as ex1. I’m pretty sure that’s better, as I can compare programs if I have to.

I worked out what stdio has to stand for. It’s not short for Studio. It means ‘standard in-out’. The ‘.h’ means it’s a header file. I looked up the second bit. The first bit I knew through failing repeatedly at Linux everything, and I’m OK with that.

I managed to get a segmentation fault by using ‘ instead of ” as line breaks. I also need a work-around for my American keyboard which doesn’t play nicely with my locale settings. I’m going to have to give up the £ to get a # and a working pipe that doesn’t need five key presses and a swift prayer.

man 3 puts

– The ‘3’ means it’s in part 3 of the linux user manual, which deals with C library functions. So,

#include

means you’re explicitly declaring the existence of puts() in the library you include, instead of implicitly calling it and relying on the compiler to make up for your error.

It’s all downhill from here

This is a blog dedicated to the making that Diana does, often in the company of others, often to the exclusion of eating, sleeping, or personal hygiene. It’s also dedicated to those who help her, and those who glaze over and rock quietly when she talks to them.

You helped!

It’s a space in which learning will often be accompanied by failure and the word ‘fuck’ whispered quietly but vehemently as the magic smoke escapes from something expensive, or with a tiny grinding sound, a drill bit breaks in a piece of steel.

Fuck.